Como funciona a parada da Gestão da Porta 25

Baseado nesse post do br-linux e nas dúvidas do povo no twitter, resolvi escrever um post rápido sobre o como funciona. Pode ser que tenha algo faltando ou errado, se tiver avisem nos comentários.

É assim:

Imagine que você tem um email email@longe.cu que fica longe.

Atualmente sua máquina conecta na porta 25 do servidor smtp.longe.cu para enviar email para qualquer lugar. Para isso ele deve pedir uma senha para permitir que você consiga enviar email e fazer relay.

Com a gerência da porta 25, vc não conseguiria fazer isso mais, a porta seria bloqueada. Teria algumas opções:

• Passar a usar SMTP com TLS/SSL que usa a porta 900 e algo.
• Usar um MSA (Mail Submission Agent) do seu provedor de conexão.

Esse MSA basicamente é um servidor que aceita conexões na porta 487, num formato igual ao SMTP mas com alguns relaxamentos de cabeçalho. Esse servidor tem de estar configurado para fazer relay para qualquer lugar do planeta, desde que a conexão venha da rede que ele serve, independente do FROM do email.
Então o seu cliente de correio envia a sua mensagem como você mesmo (email@longe.cu) para o MSA que daí envia ele pra o TO dele.

FROM: email@longe.cu
TO: bleh@gmail.com; bleh@uol.com.br; bleh@longe.cu

O que o MSA faz é enviar via SMTP (e aí entra o MTA) para os MXs responsáveis pelos dominios gmail, uol e longe.cu

Então sua mensagem continua saindo com seu email, da mesma forma de antes, só não vai ser do SMTP do domínio do email, mas isso não faz muita diferença.

Algumas vantagens/desvantagens que eu vejo:

• Os provedores de conexão tem mais controle sobre o que sai na sua rede de SMTP. Evita que faixas inteiras sejam banidas por causa de 1 spammer enviando emails diretamente lá de dentro;
• Até onde eu vi isso quebra SPF;
• Provedores de conexão poderiam bloquear envio de certos tipos de mensagem e etc.

intel

Não existe mundo virtual, infelizmente.

Na verdade essa barafunda toda com relação o PL 84/99 e tal tem umas raízes diversas. Esse post aqui é estranhamente sóbrio no mar de alarmismo que os showmans invocaram, ele elenca os problemas e os discute, ao invés de simplesmente disparar um monte de observações absurdas e sem sentido (FUD) para gerar medo. Eu nunca disse que a lei era perfeita (pode conferir, tá no primeiro post sobre o assunto), só que no momento é mais importante ter uma lei do que esperar uma lei perfeita. Nosso código penal tem uma idade absurda, é ultrapassado em vários pontos e tal, mas imagine só se nem ele existisse? Ou se estivesse em discussão a 40 anos?

Na minha opinião aparentemente única no Brasil =) o que acontece é a idéia de que a internet é um ‘país a parte’, um ‘mundo virtual’ a parte do ‘mundo real’. Era uma idéia interessante, eu mesmo traduzi e já citei várias vezes o Cypherpunk Manifesto mas infelizmente as coisas não são assim. Em qualquer tipo de nova tecnologia os usos maléficos estão entre os primeiros a serem descobertos e utilizados. Você pode reparar que sempre que existe uma nova descoberta científica existe um grande frisson para se regulamentar antes que alguém faça caquinha (energia atômica virou bomba, biogenética vira arma quimica e dai por diante).

A internet por outro lado meio que se imiscuiu desse processo, e essa visão que todo mundo gosta de ter de que é um mundo livre, sem leis, etc.. acabou virando a visão mais romântica da coisa. O projeto de lei discutido por exemplo define algumas coisas que seriam ilógicas não fosse essa visão de ‘mundo separado’. Roubo, por exemplo. Pela lei, se você compra um DVD pirata, você está indo contra a lei de propriedade intelectual, e todo mundo parece entender isso mesmo que não concorde, continue fazendo e ache uma justificativa para tal. Já a mesma pessoa que tem essa consciência com relação a comprar um DVD pirata não tem o mesmo pensamento quando baixa um DVD da internet. Mas o que está acontecendo é a mesma coisa, é ir contra a propriedade intelectual da mesma forma, mas aparentemente por estar na Internet, fica tudo bem, afinal de contas é um outro lugar, não é Brasil, nem real é! Se é virtual, é legal, aparentemente.

Mas não é assim. Ou pelo menos não poderia ser. Leis como a que esse PL sugere são necessárias porque não só o código penal existente é falho para lidar com questões tecnológicas como porque na cabeça da maioria das pessoas ainda existe a noção de que a internet é uma terra de impunidade.

