Mostrando postagens com marcador Firefox. Mostrar todas as postagens
Mostrando postagens com marcador Firefox. Mostrar todas as postagens

segunda-feira, 16 de outubro de 2017

Corrigindo falha nas fontes no Firefox e Thunderbird no Linux

Numa das atualizações do sistema acabei notando o Thunderbird abriu com as fontes com a aparência bastante horrível. Mais ou menos no que aparece na figura abaixo:

A figura do exemplo é do Firefox. Mas isso aconteceu apenas no Thunderbird aqui


O que é mais estranho é que isso ocorreu apenas no Thunberbird. Já o Firefox estava normal e sem nenhum problema. Então existe a possibilidade que isso seja algum problema em bibliotecas. Então eu recompilei o Thunderbird para ver se a situação melhora. Mas isso não funcionou.

Depois de algumas pesquisas eu achei a solução neste endereço: http://z-issue.com/wp/ugly-fonts-in-mozilla-firefox-and-thunderbird-under-linux-skia-and-cairo/. Nesta página indicava que a falha era mais por conta da mudança da biblioteca de renderização de fontes que mudou, nos aplicativos da Mozilla, do cairo para o skia. Provavelmente o skia usado pela Debian ficou bugado depois da última atualização. Mas ainda não explica o porque do Firefox estar imune a falha (Ele usa o skia e está normal).

De qualquer forma, no endereço acima, ele explica que tem como corrigir. No Firefox(Vale no Thunderbird, mas é outro caminho) tem que ir no about:config sabendo que verá dragões (Hic sunt dracones) e procurar os seguintes parâmetros:

gfx.canvas.azure.backends
gfx.content.azure.backends

Altera os valores de skia para cairo nos dois parâmetros e reinicia o aplicativo. A partir daí a exibição das fontes será normalizada.

No Thunderbird a configuração pode ser acessada em Editar -> Preferências -> Avançado -> Geral -> Editor de config.

Pelo menos aqui o Thunderbird voltou ao normal com essa configuração.

Tenham uma boa semana.

segunda-feira, 3 de julho de 2017

Resolvendo os problemas do Guardião 30 Horas em qualquer sistema (Versão 2017)


Atualização 03/09/2021: Depois de muitos anos o Itaú resolve acabar com o acesso a quem não tem suporte ao Guardião.
Então é possível que esta publicação esteja inválida após o dia 21/09/2021 e sejamos forçados a instalar o Warsaw. Assim que descobrir uma nova forma de contornar isso farei uma nova publicação com o novo método. Por hora segue o texto atual.


Essa é uma atualização completa de http://www.adilson.net.br/2012/02/resolvendo-os-problemas-no-guardiao-30.html e as dicas, a seguir, vale tanto para Linux quanto para Windows, Mac, e qualquer outro sistema operacional. Isso é válido para o Itaú. Como ainda não testei na Caixa, não dá para garantir que esta dica vá funcionar do mesmo jeito.

Antes de mais anda me desculpe pela longa demora em criar algo novo aqui. Ainda tenho algumas idéias mas ainda não coloquei em prática. Como hoje tive problemas em usar o Itaú no celular, resolvi usar novamente no Desktop e aí é que os problemas apareceram:

Já faz algum tempo que o Java deixou de ser suportado na maioria dos navegadores modernos. E quem usa Linux, como eu e muitos por aí, ficaram preocupados já que a outra opção seria usar o Windows com um software muito complicado chamado Warsaw. Também conhecido como G-Buster e, nos sites dos bancos, como Guardião. Chamo de complicado porque ele já entrou em conflito com atualizações do windows, chegou a bloquear a conexão de máquinas utilizando o ipv6, além de deixar alguns processos rodando nos computadores que podem fazer qualquer coisa que não imaginamos o que poderia ser.

Sobre o uso do banco através de máquina windows ainda tem a outra ameaça:



E, consequentemente...


