Posts

  • Contribuições com Software Livre em Maio de 2016

    Uma prática muito comum que observo há algum tempo em comunidades de software livre são relatórios mensais sobre suas próprias contribuições. A ideia é informar sobre o que foi feito recentemente, assim como atrair pessoas que possam se interessar em projetos nas mesmas áreas para trabalharem comigo. Sendo assim, seguem minhas contribuições no mês de Maio de 2016.

    Debian

    bootstrap-vz

  • Contribuições com Software Livre em Abril de 2016

    Uma prática muito comum que observo há algum tempo em comunidades de software livre são relatórios mensais sobre suas próprias contribuições. A ideia é informar sobre o que foi feito recentemente, assim como atrair pessoas que possam se interessar em projetos nas mesmas áreas para trabalharem comigo. Sendo assim, seguem minhas contribuições no mês de Abril de 2016.

    Debian

    • Apliquei para o processo de me tornar um Debian Maintainer, obtendo o apoio de Antonio Terceiro (que eu havia pedido) e Charles Plessy (o que foi uma agradabilíssima surpresa). A ideia é assumir uma posição “mais oficial” junto ao projeto e, quem sabe, daqui uns tempos me tornar um Debian Developer (com um e-mail @debian.org).
    • Assumi os bugs ITP (Intent to Package) #790611 e #790612, do Grip e do Path-and-Addresss (dependência do Grip), respectivamente. Gustavo Panizzo os havia criado no meio do ano passado, mas não teve tempo de terminar o empacotamento. Perguntei se poderíamos trabalhar juntos nisso e ele me permitiu assumir a responsabilidade.
    • Corrigi alguns problemas no empacotamento do cloud-utils, como o copyright de uma man page que havia ficado faltando e me foi apontado pelo Chris Lamb. O upload foi patrocinado pelo Antonio Terceiro, que tem me ajudado bastante com o cloud-utils.
    • Corrigi o bug #820607, reportado pelo Olivier Berger, relacionado ao changelog do upstream incluído no pacote do bootstrap-vz estar praticamente vazio.
    • Corrigi um hífen não-ASCII na página DebianMaintainer da Wiki do Debian. Pode parecer bobo, mas isso fez com que minha mensagem de aplicação tivesse sua assinatura invalidada na interface web da lista de e-mail.
    • Desencorajei a entrada de um pacote, o series, no bug RFS (Request for Sponsorship) #820733. Infelizmente se trata de um software muito recente, praticamente utilizado apenas pelo autor. Não é o tipo de software que deve ser empacotado para o Debian.
    • Realizei diversas (muitas mesmo) melhorias no pacote do bootstrap-vz. Se tiver trabalhado 30h só com isto ainda foi pouco. A mais importante é a criação do pacote bootstrap-vz-doc, com a documentação em HTML disponível para leitura offline.
    • Reforcei, no bug #788527, o pedido para que o pacote python2-pyro4 (dependência do bootstrap-vz) fosse atualizado, o que foi rapidamente atendido pelo Laszlo Boszormenyi.
    • Reportei alguns pequenos problemas com o “collab-maint” (repositório para manutenção colaborativa de pacotes), como certificado HTTPS expirado e falta de permissões para configurar corretamente um repositório. Alexander Wirt e Mattia Rizzolo me ajudaram a resolver estes problemas.
    • Reportei o bug #820020, solicitando a atualização do pacote python-responses, dependência dos testes do python-path-and-address, o que foi atendido (muito) rapidamente pelo Ondrej Novy.
    • Reportei o bug #820685, incluindo alguns patches com melhorias no o empacotamento do zbackup.
    • Resolvi o bug #821175, relacionado a um conflito com o diretório de configurações do grip. O que acontece é que um pacote do GNOME CD Ripper tinha o mesmo, mas mesmo não faz mais parte do Debian desde 2009 (e foi abandonado pelo upstream em 2005). Sendo assim, não havia nada a ser feito.
    • Revisei o pacote python-django-gravatar2, referente ao bug RFS #819681. Encontrei alguns problemas, mas o Pierre-Elliott resolveu a maioria deles.
    • Revisei a imagem do Debian Jessie 8.4 criada para o Amazon EC2 pelo James Bromberger. Encontrei alguns pequenos problemas, mas nada grave.
    • Revisei o pacote netsed, referente ao bug RFS #821236. O pacote é mantido pelo Mats Erik Andersson há mais de 5 anos, então não havia nada muito grave a ser corrigido.
    • Revisei o pacote python-hashids, referente ao bug RFS #820900. O empacotamento foi feito por um antigo DD, Edward Betts, então não tive nada a acrescentar.
    • Revisei o pacote roadfighter e encontrei pouquíssimos detalhes a serem corrigidos, devido ao grande trabalho do Carlos Donizete Froes.
    • Submeti o bug RFS #820029 do grip, atendido pelo Mattia Rizzolo.
    • Submeti o bug RFS #819773 do python-path-and-address, também atendido pelo Mattia Rizzolo.
    • Tive meu bug RFS #819289 do pythonpy, que havia submetido no final de março, atendido. O upload foi patrocinado pelo Dmitry Shachnev.

    bootstrap-vz

    Path-and-Address

  • Desligando a tela ao bloquear o Xfce

    Como quem acompanha o blog sabe, utilizo exclusivamente Linux no desktop há quase quatro anos. Optei por muito tempo pelas versão estáveis do Debian (Squeeze/Wheezy na época) no notebook, passando a utilizar o Xubuntu (versões LTS, 12.04 e 14.04, com suporte extendido, mas de apenas três anos invés de cinco, diferente do Ubuntu) no computador de trabalho. Considerando a usabilidade do Xubuntu maior do que a do Debian com Xfce, foi natural que passasse a utilizar o primeiro também no meu notebook pessoal.

    Questiono a usabilidade do Debian porque é necessário configurar manualmente muitas das coisas que já vem habilitadas por padrão no Xubuntu. Coisas que podem parecer bobas, como o “clique com toque” e “clique com o botão direito, com toque de dois dedos” no touchpad fazem muita diferença. E, tendo voltado pro Debian (Jessie, a atual versão estável) recentemente, um destes detalhes voltou a me irritar profundamente: o fato da tela não ser desligada quando bloqueio o sistema (exigindo senha para utilizá-lo novamente).

    Como não poderia deixar de ser, se você procurar por isso encontrará soluções esdrúchulas, como a recomendação de se criar um script que chama o comando de salvar a tela, espera um tempo e chama outro comando para desligá-la depois. E o pior de tudo, é que como se já não bastasse você precisar de um script para fazer isto em pleno ano de 2016, ele simplesmente não funciona! Por algum motivo a tela liga sozinha pouco tempo depois.

    Felizmente, há uma solução simples, ainda que não tão intuitiva, para o problema. Por padrão, o Debian (pelo menos com Xfce) utiliza o XScreenSaver para gerenciamento de proteção de tela, e ele é o responsável por desligá-la após bloquear a sessão. Acessando sua configuração através do menu “Settings -> Screensaver” (ou acessando a opção “Screensaver” do “Settings Manager”), é necessário escolher as seguintes opções:

    • Mode: Blank Screen Only;
    • Lock Screen After: esta opção não é obrigatória e não irá influenciar quando a tela for bloqueada propositalmente, apenas após o computador ter ficado inativo pelo tempo configurado nas opções anteriores.

    E o problema todo está nesta última tela. Note que há a opção Quick Power-off in Blank Only Mode, que é exatamente o que estávamos procurando. Entretanto, a mesma depende da opção Power Management Enabled estar marcada, muito embora ela fique disponível para ser ativada/desativada, estando a opção anterior selecionada ou não! Meu professor de “Interface Homem-Máquina”, Frederico Bida, provavelmente infartaria vendo uma coisa dessas.

    Como pode ser percebido, deixei as demais opções de energia em 1440 minutos (24 horas), simplesmente porque não quero que o XScreenSaver controle quando o computador deve ser suspenso/desligado, já que isto fica a cargo do gerenciador de energia do Xfce. A intenção é que ele se preocupe apenas com o que realmente interessa, que é o fato de desligar corretamente a tela quando a mesma for bloqueada.

  • O lamentável estado dos softwares Freeware

    Sempre fui aficionado em conhecer e experimentar softwares novos. Ainda criança, um dos meus passatempos preferidos era passar o fim de semana (em uma conexão discada de 14.4 Kbps) navegando entre as seções, principalmente de Rede e Internet e Utilitários, do Superdownloads - que pasmem, existe desde 1998. Não demorou para que eu descobrisse em quais condições os softwares eram ali distribuídos: havia versões de demonstração (Demo), assim como as pagas porém gratuitas para testar por tempo limitado (Shareware). Destas, a categoria que mais me atraia era a dos gratuitos sem limitação de tempo ou funcionalidade: os Freeware.

    Foi nesta época que conheci softwares como o mensageiro multi-protocolo Miranda IM (que na época provavelvemente ainda se chamava Miranda ICQ, nome que foi mudado no final de 2002). Ele não é freeware e sim opensource, mas vale a pena citá-lo por conta de um bug extremamente curioso (e irritante) das primeiras versões: às vezes, quando utilizado com o protocolo do MSN (mais tarde chamado de Windows Messenger), ele perdia a habilidade de enviar mensagens mas as continuava recebendo. Se estivesse, por exemplo, discutindo com alguém, a pessoa poderia te xingar repetidamente e te chamar de covarde… E você nada poderia fazer.

    Nestas incursões no mundo dos softwares freeware, conheci muitas alternativas bacanas (todas para Windows), como o Resource Hacker, que permite editar arquivos executáveis, e o Spybot Search & Destroy, removedor de adwares/spywares. Tenho um grande carinho pelos softwares da AnalogX, em especial, por terem criado exemplares pequenos porém de grande utilidade, como o AnalogX Capture, AnalogX Proxy e AnalogX Vocal Remover. O mais importante a ser destacado aqui é que estes softwares citados são exceções, por terem se mantido funcionais e sem pegadinhas através do tempo.

    O grande problema com os softwares freeware, que pode não estar aparente, é seu modelo de negócio. Se é um produto grátis, sem custo para o usuário final, quem banca seu desenvolvimento, distribuição e manutenção? É justamente ao se tentar gerar receita com estes programas, normalmente depois de já serem conhecidos pelo público, é que o processo desanda. O μTorrent, por exemplo, tentou adicionar anúncios e chegou a instalar um minerador de criptomoedas, em uma tentativa desesperada de gerar receita.

    Alguns casos mais graves, como o do BS Player, chegaram a impossibilitar sua utilização caso o usuário removesse os adwares que acompanhavam o instalador. A situação fica ainda mais crítica quando isto se torna tão corriqueiro que as pessoas simplesmente se conformam, como foi o caso de um amigo e colega de trabalho. Ele me disse que usava o KMPlayer, mas que parou quando o instalador passou a adicionar um monte de porcarias indesejadas. E qual foi sua reação? Passar a usar outro player gratuito “enquanto ele não começar a adicionar coisas inúteis ao instalador”.

    A parte reconfortante desta história toda é que há uma alternativa: utilizar software livre. Pode parecer clichê ou “coisa de quem usa Linux”, mas não é. O excelente player de vídeo VLC (o “Chuck Norris” dos media players), por exemplo, roda em praticamente qualquer sistema operacional existente. Sem ter de ficar instalando incontáveis codecs (nenhuma saudade do K-Lite Codec Pack), o VLC toca praticamente qualquer arquivo de mídia existente (inclusive imagens ISOs sem precisar montá-las). E se alguém algum dia tentasse incluir anúncios ou outros softwares inúteis no instalador, com certeza outra pessoa empacotaria e distribuiria uma versão “limpa” do mesmo.

  • Obtendo nota máxima no teste da Qualys SSL Labs

    Buscando por “ssl test” no Google, os dois primeiros resultados encontrados correspondem a duas ferramentas muito úteis. Uma, o SSL Checker da SSL Shopper, fornece informações básicas sobre o certificado. Um certificado da StartSSL que tenha sido gerado com as dicas do último post resulta em uma saída parecida com esta:

    As informações estão dispostas de forma bem didática, mas ainda vale a pena comentar sobre cada item:

    • ssl.myhro.net resolves to 52.2.85.74: primeiro teste, exibindo o IP resolvido. Esta informação é importante para termos certeza que o teste está sendo realizado no servidor correto, o que poderia não acontecer no caso de uma entrada DNS alterada recentemente que ainda estivesse em cache;
    • Server Type: nginx/1.4.6 (Ubuntu): informações sobre o servidor, que no caso é o nginx 1.4.6, versão presente no Ubuntu 14.04;
    • The certificate should be trusted by all major web browsers (all the correct intermediate certificates are installed): destaca a importância do encadeamento correto dos certificados, com a presença dos certificados intermediários, também citada no post sobre a StartSSL;
    • The certificate was issued by StartCom: entidade certificadora responsável por emitir e assinar o certificado;
    • The certificate will expire in 365 days: tempo restante (em dias) pelo qual o certificado ainda é válido. É possível adicionar um lembrete de expiração, mas normalmente a empresa responsável pela emissão já irá realizar isto quando o prazo estiver vencendo;
    • The hostname (ssl.myhro.net) is correctly listed in the certificate: informa que o hostname está presente no certificado, o que significa que um browser não irá acusar a divergência de hostnames entre o certificado e a página de fato acessada.

    Por fim, há uma representação gráfica da relação entre os certificados, com mais algumas informações quanto ao período de validade, algoritmo de assinatura, etc. O mais importante a se destacar neste momento é que, embora seja uma boa notícia o fato do certificado não ter apresentado problema nesta validação básica, isto não significa que o site por trás dele está realmente seguro. É preciso, portanto, realizar uma análise mais detalhada, como a oferecida pelo SSL Server Test da Qualys SSL Labs.

    O resultado obtido com a configuração padrão do nginx no Ubuntu 14.04 é o seguinte:

    Dois problemas comprometeram a nota do teste: a qualidade da troca de chaves utilizando o protocolo Diffie-Hellman e a vunerabilidade à falha de segurança do SSL 3.0 conhecida como POODLE. Felizmente, estas duas fraquezas são simples de serem resolvidas e o próprio teste aponta para documentações relevantes sobre os problemas.

    Diffie-Hellman

    O guia de implantação do Diffie-Hellman para TLS traz uma descrição detalhada e até um pouco paranóica (especificando todas as cifras suportadas, o que não é necessário) sobre como reforçar a segurança da troca de chaves. Resumidamente, é preciso realizar dois passos. O primeiro é gerar um grupo de parâmetros DH com tamanho de 2048 bits:

    openssl dhparam -out dhparams.pem 2048
    

    E em seguida adicionar estas duas linhas ao arquivo de configuração do nginx (seja globalmente ou por virtual host):

    ssl_dhparam /etc/nginx/ssl/dhparams.pem;
    ssl_prefer_server_ciphers on;
    

    … Após ter movido o arquivo gerado para o diretório /etc/nginx/ssl/.

    O resultado ainda continua com classificação C, por causa do POODLE, mas não há mais menção ao problema com o protocolo Diffie-Hellman. A nota no quesito “Protocol Support” subiu de 70 para 90:

    POODLE

    Resolver a questão do POODLE é mais fácil ainda, já que basta desabilitar o suporte ao SSL 3.0 no nginx. Por mais estranho que pareça, a configuração padrão do Ubuntu 14.04 adiciona a opção SSLv3 ao parâmetro ssl_protocols. Isto provavelmente se deve ao fato desta versão ter sido lançada em torno de 6 meses antes da descoberta da vulnerabilidade. Para reverter esta configuração, a seguinte linha deve estar presente na configuração do nginx:

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    

    Esta linha força o nginx a suportar apenas protocolo TLS (Transport Layer Security) (e não SSL (Secure Sockets Layer)), em suas versões de 1.0 a 1.2. Agora, a classificação do teste passa a ser A e a nota do “Protocol Support” atinge 95:

    Mesmo assim, ainda há uma pequena melhoria a ser realizada.

    HSTS

    O HSTS (HTTP Strict Transport Security) é um header adicionado à resposta de uma requisição HTTP que informa ao cliente que todas as conexões a este servidor, dali em diante, devem ser realizadas via HTTPS. O processo para habilitá-lo no nginx consiste em adicionar a seguinte linha ao seu arquivo de configuração:

    add_header Strict-Transport-Security "max-age=31536000";
    

    E com isto a classificação sobe para A+, ainda que as notas individuais de cada quesito não mudem:

    Arquivo de configuração do nginx

    O arquivo de configuração do virtual host do nginx resultante das modificações realizadas durante os testes é este:

    # HTTPS redirect
    #
    server {
        listen 80;
        server_name ssl.myhro.net;
        return 301 https://ssl.myhro.net$request_uri;
    }
    
    # HTTPS server
    #
    server {
        listen 443 ssl;
        server_name ssl.myhro.net;
        add_header Strict-Transport-Security "max-age=31536000";
    
        root /usr/share/nginx/html;
        index index.html index.htm;
    
        ssl on;
        ssl_certificate /etc/nginx/ssl/cert.pem;
        ssl_certificate_key /etc/nginx/ssl/cert.key;
        ssl_dhparam /etc/nginx/ssl/dhparams.pem;
    
        ssl_session_timeout 5m;
    
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
    
        location / {
            try_files $uri $uri/ =404;
        }
    }
    

    Vale ressaltar que foi adicionado o redirecionamento HTTP -> HTTPS, um comportamento que não é realizado por padrão, mas que é interessantíssimo caso seu interesse realmente seja servir conteúdo de forma segura. Desta forma, todos os visitantes acessarão o site via HTTPS automaticamente.

Subscribe via RSS