O sr do post lá em cima tem várias críticas que fazem sentido, e algumas nem tanto. Eu digo e repito, três anos de log não são nada demais. Além disso ele argumenta que um atacante experiente pode mascarar seus logs, o que eu concordo, mas a internet brasileira não é formada por 100% de atacantes experientes, e sim de uma mistura de experientes e não-tão-experientes-assim. Além disso, se a justificativa de que ‘atacantes experientes não vão ser afetados’ fosse válida, não precisaríamos de nenhuma lei relacionada a crimes, porque afinal de contas um criminoso experiente pode muito bem realizar um crime sem deixar pistas, certo? E os registros telefônicos que já existem, são basicamente a mesma coisa que um log. Telefonia pode, mas internet não, denovo a idéia de que a internet é um lugar diferente.

Certificação digital é uma outra solução que o sr propôe, como solução para fraldes bancárias. Claro, ia tornar mais difícil essas fraudes mas como diz o adágio, não existe patch para estupidez humana. Mesmo com a certificação digital existem várias outras falhas no caminho que podem ser atacadas. Criptografia não é solução para os problemas do mundo (qualquer um que estuda segurança sabe disso), e criptografia mal implementada e nada são a mesma coisa.

Acho que algumas pessoas pegaram o barco nessa lei para lutar por outra coisa. De quando em vez vejo pessoas ai reclamando nos blogs que essa lei é coisa do PIG para controlar o direito autoral. Por mais que eu despreze a Veja e a Globo e acredite na existência do PIG, não acho que vai ser lutar contra esse PL que vai mudar nada na imprensa brasileira, até porque o PL não lida com quase nada que afete blogs/imprensa livre ou não. Ou nas leis de direito autoral, for that matter. Se o problema é que ‘a cópia de arquivos vai acabar com as redes P2P”, acho que essas pessoas deviam estar trabalhando para mudar a legislação de copyright que é velha, quebrada e não contempla os novos paradigmas dos mercados. Mas é mais fácil fazer escândalo e capitalizar em cima do hype, para atrair mais seguidores para sua causa, mesmo que não tenha nada a ver uma coisa com a outra.

E com isso acho que eu termino meu último post sobre o assunto. Acho que já disse o que tinha para dizer.

intel

PS: Para não ser chamado de hipócrita: eu vou ser atingido como qualquer um por esta lei, mais ainda porque minha área profissional tem muito a ver com internet e segurança, eu tenho total consciência disso. Isso não me impede de acha-la uma boa idéia, com falhas, mas melhor que nada.

Quando usamos as armas do inimigo

Eu tenho ficado longe de assuntos de software livre atualmente, mais por me focar em outras áreas e tal e principalmente para me manter fora de política.

Então foi com alguma tristeza que eu notei que para alguns “luminares” do software livre no Brasil, pimenta nos olhos dos outros é realmente refresco. Digo isso porque com alguma surpresa notei que esses “luminares” resolveram usar as mesmas estratégias que eles condenam a anos na luta contra as grandes empresas do software proprietário. De repente, eu vi as pessoas usando FUD (medo-incerteza-dúvida, em inglês).

Porque eu digo isso? Porque se você observar toda a “campanha” contra o PL do Senador Azeredo, você vai ver que eles usam pedaços de informação, distorcendo o contexto. Além disso exageram em coisas como chamar o projeto de “AI 5 Digital”, o que para qualquer pessoa que realmente leia o que foi o AI-5 chega a insultar a inteligência. Exemplos? Ta ái:

• “Projeto do Senador Azeredo vai inviabilizar redes abertas”
  Como assim? O que são redes abertas? São redes de colaboração entre pessoas como projetos de software livre (o que eles querem que você pense) ou redes wireless (hot-spots) que funcionam sem necessidade de cadastro/autenticação (o que a lei realmente quer evitar)? Porque nesse caso, é até uma coisa constitucional, por mais que se concorde ou não, anonimato é proibido no Brasil. E de mais a mais, qual seria o problema de se exigir um cadastro para utilização de hot-spots, visto que até para comprar celular pré-pago você precisa apresentar seus documentos. Como eu disse, FUD.
• “Projeto vai acabar com telecentros”
  Oi? Como? Ainda com a idéia aí de cima sobre redes abertas?
• “Transferir  arquivos vai ser crime, acabando com as redes P2P”
  Realmente, o projeto tem uma parte sobre cópia de arquivos, mas fala de copiar arquivos “sem a permissão do dono”. O pessoal do FUD diz que isso vai acabar com qualquer cópia de arquivo, enquanto na verdade é uma coisa meio óbvia com relação a copyright. Arquivos cujo copyright proíbem a cópia realmente não deviam ser copiados. Mas e arquivos, por exemplo, licenciados livremente via GPL, LGPL ou Creative Commons? Eles já tem, intrinsicamente, a permissão de cópia. Mas o FUD tem de ser feito.