Nisso, o criador deste software complicado, a GAS Tecnologia, resolve portar o mesmo para o Linux. Tanto que, pelo menos nas distribuições Debian, Ubuntu e derivados, ao clicar em instalar o Guardião, ele baixa o pacote deb correspondente.

O que compensa é que os aplicativos para celular evoluíram tanto que vale mais a pena usar eles do que instalar este plugin.

Mas hoje tive um problema no acesso ao celular e, a alternativa, é usar o navegador. Porém não queria instalar o Warsaw na minha máquina principal e de confiança. Mas, como tenho uma máquina virtual com Ubuntu (Também tenho uma máquina virtual com Windows 10, mas não será usada pelos motivos mostrados anteriormente) então resolvi utilizar ela para acessar o banco. Afinal, cria-se um snapshot, instala o Warsaw, usa o banco e, depois restaura o estado anterior.

Então fiz o seguinte, acessei o Itaú, tanto pelo Chrome quanto no Firefox e me deparei com esta mensagem:


Cliquei em Instale agora, continuar e baixou o arquivo warsaw_setup_64.deb. Daí é feita a sua instalação, juntamente com qualquer dependência que solicitar.

Durante a instalação apareceu algo bastante estranho:

Configurando warsaw (1.3.0) ...
/var/tmp /
Generating RSA private key, 4096 bit long modulus
...........................................................................................................................................++
......................................++
e is 65537 (0x10001)
Generating RSA private key, 4096 bit long modulus
..........................................++
......................................++
e is 65537 (0x10001)
Signature ok
subject=/CN=127.0.0.1
Getting CA Private Key
certutil: could not find certificate named "Warsaw Personal CA": SEC_ERROR_BAD_DATABASE: security library: bad database.
Notice: Trust flag u is set automatically if the private key is present.
certutil: could not find certificate named "Warsaw Personal CA": SEC_ERROR_UNRECOGNIZED_OID: Unrecognized Object Identifier.
Notice: Trust flag u is set automatically if the private key is present.

Bad database? Unrecognized Object Identifier?

Será que isso influencia em algo?? Bom, os navegadores foram reiniciados e foi feito um teste inicial no Google Chrome. O resultado foi:


Não sei o porque do Chrome não detectar o Warsaw. Então fui no Firefox e:


Melhorou, então fui digitar a senha e...



Mas como pode isso??? Tudo foi instalado, a máquina virtual reiniciada e o erro permanece. Provavelmente pelos problemas de certificados que apresentou na instalação.

Fui ver os processos e encontrei isso:

adilsond@fett:~$ ps aux |grep warsaw
root       1039  0.0  1.0 742956 21704 ?        Sl   19:41   0:00 /usr/local/bin/warsaw/core
adilsond   2298  0.0  0.5 584392 10280 ?        Sl   19:43   0:00 /usr/local/bin/warsaw/core


Um dos processos roda com o usuário root.

O Warsaw roda como root!

O Warsaw roda como root!


O Warsaw roda como root!
Lembra que falei que não sabemos o que o Warsaw pode fazer numa máquina Windows? Pois bem, se no Windows ele pode fazer bagunça, imagina no Linux, e como usuário root que é o administrador do sistema. Tem que ter em mente como funciona o sistema de permissão do Linux. Um usuário comum pode não ter permissão para mexer e bagunçar o sistema por completo. Mas o usuário root é considerado um "Deus", ou seja, ele pode tudo. Imagina um rm -rf * na pasta raiz (/). Como usuário comum o estrago pode até ser minimo. Mas, como root, o estrago é total. Claro que existem softwares que rodam como root no Linux mas, boa parte deles, tem código fonte disponível, já foi auditado por muita gente ao redor do planeta e as falhas são sanadas rapidamente. Já o warsaw, acho que só tem aqui no Brasil, é de código fechado e ninguém sabe o que ele pode fazer se tiver algum exploit violento do tipo Zero Day(É o exploit que só se descobre depois que se ******). (OBS: Pior que já teve um caso assim).

O aplicativo para celular ainda estava com com problemas, o que foi confirmado posteriormente pelo Itaú:



Entrar no Windows estava fora de cogitação. Então, durante uma pesquisa no Google, encontrei algo que remonta o antigo problema da época do java.


No artigo anterior eu expliquei como alterar o User-Agent, para um outro navegador. Neste caso agora só precisa fazer com que o navegador finja que é um Firefox mais recente num sistema Solaris (Pode ser outro sistema operacional que não seja Windows, Linux ou Mac OS X).

Mozilla/5.0 (Solaris; Solaris x86_64; rv:54.0) Gecko/20100101 Firefox/54.0

Com essa alteração, acessei o Itaú, tanto pelo Firefox quanto pelo Chrome, o acesso foi normal e não apareceu nenhum aviso para instalar ou que está usando o Guardião.  Nos testes o Warsaw nem estava instalado ou rodando. Isso garantiu que eu fizesse as transações sem problema algum, apenas pedindo o código do token no celular.

Com isso foi mostrado que é possível acessar o Internet Banking do Itaú sem a necessidade deste plugin chato. Como a solução é via navegador, ele vale tanto para Linux, quanto para Windows, Mac e qualquer outro sistema onde este warsaw é utilizado.

Como falei, anteriormente, isso só foi testado no Itaú. Em outros bancos aonde o plugin é usado eu não fiz o teste e não há garantias que ele possa funcionar. Nas o ideal mesmo é que este plugin seja abandonado e que os bancos utilizem outras soluções menos invasivas para o usuário final.

Espero que isso seja de grande ajuda para quem tem problemas com este plugin. Vou ver se consigo voltar a publicar mais vezes já que tenho bastante material para publicar e tenham uma boa semana.

sábado, 12 de março de 2016

Fim da tetra entre Mozilla e Debian. Iceweasel volta a ser Firefox.

Já não vamos ter mais Iceweasel

No dia 27 de fevereiro de 2006 foi aberto um bug report em https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354622 onde um representante da Mozilla reclamava sobre o uso da marca Firefox e Thunderbird nas versões compiladas na Debian. Para manter a qualidade do programa, os desenvolvedores da distribuição aplicava patches de segurança e esses patches não passavam pela Mozilla. A partir deste ponto rolou uma discussão pelo uso da marca que culminou no seguinte: Os desenvolvedores da Debian ainda pegavam o código do Firefox. Porém eles faziam várias modificações para ganhar um novo nome e logo. E aí deu a origem ao Iceweasel e, por consequência, o Thunderbird se tornou o Icedove. Com isso a Mozilla não pertubava mais a Debian sobre a questão da marca.

Mas isso trouxe alguns problemas para alguns usuários. Desde de extensões não funcionando até problemas de acesso a certos sites. Essas falhas foram logo resolvidas, porém ainda tem usuários que preferem utilizar o Firefox ao invés do Iceweasel. Algumas opções existiam por exemplo:


  • Mudar de distribuição aonde tinha o Firefox nativo.
  • Baixar o Firefox do site oficial. Pode gerar alguns problemas de atualizações mas o Firefox tem um aviso quando chega uma versão nova.
  • Pegar os fontes do Iceweasel e tentar reverter para o Firefox. Foi a minha primeira opção. Dava um trabalhão mas conseguia um bom resultado.
  • Pegar os fontes de uma outra distribuição e adaptar para Debian. Foi a minha segunda opção depois de alguns anos. Pegava os fontes do Ubuntu e recompilava na Debian. Esta opção funcionava bem melhor.
A única desvantagem da utilização dos fontes é ter que baixar toda vez e recompilar quando saia uma nova versão. Mas era uma boa opção para mim.

Isso durou anos. Com o tempo alguns desenvolvedores da Mozilla também cuidaram de alguns softwares da Debian até que, no dia 17 de fevereiro de 2016, quase 10 anos depois do inicio da tetra, um novo bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006) foi aberto para encerrar as divergências e trazer o Firefox e Thunderbird de volta a Debian.