• “Pequenos provedores e telecentros vão ser afetados pela guarda de logs”
  Como eu ja disse em um post anterior, o gasto para se manter um tamanho razoável de registros de acesso em redes não é nada exorbitante como o FUD pretende dizer. Claro, vai ter um gasto, mas nada que vá quebrar um provedor ou um telecentro.
• “Projeto transforma provedor em polícia/xerife”
  Essa dá nos nervos. O que está escrito na lei e que um provedor tem de avisar para as autoridades caso seja informado de um crime. Nada sobre o provedor ter de vigiar o que acontece de todo mundo na sua rede para depois prender e processar alguém. Mas FUD tem de se basear em falácias do tipo. Qualquer pessoa a ser informada de um crime faz por bem comunicá-lo a polícia/autoridades, porque um provedor seria diferente?
• “Projeto penaliza todo mundo menos os criminosos”
  Do jeito que a galera do FUD explica, parece que o PL foi feito para atingir o usuário normal do dia a dia de internet, enquanto os verdadeiros megahackers nunca vão ser atingidos. O fato é que o PL serve para tipificar crimes, o que não existe na legislação brasileira. Ou seja, mesmo quando um “mega hacker” é preso não existe a modalidade de crime para enquadrá-lo e acabam tendo de fazer uma gambiarra legal facilmente desqualificada por advogados. Lembra que até pouco tempo atrás a posse de pedofilia não era crime? Então, atualmente fazer um vírus ou cavalo de tróia também não. Nem roubar senha de bancos via internet (usar a senha roubada sim, é crime. Roubar e não usar, não).

Eu sei que com isso eu vou contra a corrente libertária do pessoal open-source, free software, etc… e mesmo de diversos amigos que provavelmente vão parar de falar comigo =). Mas do meu ponto de vista de profissional de segurança/entusiasta de software livre é muito triste essa disputa virar um palanque para afirmações exageradas para colocar o medo-incerteza-dúvida (FUD) em pessoas que nem ao menos tentaram ler o texto da lei sendo discutida, acabando por criar uma massa de desinformados gritando contra uma coisa que não conhece. Peraí, não era a Microsoft que fazia isso?

Como diz um amigo que trabalha comigo “Comunidade é legal mas sempre tem showman querendo aparecer”.

Afinal de contas, nada gera mais publicidade do que se colocar como um paladino lutando pela liberdade, por mais que as vezes a luta seja na verdade por libertinagem.

intel

Programando Androids – Parte 4

Na parte 3 falei sobre o gerenciamento de memória. Também falei sobre o cuidado que se deve ter para manter o estado da aplicação consistente entre as várias mudanças que o Android OS executa automaticamente.

Ciclo de vida de uma aplicação no Android

Vale lembrar que uma “aplicação” no Android é na verdade uma Activity, ou um conjunto de Activities, que podem ser consideradas as “janelas” da aplicação. Cada Activity é considerada separadamente, mesmo que esteja dentro da mesma Aplicação.

O ciclo de vida de Services é bem diferente do ciclo de vida de uma Activity e não vem ao caso para este post.

A imagem abaixo (novamente cortesia do Google) demonstra o ciclo de vida básico de uma Activity.

As ovais coloridas são os estados em que a Activity pode estar, enquanto os retângulos cinzas são os nomes de métodos de callback que serão invocadas pelo OS em cada transição. Ou seja, de quando uma Activity inicia até ela ser mostrada na tela, ela executará o código dos métodos onCreate, onStart e onResume. Os retângulos brancos com texto em itálico descrevem a ação necessária para causar os callbacks ou mudanças de estado.

Você não precisa implementar todos os callbacks, mas existem certas funcionalidades que só estão disponíveis em determinados contextos de callback e coisas que simplesmente não funcionam em alguns lugares. Por exemplo: animações, se colocadas no onResume, não iniciam. As funcionalidades para gravação de estado da aplicação são melhor aplicadas no onPause, mas este método é desenhado para ser executado rapidamente, então cuidado com o que se colocar ali.

Também é importante notar neste gráfico que sua aplicação pode ser morta caso o sistema precise de memória, e é importante dar o tratamento correto aos dados/estados que precisem ser mantidos (como em um jogo, salvar posições de objetos, valores e etc..). Outra coisa a se notar é que a Activity vai ser destruída na mudança de orientação (quando a tela roda, automaticamente ou pela abertura do teclado nos G1), e isso deve ser levado em conta (código no onCreate pode acabar sendo rodado duas vezes no caso de uma mudança de orientação).