Mozilla: Aí Debian, chega de treta. Podemos ficar de boas e pode usar os logos.
Debian: Claro, vamos ficar de boas.
Isso quer dizer que a questão dos logos e dos patches foram encerradas e a Debian pode novamente disponibilizar o Firefox, o que quer dizer que vai ser o fim do Iceweasel e, por consequencia, o fim do Icedove já que o Thunderbird deve voltar em seguida.

E isso também quer dizer que não preciso mais compilar o Firefox do Ubuntu. :)

Com isso, no dia 10 deste mês, um dos desenvolvedores da Debian publicou em https://glandium.org/blog/?p=3622 anunciando que o Firefox estará disponível e verificando em https://packages.debian.org/sid/firefoxhttps://packages.debian.org/sid/firefox-esr os pacotes já se encontram disponíveis para uso. O Iceweasel ainda continuará na Jessie até o limite da versão ESR que será substituído pelo próximo Firefox ESR.

Com o fim dessa longa tetra, tudo volta ao normal no mundo dos navegadores.

Tenham um bom final de semana e, para usuários da Debian, um bom download do Firefox.

quarta-feira, 22 de fevereiro de 2012

Adobe anuncia que o Flash para Linux, após o 11.2, só será oferecido ao Google Chrome

Notícia que surgiu desde a manhã desta quarta feira de cinzas agitou o mundo open source quando a Adobe anunciou que após a versão 11.2 a versão do Flash Player para Linux deixará de ser distribuído via download. Neste caso o plugin será distribuído por uma nova api chamada de Pepper Plugin Api (PPAPI). Apesar de ser uma api opensource, até o momento, só está disponível nos navegadores Google Chrome e a versão de código aberto Chromium.

Por enquanto nada de Flash para raposa?

Segundo a Mozilla, a algum tempo atrás, eles não estão interessados em implementar o Pepper API. Mas pode ser que esta notícia faça com que eles mudem de idéia. Apesar disso as futuras versões do Flash estarão disponíveis por meio de downloads em outras plataformas (Windows e Mac). Já no Linux só serão liberadas atualizações de segurança da última versão não-Pepper(11.2) durante 5 anos para os demais navegadores que não adotaram a API. Ou seja, qualquer função nova que for implementada no Flash só será vista, no Linux, pelo Google Chrome.

Isso também pode ser um fator para que acelerem o densenvolvimento de algumas alternativas, como o Gnash e o Lightspark ou que o HTML5 avance, de forma significativa, muito mais devido a plataforma móvel já que a Adobe desistiu de desenvolver o Flash para celulares, além dos iPhones e iPads não suportarem o plugin.

O jeito é aguardar os próxmios capítulos para saber no que vai dar essa mudança toda.

Mais detalhes em:


Tenham uma boa semana.


quarta-feira, 15 de fevereiro de 2012

Resolvendo os problemas no Guardião 30 Horas no Linux

Atualização: 17/02/2012 Recebi uma ligação do Itaú já informando que estão corrigindo os erros e que, pelo Firefox, eles conseguiram sanar o problema. Entretanto comigo o erro continua muito provavelmente porque atualizei o Firefox para a versão 10.0.2 que saiu agora. Repassei este fato para a atendente que será repassada para o setor de TI do banco. Ao menos já é um bom sinal para quem está tendo problemas com o Itaú. Acredito que, depois do carnaval, a situação volte ao normal.

Atualização: 25/02/2012 Finalmente o Guardião 30 Horas instalou no Linux. Neste caso já consigo acessar todas as funções do antigo bankline tanto em casa quanto no trabalho sem precisar alterar o User Agent. Mas, se tiver mais alguém com problemas, siga as instruções abaixo e reclame com o Itaú. Mas tudo indica que o banco já pode fazer as pazes com os usuários do pinguim :D

Atualização: 25/02/2012 (2) Eu fiz um teste em uma máquina virtual Ubuntu e mostrou o seguinte:

  • O guardião roda bem em um Firefox usando o OpenJDK, porém ele falha no Google Chrome. Neste caso deve-se instalar o java da Oracle. As instruções para criar os pacotes estão aqui. Mas lembre-se que a última versão é a 6.31. Então adapte os comandos de download para os que estão nesta página da Oracle.