Exemplos

Tirando o fato de que eu mal sei programar em Java, meu programa Lanterna foi um bom aprendizado sobre esses estados e o ciclo de vida da aplicação.

Por exemplo, o Lanterna requer que o telefone fique sempre ligado quando funcionando (ótima forma de se acabar com a bateria). Para isso eu precisei requerer uma parada chamada WakeLock, disponível no serviço de gerenciamento de energia (PowerManager). No onCreate eu requisito ao Android o acesso ao serviço:

/* PowerManager interface to get and release the WakeLocks later */
PowerManager pmanager = (PowerManager) getSystemService(Context.POWER_SERVICE);
this.wakelock = pmanager.newWakeLock(PowerManager.SCREEN_BRIGHT_WAKE_LOCK,
"Lanterna Lock");

A variável wakelock (ou atributo, sei lá como Java chama isso), foi criada anteriormente, só olhar o código inteiro para entender. Como isso é uma referência ao serviço e nada mais, ele ser recriado a cada vez que a Activity for ativada não faz diferença. O cuidado tem de se ter ao adquirir e liberar a WakeLock, que significa basicamente ativar ou desativar a trava que vai deixar o telefone dormir ou não. Eu faço isso no onPause e no onResume, desta forma a trava é adquirida na primeira vez que a Activity é iniciada e quando ela volta a ser a Activity mostrada na tela (o onResume é chamado nessas duas situações), e é liberada sempre que alguma outra coisa entra na frente (para evitar que o telefone nunca mais durma):

@Override
public void onResume() {
super.onResume();
...
/* Get the WakeLock */
this.wakelock.acquire();

E o código para liberar a trava:

@Override
public void onPause() {
super.onPause();
/* Releases the WakeLock */
this.wakelock.release();
}

Programando Androids – Parte 3

Continuando com meus posts sobre programação Android, mesmo desanimado pelo fato de não conseguir colocar minha(s) app(s) no Android Market.

Mas já que comecei, e o assunto é interessante, melhor continuar. Neste post, dando uma olhada por alto em como o Android OS é organizado e como ele gerencia a memória.

Arquitetura e Memória

O Android OS tem uma arquitetura em camadas (stacks). Os níveis mais baixos dessas camadas são por sua vez expostos para os níveis mais altos através de interfaces até a camada mais alta, onde se programa em Java.

A imagem abaixo (cortesia do google) demonstra uma visão aumentada de como estas camadas são organizadas:

Arquitetura do Android OS

Como se pode ver, o nível mais baixo do Android é o Kernel. Atualmente (versão 1.5 “cupcake”) o kernel utilizado é o Linux 2.6.27. No kernel estão também os drivers e controles básicos de hardware. A segunda camada é onde ficam as bibliotecas (libraries) e o próprio runtime do Android, incluindo aí a Dalvik Virtual Machine, encarregada de efetivamente executar o código das aplicações. A terceira camada consiste já das capacidades expostas aos desenvolvedores  para suas aplicações (gerenciador de janelas, sistema de notificação e etc). Finalmente a última camada é composta pelas aplicações propriamente ditas.

A camada de kernel é responsável também pelo controle mais fino da memória. Cada aplicação no Android roda em um processo separado, com sua própria VM, PID (número de processo) e usuário. Isso garante que caso uma aplicação dê problema, ela possa ser isolada e removida da memória sem comprometer o resto do sistema.

A Dalvik VM é a virtual machine que roda código java, mas com várias alterações para fazer isso usando menos ciclos de CPU (portanto gastando menos energia) e com otimizações de espaço/tamanho de dados. A Dalvik usa bytecode diferente da JVM tradicional e as aplicações usam um formato diferente do tradicional JAR (.jar), chamado .dex, também otimizado para menor uso de espaço.

Uma das diferenças da Dalvik é como ela mapeia a memória. Isso é feito usando um mapa memória-disco que permite que aplicações sejam rapidamente removidas da memória e depois restauradas. O G1 da T-Mobile limita cada aplicação a 16M de heap, e ainda estou tentando descobrir exatamente quanto de RAM ele tem. Algumas fontes dizem 192M, outras 64M. O fato é que a maioria das aplicações é bem menor que 16M. Quando o sistema começa a ter problemas de falta de memória o OS vai fechar aplicações que não estejam sendo exibidas, e estas aplicações podem ser retomadas depois com seus estados intactos (desde que bem programadas).

No próximo post eu vou falar um pouco sobre esses cuidados com as informações e o ciclo de vida das aplicações.