Eu sou cliente do Itaú já tem mais de 10 anos e a conta salário que abri se tornou a principal conta corrente. Eu quase não tive problemas com o banco tanto que o último problema sério que tive foi com o iToken a alguns anos atrás, que tive que trocar no dia seguinte já que a agência não tinha na hora.

Até mesmo o acesso ao Itaú Bankline (Atual Itaú 30 horas herdado do Unibanco) era tranquilo no Linux até que chegou um aviso de que teria que instalar o Guardião 30 Horas. Até aí ignorei, mas ao tentar pagar uma conta, uma outra janela abre mostrando o seguinte:


Segui as instruções, inclusive com a confirmação do java, e o que houve foi um erro dizendo que não pode ser instalado. Imagina a minha reação na hora já que a conta vencia no mesmo dia.



Algumas soluções vieram na minha cabeça.

1) Reiniciar o computador e acessar o Itaú pelo Windows 7.

Nem precisa dizer o que acho sobre isso:

Eu evito o máximo de acessar o banco na plataforma Windows justamente pelos riscos que existem de Virus. Mesmo com o anti-virus instalado e atualizado, sempre aparece alguma ameaça nova para roubar as senhas. Então:

De jeito nenhum

2) Acessar pelo celular.
3) Fazer o pagamento por telefone
4) Procurar por alguma alternativa.

A 2 e a 3 são boas alternativas. Mais ainda a 2 já que o aplicativo nativo para o Android é muito bem feito. Mas isso seria para o último caso. Então parto para a opção 4  e, procurando no Google, descobri uma coisa interessante: Os usuários de Mac não são afetados, tanto que veio uma informação que era só alterar o user-agent do navegador para um no Mac para burlar o Itaú.

Então tem uma maneira e vou explicar nas duas formas, uma pelo Firefox e outra pelo Google Chrome.

1) Pelo Firefox:

Baixe o User Agent Switcher que é uma extensão que vai fazer a mágica.

2) Pelo Google Chrome:

Baixe o User-Agent Selector que é o equivalente a extensão do Firefox.

Estando de posse de um dos dois ou ambos, vamos montar o User Agent para Mac.

Abra uma nova aba e digita about: no Firefox ou chrome://version/ no Google Chrome e anota o Agente do usuário ou identificação da compilação que seria o seguinte:

Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
ou
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.46 Safari/535.11

O que está em negrito é a parte que vamos manipular. Crie uma nova entrada nas opções da extensão e cole uma das duas strings.

Logo, em seguida, mude o que está em negrito para: Macintosh; Intel Mac OS X 11_7_9. A partir daí a string ficará dessa maneira:

Mozilla/5.0 (Macintosh; Intel Mac OS X 11_7_9; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
ou
Mozilla/5.0 (Macintosh; Intel Mac OS X 11_7_9) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.46 Safari/535.11


Salve e vá para o site do Itaú. A partir dele você seleciona, no menu da extensão, a opção do navegador no Mac que você criou. Loga no Itaú 30 horas e tenta pagar a conta. O que vai ver, em seguida, será a situação de antes de aparecer o Guardião: O campo para pagar a conta ou a senha do iToken. Ou seja, pode pagar a conta sem problemas.

Essa solução é apenas um paliativo enquanto o Itaú não resolve este problema para quem usa Linux. Fazendo uma busca vai encontrar diversas reclamações a respeito da instalação do Guardião seja qual for sistema operacional utilizado. Uma prova que, desta vez, o Itaú criou uma coisa para complicar a vida do usuário ao invés de facilitar.

E, para finalizar, se for usuário de Firefox e  tiver preguiça de usar a extensão para mudar o User-Agent, tente a extensão Bancos Bugados (Itaú) que simplifica esta tarefa.

Tenha uma boa semana.

Atualização (16/02/2012): Recebi a informação de que alguns usuários de Mac estão tendo o mesmo problema. Isso está sendo investigado já que não tenho Mac para fazer os testes. Por enquanto, o que posso recomendar, é seguir as mesmas instruções. De início instale as últimas versões do Firefox e do Google Chrome. Se não funcionar utilizem as extensões e aplique um dos User-Agent modificados que está nesta página. Depois me informa na área de comentários se conseguiu acessar ou não informando a versão do navegador e sistema operacional utilizado.

sábado, 20 de agosto de 2011

Resolvendo problemas de compilação dos softwares do Mozilla

Não tive muito tempo para postar nos últimos dias, mas hoje vou deixar umas dicas de compilação de alguns programas do Mozilla (Firefox, Thunderbird e Seamonkey) que dão alguns erros nas últimas versões. Tá certo que já existem pacotes prontos nas diversas distribuições mas existem casos que é melhor compilar. Por exemplo eu uso Debian mas não quero Iceweasel e sim Firefox num ambiente 64 bits. Então eu pego os fontes do Ubuntu recompilo os pacotes para se adaptar na Debian.


Aqui vão dois erros que estão acontecendo comigo e como fiz para solucionar:


curl/types.h not found


Um erro assim ocorre justamente no Debian sid já que a versão mais nova do curl tornou o types.h obsoleto, quebrando alguns programas.


Workaround: 
Instale os pacotes libcurl3_7.21.0-2 e libcurl4-openssl-dev_7.21.0-2 do wheezy ou os equivalentes nas outras distrbuições até que se resolva o problema no libcurl ou nos outros programas.


../coreconf/config.mk:71: ../coreconf/Linux3.0.mk: Arquivo ou diretório não encontrado


Este problema só ocorre quando se usa a versão 3.0 do kernel recém lançado. Neste caso tem um workaround bem mais fácil.


Entrando na pasta mozilla/security/coreconf tem vários arquivos sendo que um deles é o   Linux2.6.mk. Como sabemos que a diferença principal entre o kernel 2.6.x e o 3.0 é apenas na numeração, podemos simplesmente usar um dos dois comandos:


ln -s Linux2.6.mk Linux3.0.mk
ou
cp Linux2.6.mk Linux3.0.mk


Manda compilar e problema resolvido.


Tenham um bom final de semana.

quinta-feira, 31 de dezembro de 2009

Resolvendo os problemas do applet Java no Debian Sid

Este é um dos últimos posts do ano que engloba um problema que consegui resolver por conta de um applet que não rodava.


Por curiosidade resolvi entrar numa página para a contagem regressiva para 2010: http://www.timeanddate.com/counters/multicountdowna.html e encontrei o seguinte erro:





Até aí nada de mais e tentei rodar o Google Chrome e...





Só no Opera que o applet rodou normalmente:




Foram feitos vários testes nos outros dois navegadores até que, testando o appletviewer encontrei o seguinte:



adilsond@yoda:~$ appletviewer http://www.timeanddate.com/counters/multicountdowna.html
I/O exception while reading: Network is unreachable
adilsond@yoda:~$

Como o appletviewer faz parte do pacote sun-java6-jdk, pesquisei a lista de bugs e encontrei o seguinte neste link: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560044

O Netbase recentemente introduziu a configuração
net.ipv6.bindv6only=1 em /etc/sysctl.d/bindv6only.conf e essa configuração
provavelmente será o padrão no squeeze.

Esta configuração causa problemas no java e qualquer trafego de rede vai 
sempre resultar no erro "java.net.SocketException: Network is unreachable".

Mas tem um jeito de contornar este erro enquanto a Sun não atualiza o pacote do java.

Edita o /etc/sysctl.d/bindv6only.conf  e altera o valor net.ipv6.bindv6only de 1 para 0. Roda o comando invoke-rc.d procps restart e, recarregando o navegador:






O java volta a funcionar tanto no Google Chrome quanto no Firefox.


Um Feliz Ano Novo para todos.