From gilmagno em gmail.com  Fri Oct  5 08:52:06 2012
From: gilmagno em gmail.com (Gil Magno)
Date: Fri, 05 Oct 2012 12:52:06 -0300
Subject: [Brasil-PM] =?utf-8?q?Contribui=C3=A7=C3=A3o_ao_Open_Data_BR_-_wi?=
 =?utf-8?q?kipoliticos=2Ecom=2Ebr?=
Message-ID: <506F0226.2070608@gmail.com>

Olá, Monges,

Acompanho várias listas de Perl, mas mais com um observador. Gosto muito
da linguagem; infelizmente no trabalho uso menos do que eu gostaria, mas
estou mudando isso.

Pesquisando para a eleições, achei uma fonte de dados muito boa no
Tribunal Superior Eleitoral. A lei 9.504 obriga os candidatos a fazerem
duas prestações de contas de suas campanhas ainda durante as eleições.
Em agosto e em setembro eles declararam quanto e de quem receberam
doações, e também com o que as gastaram.

Peguei a segunda parcial (de setembro), importei para um banco de dados
e fiz uma interface. Ela está em wikipoliticos.com.br

Nessa página podemos ver as doações feitas para as campanhas de prefeito
e vereador até o início de setembro, incluindo o nome de quem doou
(pessoas físicas, empresas etc.) e a proporção por tipo de doação
(doações de pessoas físicas, doações de empresas etc.)

Também podemos ver o quanto cada candidato declarou que gastaria, no
máximo, em sua campanha. Essa é uma informação muito importante, pois
entre setembro e o dia das eleições as doações ainda estão acontecendo,
mas a segunda prestação de contas parciais só nos dá dados até setembro.

Assim como o www.deputando.com.br e o
www.paraondefoiomeudinheiro.com.br, espero que seja uma contribuição
para o Open Data BR.

Os scripts de importação e a interface web foram escrito em Perl e
Catalyst. A escrita está ruim[1], mas não me importo; ela está atingindo
o objetivo de deixar a informação acessível, então tudo bem. Após às
eleições vou reescrevê-lo e importar mais informações.

E desculpem o relativo spam (estou mandando para muitas listas de Perl

Qualquer crítica, sugestão, contribuição é bem-vinda.

[1] github.com/gilmagno/dados-eleitorais

gil

From renato.cron em gmail.com  Fri Oct  5 08:55:34 2012
From: renato.cron em gmail.com (Renato Santos)
Date: Fri, 5 Oct 2012 12:55:34 -0300
Subject: [Brasil-PM]
	=?iso-8859-1?q?=5BCuritiba-pm=5D_Contribui=E7=E3o_ao_?=
	=?iso-8859-1?q?Open_Data_BR_-_wikipoliticos=2Ecom=2Ebr?=
In-Reply-To: <506F0226.2070608@gmail.com>
References: <506F0226.2070608@gmail.com>
Message-ID: <CABmdQ_QVuPURyzxWcKDWeTxYTvGzTfDOkDkjdW8HcdrUu=kt1Q@mail.gmail.com>

Gil++

Ficou muito legal!


Depois das eleições, teremos mais dados para poder brincar com quem passou
dos limites, ou não.


2012/10/5 Gil Magno <gilmagno em gmail.com>

> Olá, Monges,
>
> Acompanho várias listas de Perl, mas mais com um observador. Gosto muito
> da linguagem; infelizmente no trabalho uso menos do que eu gostaria, mas
> estou mudando isso.
>
> Pesquisando para a eleições, achei uma fonte de dados muito boa no
> Tribunal Superior Eleitoral. A lei 9.504 obriga os candidatos a fazerem
> duas prestações de contas de suas campanhas ainda durante as eleições.
> Em agosto e em setembro eles declararam quanto e de quem receberam
> doações, e também com o que as gastaram.
>
> Peguei a segunda parcial (de setembro), importei para um banco de dados
> e fiz uma interface. Ela está em wikipoliticos.com.br
>
> Nessa página podemos ver as doações feitas para as campanhas de prefeito
> e vereador até o início de setembro, incluindo o nome de quem doou
> (pessoas físicas, empresas etc.) e a proporção por tipo de doação
> (doações de pessoas físicas, doações de empresas etc.)
>
> Também podemos ver o quanto cada candidato declarou que gastaria, no
> máximo, em sua campanha. Essa é uma informação muito importante, pois
> entre setembro e o dia das eleições as doações ainda estão acontecendo,
> mas a segunda prestação de contas parciais só nos dá dados até setembro.
>
> Assim como o www.deputando.com.br e o
> www.paraondefoiomeudinheiro.com.br, espero que seja uma contribuição
> para o Open Data BR.
>
> Os scripts de importação e a interface web foram escrito em Perl e
> Catalyst. A escrita está ruim[1], mas não me importo; ela está atingindo
> o objetivo de deixar a informação acessível, então tudo bem. Após às
> eleições vou reescrevê-lo e importar mais informações.
>
> E desculpem o relativo spam (estou mandando para muitas listas de Perl
>
> Qualquer crítica, sugestão, contribuição é bem-vinda.
>
> [1] github.com/gilmagno/dados-eleitorais
>
> gil
> _______________________________________________
> Curitiba-pm mailing list
> Curitiba-pm em pm.org
> http://mail.pm.org/mailman/listinfo/curitiba-pm
>



-- 
Saravá,
Renato CRON
http://www.renatocron.com/blog/
@renato_cron <http://twitter.com/#!/renato_cron>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/brasil-pm/attachments/20121005/e7bfcfec/attachment.html>

From djrondon em gmail.com  Fri Oct  5 13:13:55 2012
From: djrondon em gmail.com (Rondon)
Date: Fri, 5 Oct 2012 17:13:55 -0300
Subject: [Brasil-PM]
	=?iso-8859-1?q?=5Bopendata-br=5D_Re=3A_=5BCuritiba-pm?=
	=?iso-8859-1?q?=5D_Contribui=E7=E3o_ao_Open_Data_BR_-_wikipolitico?=
	=?iso-8859-1?q?s=2Ecom=2Ebr?=
In-Reply-To: <CABmdQ_QVuPURyzxWcKDWeTxYTvGzTfDOkDkjdW8HcdrUu=kt1Q@mail.gmail.com>
References: <506F0226.2070608@gmail.com>
	<CABmdQ_QVuPURyzxWcKDWeTxYTvGzTfDOkDkjdW8HcdrUu=kt1Q@mail.gmail.com>
Message-ID: <CAKsBXgC+g+JhGo-ThOf9huSOf_SWLv98OuyiPsBZqf_QnJNT=A@mail.gmail.com>

Galera,

Se quiserem pode utilizar o modelo que fiz para as eleições no TSE em 2008
e em 2010.
http://www.tse.jus.br/hotSites/cd/tse/index.html

http://www.tse.jus.br/hotSites/cd/tse/donation.htm

http://www.cienciapolitica.com.br/elections/


A parte do financiamento eleitoral. ok. Tem a de 2008 e 2010.
Eu estou terminando um outro, mas pelos financiadores e não pelos
candidatos. Assim que tiver pronto , repassarei.

Abraços,

Rondon
---------------------------------------------------------------------------------------------
Your life is shaped by your mind and you become what you think.
Dhampada - Twin Verses.



Em 5 de outubro de 2012 12:55, Renato Santos <renato.cron em gmail.com>escreveu:

> Gil++
>
> Ficou muito legal!
>
>
> Depois das eleições, teremos mais dados para poder brincar com quem passou
> dos limites, ou não.
>
>
> 2012/10/5 Gil Magno <gilmagno em gmail.com>
>
>>  Olá, Monges,
>>
>> Acompanho várias listas de Perl, mas mais com um observador. Gosto muito
>> da linguagem; infelizmente no trabalho uso menos do que eu gostaria, mas
>> estou mudando isso.
>>
>> Pesquisando para a eleições, achei uma fonte de dados muito boa no
>> Tribunal Superior Eleitoral. A lei 9.504 obriga os candidatos a fazerem
>> duas prestações de contas de suas campanhas ainda durante as eleições.
>> Em agosto e em setembro eles declararam quanto e de quem receberam
>> doações, e também com o que as gastaram.
>>
>> Peguei a segunda parcial (de setembro), importei para um banco de dados
>> e fiz uma interface. Ela está em wikipoliticos.com.br
>>
>> Nessa página podemos ver as doações feitas para as campanhas de prefeito
>> e vereador até o início de setembro, incluindo o nome de quem doou
>> (pessoas físicas, empresas etc.) e a proporção por tipo de doação
>> (doações de pessoas físicas, doações de empresas etc.)
>>
>> Também podemos ver o quanto cada candidato declarou que gastaria, no
>> máximo, em sua campanha. Essa é uma informação muito importante, pois
>> entre setembro e o dia das eleições as doações ainda estão acontecendo,
>> mas a segunda prestação de contas parciais só nos dá dados até setembro.
>>
>> Assim como o www.deputando.com.br e o
>> www.paraondefoiomeudinheiro.com.br, espero que seja uma contribuição
>> para o Open Data BR.
>>
>> Os scripts de importação e a interface web foram escrito em Perl e
>> Catalyst. A escrita está ruim[1], mas não me importo; ela está atingindo
>> o objetivo de deixar a informação acessível, então tudo bem. Após às
>> eleições vou reescrevê-lo e importar mais informações.
>>
>> E desculpem o relativo spam (estou mandando para muitas listas de Perl
>>
>> Qualquer crítica, sugestão, contribuição é bem-vinda.
>>
>> [1] github.com/gilmagno/dados-eleitorais
>>
>> gil
>> _______________________________________________
>> Curitiba-pm mailing list
>> Curitiba-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/curitiba-pm
>>
>
>
>
> --
> Saravá,
> Renato CRON
>  http://www.renatocron.com/blog/
> @renato_cron <http://twitter.com/#!/renato_cron>
>
>  --
> Para maiores informações:
> http://www.opendatabr.org/
> http://groups.google.com/group/opendata-br?hl=en
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/brasil-pm/attachments/20121005/6bc61736/attachment.html>

From thiago em aware.com.br  Sat Oct  6 04:38:50 2012
From: thiago em aware.com.br (Thiago Rondon)
Date: Sat, 6 Oct 2012 08:38:50 -0300
Subject: [Brasil-PM]
 =?utf-8?q?=5Bopendata-br=5D_Contribui=C3=A7=C3=A3o_ao?=
 =?utf-8?q?_Open_Data_BR_-_wikipoliticos=2Ecom=2Ebr?=
In-Reply-To: <506F0226.2070608@gmail.com>
References: <506F0226.2070608@gmail.com>
Message-ID: <660EDAFE428A49CDAF6457303807E7C6@aware.com.br>


Gil Magno,

Muito bacana o teu projeto, parabéns pela iniciativa!

E eu faço um convite para você, para você participar do evento que estamos trabalhando que é o YAPC::Brasil::2012 - A Revolução dos dados, http://yapcbrasil.org.br/2012/

Você não quer oferecer um lightning talk sobre o teu projeto no evento ?

Abs!
-Thiago Rondon




On Friday, October 5, 2012 at 12:52 PM, Gil Magno wrote:

> Olá, Monges,
>  
> Acompanho várias listas de Perl, mas mais com um observador. Gosto muito
> da linguagem; infelizmente no trabalho uso menos do que eu gostaria, mas
> estou mudando isso.
>  
> Pesquisando para a eleições, achei uma fonte de dados muito boa no
> Tribunal Superior Eleitoral. A lei 9.504 obriga os candidatos a fazerem
> duas prestações de contas de suas campanhas ainda durante as eleições.
> Em agosto e em setembro eles declararam quanto e de quem receberam
> doações, e também com o que as gastaram.
>  
> Peguei a segunda parcial (de setembro), importei para um banco de dados
> e fiz uma interface. Ela está em wikipoliticos.com.br
>  
> Nessa página podemos ver as doações feitas para as campanhas de prefeito
> e vereador até o início de setembro, incluindo o nome de quem doou
> (pessoas físicas, empresas etc.) e a proporção por tipo de doação
> (doações de pessoas físicas, doações de empresas etc.)
>  
> Também podemos ver o quanto cada candidato declarou que gastaria, no
> máximo, em sua campanha. Essa é uma informação muito importante, pois
> entre setembro e o dia das eleições as doações ainda estão acontecendo,
> mas a segunda prestação de contas parciais só nos dá dados até setembro.
>  
> Assim como o www.deputando.com.br (http://www.deputando.com.br) e o
> www.paraondefoiomeudinheiro.com.br (http://www.paraondefoiomeudinheiro.com.br), espero que seja uma contribuição
> para o Open Data BR.
>  
> Os scripts de importação e a interface web foram escrito em Perl e
> Catalyst. A escrita está ruim[1], mas não me importo; ela está atingindo
> o objetivo de deixar a informação acessível, então tudo bem. Após às
> eleições vou reescrevê-lo e importar mais informações.
>  
> E desculpem o relativo spam (estou mandando para muitas listas de Perl
>  
> Qualquer crítica, sugestão, contribuição é bem-vinda.
>  
> [1] github.com/gilmagno/dados-eleitorais (http://github.com/gilmagno/dados-eleitorais)
>  
> gil
>  
> --  
> Para maiores informações:  
> http://www.opendatabr.org/
> http://groups.google.com/group/opendata-br?hl=en




From gilmagno em gmail.com  Tue Oct  9 02:43:25 2012
From: gilmagno em gmail.com (Gil Magno)
Date: Tue, 09 Oct 2012 06:43:25 -0300
Subject: [Brasil-PM]
 =?utf-8?q?Contribui=C3=A7=C3=A3o_ao_Open_Data_BR_-_wi?=
 =?utf-8?q?kipoliticos=2Ecom=2Ebr?=
In-Reply-To: <506F0226.2070608@gmail.com>
References: <506F0226.2070608@gmail.com>
Message-ID: <5073F1BD.3010305@gmail.com>

Valeu, pessoal. O projeto é aberto pra contribuições e sugestões.

E, mais uma vez, desculpem o relativo spam (e-mail pra muitas listas),
mas as eleições estavam chegando, e as informações da página poderiam
ajudar alguém que estivesse em dúvida.

Abraços,

From gilmagno em gmail.com  Tue Oct  9 02:43:37 2012
From: gilmagno em gmail.com (Gil Magno)
Date: Tue, 09 Oct 2012 06:43:37 -0300
Subject: [Brasil-PM]
 =?utf-8?q?Contribui=C3=A7=C3=A3o_ao_Open_Data_BR_-_wi?=
 =?utf-8?q?kipoliticos=2Ecom=2Ebr?=
In-Reply-To: <660EDAFE428A49CDAF6457303807E7C6@aware.com.br>
References: <506F0226.2070608@gmail.com>
	<660EDAFE428A49CDAF6457303807E7C6@aware.com.br>
Message-ID: <5073F1C9.80305@gmail.com>

Thiago Rondon, 2012-10-06:
> E eu faço um convite para você, para você participar do evento que estamos trabalhando que é o YAPC::Brasil::2012 - A Revolução dos dados, http://yapcbrasil.org.br/2012/
> Você não quer oferecer um lightning talk sobre o teu projeto no evento ?
> Abs!
> -Thiago Rondon

Opa Thiago,

Fico alegre com o convite. Eu já estava querendo ir pra o YAPC, mas
estava incerto. Seria um prazer poder contribuir de alguma forma com o
evento.

Quanto tempo tem um lightning talk?

Abraço,

From thiago em aware.com.br  Tue Oct  9 06:26:23 2012
From: thiago em aware.com.br (Thiago Rondon)
Date: Tue, 9 Oct 2012 10:26:23 -0300
Subject: [Brasil-PM]
 =?utf-8?q?Contribui=C3=A7=C3=A3o_ao_Open_Data_BR_-_wi?=
 =?utf-8?q?kipoliticos=2Ecom=2Ebr?=
In-Reply-To: <5073F1C9.80305@gmail.com>
References: <506F0226.2070608@gmail.com>
	<660EDAFE428A49CDAF6457303807E7C6@aware.com.br>
	<5073F1C9.80305@gmail.com>
Message-ID: <48A9C395B4774EA498C0240FBAB220FA@aware.com.br>

On Tuesday, October 9, 2012 at 6:43 AM, Gil Magno wrote:
> Thiago Rondon, 2012-10-06:
> > E eu faço um convite para você, para você participar do evento que estamos trabalhando que é o YAPC::Brasil::2012 - A Revolução dos dados, http://yapcbrasil.org.br/2012/
> > Você não quer oferecer um lightning talk sobre o teu projeto no evento ?
> >  
>  
>  

Nós iremos abrir no sábado um momento, para que as pessoas que estejam participando no evento possam realiazar estas palestras relâmpago. Ou seja, quem quiser, quem tiver lá, é só entrar na fila na frente do palco, e esperar sua vez. :-)

O tempo é de 5 minutos.

O interessante que dentro do YAPC no sábado, estará o pessoal da HacksHackers (grupo de jornalistas e desenvolvedores interessados em dados abertos) e o concurso Decoders (que é um evento que tem como objetivo fomentar a criação de ferramentas como a tua, e que seria muito interessante para as pessoas verem o teu aplicativo).

Abs!
-Thiago Rondon  



From nferraz em gmail.com  Tue Oct  9 08:07:12 2012
From: nferraz em gmail.com (Nelson Ferraz)
Date: Tue, 9 Oct 2012 17:07:12 +0200
Subject: [Brasil-PM] =?iso-8859-1?q?Concurso_dar=E1_R=24_15_mil_a_hacker_q?=
	=?iso-8859-1?q?ue_ajudar_a_combater_corru=E7=E3o?=
Message-ID: <CAG+zsv2akV4grrLK37F62hOiQxA4TCBeQf62HmVCJqN+Yqe0ig@mail.gmail.com>

A 15ª Conferência Internacional Anticorrupção (IACC) abriu inscrições
para o ?IACC Hackathon?, concurso que premiará as melhores iniciativas
tecnológicas para solucionar problemas ligados à corrupção.

Podem participar programadores que criarem sites, aplicativos de redes
sociais, aplicativos de smartphones, máquinas e soluções de hardware
ou ainda qualquer pessoa que tenha ideias ligadas à corrupção e
transparência que possam ser discutidas no IACC Hackathon.

Entre os principais temas que podem inspirar os projetos, segundo a
organização do prêmio, estão o acesso a informações sobre uso de
verbas públicas ou novas legislações; pesquisa de conjuntos de dados
sobre questões relacionadas à corrupção; visualização de dados sobre
conscientização; eficiência na comunicação da política; crowdsourcing
para organizações anticorrupção, ente outros.

Além da premiação de 6 mil euros, equivalente a mais de R$ 15 mil,
para apoiar a viabilização do projeto vencedor, outros participantes
poderão ser convidados para participar da 15ª edição do IACC.
Considerado o principal encontro mundial sobre corrupção, o fórum
reúne chefes de estado, sociedade civil e representantes dos setores
público e privado, e ocorrerá em Brasília (DF), de 7 a 10 de novembro.

Para participar, inscreva sua ideia neste site:
http://15iacc.org/get-involved/iacc-hackathon/hackathon-problem-proposal/

http://olhardigital.uol.com.br/negocios/digital_news/noticias/concurso-dara-r-15-mil-a-hacker-que-ajudar-a-combater-corrucao

From thiago em aware.com.br  Wed Oct 10 12:34:25 2012
From: thiago em aware.com.br (Thiago Rondon)
Date: Wed, 10 Oct 2012 16:34:25 -0300
Subject: [Brasil-PM] YAPC::Brasil::2012 -- Falta pouco! Nos ajude a divulgar!
Message-ID: <DAA6485B96A4401DAE44AAB0B1A91184@aware.com.br>


Pessoal,

Nosso evento tá saindo do forno, estamos correndo para fazer um YAPC diferente, experimental, para re-encontrar pessoas presencialmente da comunidade, assim como para conhecermos outras.

Se você quiser nos ajudar em alguma coisa com a organização do evento, participe da nossa lista de discussão. [1]

Estamos procurando formas de divulgar o evento, fechar pacotes dentro de empresas e universidades para participações com desconto por inscrito !  

Peço a ajuda de todos, para divulgar nosso evento, em todos os meios que forem possível! Há um release que o Leonardo preparou e já foi divulgado na BR-Linux. [2].

[1]https://groups.google.com/forum/?hl=pt-BR&fromgroups#!forum/yapc-brasil-coord

[2]http://br-linux.org/2012/inscricoes-abertas-para-a-yapcbrasil-2012-a-revolucao-dos-dados/

abs!
-Thiago Rondon



From gabriel.vieira em gmail.com  Wed Oct 10 14:18:21 2012
From: gabriel.vieira em gmail.com (Gabriel Vieira)
Date: Wed, 10 Oct 2012 18:18:21 -0300
Subject: [Brasil-PM] YAPC::Brasil 2012 - Parceria com o 155 Hotel
In-Reply-To: <CAFeYYazW03SVcT63_0VeENiQZ5VZhvQNS0eF0iL6FYv0RLv0qw@mail.gmail.com>
References: <CAFeYYazW03SVcT63_0VeENiQZ5VZhvQNS0eF0iL6FYv0RLv0qw@mail.gmail.com>
Message-ID: <CAFeYYaxie2uzRuNjF-oYwZx0dhLSufDJkbZiGZ-1=rhUXPZzSw@mail.gmail.com>

O YAPC::Brasil 2012 (http://www.yapcbrasil.org.br/2012) conseguiu preços
diferenciados no 155 Hotel (http://www.155hotel.com.br/), localizado a
apenas 850 metros do Shopping Frei Caneca (http://goo.gl/maps/UfHup).

As diárias diárias serão de apenas R$ 140,00, sem cobrança de impostos ou
taxa de serviço, para uma ou duas pessoas, com check-in às 14h e check-out
às 13h, com café da manhã, sendo de 2ª a 6ª feira das 06h30 às 10h30 e aos
sábados e domingos das 06h30 às 12h00.

********************************************
Como garantir o desconto:
1) Acessar http://www.155hotel.com.br/ e realizar a reserva online (não se
preocupe com o valor apresentado, o pagamento é efetuado apenas na hora do
check in);
2) Ao chegar ao hotel e realizar o check in, apresentar o comprovante de
inscrição no YAPC::Brasil 2012, será informado o valor total já com o
desconto.

Observações:
1) Não será fornecido desconto a quem não apresentar o comprovante de
inscrição no YAPC::Brasil 2012;
2) Não haverá devolução de dinheiro para quem realizar a inscrição no
YAPC::Brasil 2012 após feito o check in;
3) Acredito que a reserva poderá ser realizada também pelo telefone (11)
3150 1555.
********************************************

Informações retiradas do site do Hotel:

-------------------------------------------------------
155 HOTEL - São Paulo

Conforto e Praticidade por preço Justo

Um cantinho tranquilo no meio da correria de São Paulo, o 155 Hotel
trabalha com o conceito de Low Cost de hotel econômico, oferecendo
praticidade e comodidade a um baixo custo. Está localizado no bairro
Consolação nas proximidades da famosa rua Augusta, o hotel é uma
aconchegante opção para quem busca um quarto confortável para desfrutar de
São Paulo e que não fique pesado no bolso.

Além de oferecer aos seus hóspedes um espaço incomparável em São Paulo, o
Hotel 155 busca através de novas tecnologias de inteligência ambiental
manter-se como uma instituição sustentável com o reuso das águas da chuva e
também sistema economizador de energia. Juntos estes fatores permitem  o
155 a ser um hotel econômico, oferecendo um preço justo aos visitantes da
cidade de São Paulo.

Todos os quartos dispõe de:
- TV LCD 32" com SKY
- Internet wireless grátis
- Ar condicionado inteligente
- Frigobar
- Janelas Antirruido
- Cama box spring
- Roupa de cama antialérgica
- Cofre digital
- Fechadura eletrônica
- Estação de trabalho
- Detector de fumaça (100% antifumo)
- Água do chuveiro aquecida a gás
-------------------------------------------------------


-- 
Gabriel Vieira
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/brasil-pm/attachments/20121010/54b1e7a2/attachment.html>

From gabriel.vieira em gmail.com  Thu Oct 11 11:20:17 2012
From: gabriel.vieira em gmail.com (Gabriel Vieira)
Date: Thu, 11 Oct 2012 15:20:17 -0300
Subject: [Brasil-PM] [SP-pm] YAPC::Brasil 2012 - Parceria com o 155 Hotel
In-Reply-To: <CAMQCFAHSXNj=7u7wmRn19bwkxgSdMN1r-jBmDtY9k6gQ3eF59A@mail.gmail.com>
References: <CAFeYYazW03SVcT63_0VeENiQZ5VZhvQNS0eF0iL6FYv0RLv0qw@mail.gmail.com>
	<CAMQCFAHSXNj=7u7wmRn19bwkxgSdMN1r-jBmDtY9k6gQ3eF59A@mail.gmail.com>
Message-ID: <CAFeYYaxzU0mX2WDr48nW8K5GieF_XFvQpHnNBUyXntsm8ZUH-w@mail.gmail.com>

Atenção!

Não será mais necessário apresentar comprovante de inscrição no
YAPC::Brasil 2012 ao hotel.

Enviaremos a lista dos participantes para que eles possam gerenciar as
reservas.

De tal forma, para garantir diárias de R$ 140,00 basta se inscrever no
YAPC::Brasil 2012 (http://www.yapcbrasil.org.br/) e realizar a reserva
online (http://www.155hotel.com.br/) ou por telefone (11) 3150 1555 - opção
2.

No hora do checkin, informar que o nome consta na lista de participantes do
evento.

2012/10/10 Nilson Santos Figueiredo Jr. <acid06 em gmail.com>

> Dúvida: o que vem a ser o comprovante de inscrição no YAPC::Brasil 2012?
> Eu fiz minha inscrição mas não tenho nenhum comprovante.
>
> -Nilson
>
> 2012/10/10 Gabriel Vieira <gabriel.vieira em gmail.com>:
> > O YAPC::Brasil 2012 (http://www.yapcbrasil.org.br/2012) conseguiu preços
> > diferenciados no 155 Hotel (http://www.155hotel.com.br/), localizado a
> > apenas 850 metros do Shopping Frei Caneca (http://goo.gl/maps/UfHup).
> >
> > As diárias diárias serão de apenas R$ 140,00, sem cobrança de impostos ou
> > taxa de serviço, para uma ou duas pessoas, com check-in às 14h e
> check-out
> > às 13h, com café da manhã, sendo de 2ª a 6ª feira das 06h30 às 10h30 e
> aos
> > sábados e domingos das 06h30 às 12h00.
> >
> > ********************************************
> > Como garantir o desconto:
> > 1) Acessar http://www.155hotel.com.br/ e realizar a reserva online (não
> se
> > preocupe com o valor apresentado, o pagamento é efetuado apenas na hora
> do
> > check in);
> > 2) Ao chegar ao hotel e realizar o check in, apresentar o comprovante de
> > inscrição no YAPC::Brasil 2012, será informado o valor total já com o
> > desconto.
> >
> > Observações:
> > 1) Não será fornecido desconto a quem não apresentar o comprovante de
> > inscrição no YAPC::Brasil 2012;
> > 2) Não haverá devolução de dinheiro para quem realizar a inscrição no
> > YAPC::Brasil 2012 após feito o check in;
> > 3) Acredito que a reserva poderá ser realizada também pelo telefone (11)
> > 3150 1555.
> > ********************************************
> >
> > Informações retiradas do site do Hotel:
> >
> > -------------------------------------------------------
> > 155 HOTEL - São Paulo
> >
> > Conforto e Praticidade por preço Justo
> >
> > Um cantinho tranquilo no meio da correria de São Paulo, o 155 Hotel
> trabalha
> > com o conceito de Low Cost de hotel econômico, oferecendo praticidade e
> > comodidade a um baixo custo. Está localizado no bairro Consolação nas
> > proximidades da famosa rua Augusta, o hotel é uma aconchegante opção para
> > quem busca um quarto confortável para desfrutar de São Paulo e que não
> fique
> > pesado no bolso.
> >
> > Além de oferecer aos seus hóspedes um espaço incomparável em São Paulo, o
> > Hotel 155 busca através de novas tecnologias de inteligência ambiental
> > manter-se como uma instituição sustentável com o reuso das águas da
> chuva e
> > também sistema economizador de energia. Juntos estes fatores permitem  o
> 155
> > a ser um hotel econômico, oferecendo um preço justo aos visitantes da
> cidade
> > de São Paulo.
> >
> > Todos os quartos dispõe de:
> > - TV LCD 32" com SKY
> > - Internet wireless grátis
> > - Ar condicionado inteligente
> > - Frigobar
> > - Janelas Antirruido
> > - Cama box spring
> > - Roupa de cama antialérgica
> > - Cofre digital
> > - Fechadura eletrônica
> > - Estação de trabalho
> > - Detector de fumaça (100% antifumo)
> > - Água do chuveiro aquecida a gás
> > -------------------------------------------------------
> >
> >
> > --
> > Gabriel Vieira
> >
> > =begin disclaimer
> >    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
> >  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> > =end disclaimer
> >
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>



-- 
Gabriel Vieira
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/brasil-pm/attachments/20121011/cae50895/attachment.html>

From gabriel.vieira em gmail.com  Thu Oct 18 08:28:58 2012
From: gabriel.vieira em gmail.com (Gabriel Vieira)
Date: Thu, 18 Oct 2012 12:28:58 -0300
Subject: [Brasil-PM] [SP-pm] YAPC::Brasil 2012 - Parceria com o 155 Hotel
In-Reply-To: <CAFeYYaxzU0mX2WDr48nW8K5GieF_XFvQpHnNBUyXntsm8ZUH-w@mail.gmail.com>
References: <CAFeYYazW03SVcT63_0VeENiQZ5VZhvQNS0eF0iL6FYv0RLv0qw@mail.gmail.com>
	<CAMQCFAHSXNj=7u7wmRn19bwkxgSdMN1r-jBmDtY9k6gQ3eF59A@mail.gmail.com>
	<CAFeYYaxzU0mX2WDr48nW8K5GieF_XFvQpHnNBUyXntsm8ZUH-w@mail.gmail.com>
Message-ID: <CAFeYYaxTBjUgeKgfu=vXr78-wRG3nwWDmyBGryhAOUZ_7u260g@mail.gmail.com>

Senhores e senhoras.

Os quartos já estão liberados. Existe uma lista temporária no saguão, basta
informar  o nome para conseguir o valor da diária com desconto.

<Opinião Pessoal>
Com certeza é o melhor custo x benefício da região. Excelente hotel com um
preço bem bacana.
</Opinião Pessoal>

2012/10/11 Gabriel Vieira <gabriel.vieira em gmail.com>

> Atenção!
>
> Não será mais necessário apresentar comprovante de inscrição no
> YAPC::Brasil 2012 ao hotel.
>
> Enviaremos a lista dos participantes para que eles possam gerenciar as
> reservas.
>
> De tal forma, para garantir diárias de R$ 140,00 basta se inscrever no
> YAPC::Brasil 2012 (http://www.yapcbrasil.org.br/) e realizar a reserva
> online (http://www.155hotel.com.br/) ou por telefone (11) 3150 1555 -
> opção 2.
>
> No hora do checkin, informar que o nome consta na lista de participantes
> do evento.
>
> 2012/10/10 Nilson Santos Figueiredo Jr. <acid06 em gmail.com>
>
> Dúvida: o que vem a ser o comprovante de inscrição no YAPC::Brasil 2012?
>> Eu fiz minha inscrição mas não tenho nenhum comprovante.
>>
>> -Nilson
>>
>> 2012/10/10 Gabriel Vieira <gabriel.vieira em gmail.com>:
>> > O YAPC::Brasil 2012 (http://www.yapcbrasil.org.br/2012) conseguiu
>> preços
>> > diferenciados no 155 Hotel (http://www.155hotel.com.br/), localizado a
>> > apenas 850 metros do Shopping Frei Caneca (http://goo.gl/maps/UfHup).
>> >
>> > As diárias diárias serão de apenas R$ 140,00, sem cobrança de impostos
>> ou
>> > taxa de serviço, para uma ou duas pessoas, com check-in às 14h e
>> check-out
>> > às 13h, com café da manhã, sendo de 2ª a 6ª feira das 06h30 às 10h30 e
>> aos
>> > sábados e domingos das 06h30 às 12h00.
>> >
>> > ********************************************
>> > Como garantir o desconto:
>> > 1) Acessar http://www.155hotel.com.br/ e realizar a reserva online
>> (não se
>> > preocupe com o valor apresentado, o pagamento é efetuado apenas na hora
>> do
>> > check in);
>> > 2) Ao chegar ao hotel e realizar o check in, apresentar o comprovante de
>> > inscrição no YAPC::Brasil 2012, será informado o valor total já com o
>> > desconto.
>> >
>> > Observações:
>> > 1) Não será fornecido desconto a quem não apresentar o comprovante de
>> > inscrição no YAPC::Brasil 2012;
>> > 2) Não haverá devolução de dinheiro para quem realizar a inscrição no
>> > YAPC::Brasil 2012 após feito o check in;
>> > 3) Acredito que a reserva poderá ser realizada também pelo telefone (11)
>> > 3150 1555.
>> > ********************************************
>> >
>> > Informações retiradas do site do Hotel:
>> >
>> > -------------------------------------------------------
>> > 155 HOTEL - São Paulo
>> >
>> > Conforto e Praticidade por preço Justo
>> >
>> > Um cantinho tranquilo no meio da correria de São Paulo, o 155 Hotel
>> trabalha
>> > com o conceito de Low Cost de hotel econômico, oferecendo praticidade e
>> > comodidade a um baixo custo. Está localizado no bairro Consolação nas
>> > proximidades da famosa rua Augusta, o hotel é uma aconchegante opção
>> para
>> > quem busca um quarto confortável para desfrutar de São Paulo e que não
>> fique
>> > pesado no bolso.
>> >
>> > Além de oferecer aos seus hóspedes um espaço incomparável em São Paulo,
>> o
>> > Hotel 155 busca através de novas tecnologias de inteligência ambiental
>> > manter-se como uma instituição sustentável com o reuso das águas da
>> chuva e
>> > também sistema economizador de energia. Juntos estes fatores permitem
>>  o 155
>> > a ser um hotel econômico, oferecendo um preço justo aos visitantes da
>> cidade
>> > de São Paulo.
>> >
>> > Todos os quartos dispõe de:
>> > - TV LCD 32" com SKY
>> > - Internet wireless grátis
>> > - Ar condicionado inteligente
>> > - Frigobar
>> > - Janelas Antirruido
>> > - Cama box spring
>> > - Roupa de cama antialérgica
>> > - Cofre digital
>> > - Fechadura eletrônica
>> > - Estação de trabalho
>> > - Detector de fumaça (100% antifumo)
>> > - Água do chuveiro aquecida a gás
>> > -------------------------------------------------------
>> >
>> >
>> > --
>> > Gabriel Vieira
>> >
>> > =begin disclaimer
>> >    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>> >  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>> >  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> > =end disclaimer
>> >
>> =begin disclaimer
>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>>
>
>
>
> --
> Gabriel Vieira
>



-- 
Gabriel Vieira
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/brasil-pm/attachments/20121018/81e4322c/attachment.html>

From nuba em fastmail.fm  Mon Oct 29 09:25:36 2012
From: nuba em fastmail.fm (Nuba Princigalli)
Date: Mon, 29 Oct 2012 14:25:36 -0200
Subject: [Brasil-PM] =?iso-8859-1?q?Fwd=3A_=5BRio-pm=5D_Quack_=26_Hack_Rio?=
 =?iso-8859-1?q?_--_Ter=E7a=2C_30/out=2C_Starbucks_Rio_Sul?=
References: <1351527174.12630.140661146865453.5B9050DA@webmail.messagingengine.com>
Message-ID: <1351527936.15632.140661146871369.4B066940@webmail.messagingengine.com>

Caros,

Encaminhando a chamada, caso alguém esteja no Rio amanhã! :)

Abraço,

Nuba

----- Original message -----
From: Nuba Princigalli <[1]nuba em fastmail.fm>
To: Perl Mongers Rio de Janeiro <[2]rio-pm em pm.org>
Subject: [Rio-pm] Quack & Hack Rio -- Terça, 30/out, Starbucks Rio Sul
Date: Mon, 29 Oct 2012 14:12:54 -0200

Pessoal,

Esta é a chamada pro....

Quack & Hack Rio

[3][duckduckgo_128x128.png]

(For the english version, skip to the end)

Faremos amanhã um Hackathon impromptu, no formato Quack & Hack ,
conduzido pelo Torsten Raudssus (Getty) , do DuckDuckGo (DDG), que está
de passagem por aqui, após apresentar no YAPC::Brasil + ConferênciaWeb
W3C em São Paulo na semana passada!

Dia e Horário: Amanhã. terça-feira, 30/10/2012, a partir das 4pm
Local: Starbucks do Shopping Rio
Sul [4]http://www.starbucks.com.br/store/20310/
Shopping Rio Sul: [5]http://www.riosul.com.br/
Mapa: [6]http://goo.gl/maps/fCyHr
Esta chamada, online: [7]http://rio.pm.org/quack-and-hack

DDG é uma startup que está se diferenciando e encontrando tração no
setor de busca, com uma stack surpreendentemente simples (perl, nginx,
postgresql, freebsd, memcached) e uma atitude muito
bacana: [8]https://duckduckgo.com/about.html [9]http://dontbubble.us/ [
10]http://donttrack.us/

Quack & Hack é uma iniciativa do DDG para a divulgação e promoção do
Perl. A idéia é agregar interessados, iniciantes e veteranos para
juntos caolocarmos a mão na massa, trocar dicas e figurinhas, seja
contribuindo com as iniciativas opensource do DDG
( [11]https://github.com/duckduckgo), seja tocando os projetos
próprios. Uma linha em que o Getty está especialmente interessado em
discutir e trabalhar é na internacionalização do DDG, para facilitar
com que sua interface seja localizada para outros idiomas.

Seguem alguns links interessantes sobre DDG:
 1. [12]https://duckduckgo.com/traffic.html
 2. [13]http://www.quora.com/DuckDuckGo-company
 3. [14]https://en.wikipedia.org/wiki/Duck_Duck_Go#Reception
 4. [15]http://www.gabrielweinberg.com/blog/2009/03/duck-duck-go-archit
    ecture.html

Abraço, e até lá!

Nuba Princigalli
Rio de Janeiro Perl Mongers
  __________________________________________________________________

(English version)

Quack & Hack Rio

[16][duckduckgo_128x128.png]


We'll hold tomorrow an impromtu Quack & Hack hackathon, conducted by
Torsten Raudssus (Getty) from DuckDuckGo (DDG), who's visiting Rio de
Janeiro after presenting at YAPC::Brasil + ConferenciaWeb W3C in Sao
Paulo last week.

When: Amanhã. terça-feira, 30/10/2012, a partir das 4pm
Where : Starbucks do Shopping Rio
Sul [17]http://www.starbucks.com.br/store/20310/
Shopping Rio Sul: [18]http://www.riosul.com.br/
Map: [19]http://goo.gl/maps/fCyHr
This announcement, online: [20]http://rio.pm.org/quack-and-hack

DDG is a startups which is differentiating itself, and finding traction
in the search sector, with a surprisingly simple stack (perl, nginx,
postgresql, freebsd, memcached) and a very cool
attitude:[21]https://duckduckgo.com/about.html [22]http://dontbubble.us
/ [23]http://donttrack.us/

Quack & Hack is a DDG initiative to divulge and promote Perl. The idea
is to have a gathering of people interested in Perl from all levels,
beginners and veterans, and get hands-on together, exchanging tips and
tricks, while contributing to DDG's opensource initiatives
( [24]https://github.com/duckduckgo ) or hacking on our own things.
Something Getty is pretty much interested right now it in discussing
and working in DDG internationalization, to make it easier for it to be
localized into other languages.

Below are some interesting links about DDG:
 5. [25]https://duckduckgo.com/traffic.html
 6. [26]http://www.quora.com/DuckDuckGo-company
 7. [27]https://en.wikipedia.org/wiki/Duck_Duck_Go#Reception
 8. [28]http://www.gabrielweinberg.com/blog/2009/03/duck-duck-go-archit
    ecture.html

See you there!

Nuba Princigalli
Rio de Janeiro Perl Mongers






--
Nuba R. Princigalli [29]nuba em pauleira.com http://pauleira.com
@nprincigalli
Discipline is not an end in itself, just a means to an end. - King
Crimson
_______________________________________________
Rio-pm mailing list
[30]Rio-pm em pm.org
[31]http://mail.pm.org/mailman/listinfo/rio-pm

References

1. mailto:nuba em fastmail.fm
2. mailto:rio-pm em pm.org
3. https://duckduckgo.com/
4. http://www.starbucks.com.br/store/20310/
5. http://www.riosul.com.br/
6. http://goo.gl/maps/fCyHr
7. http://rio.pm.org/quack-and-hack
8. https://duckduckgo.com/about.html
9. http://dontbubble.us/
  10. http://donttrack.us/
  11. https://github.com/duckduckgo
  12. https://duckduckgo.com/traffic.html
  13. http://www.quora.com/DuckDuckGo-company
  14. https://en.wikipedia.org/wiki/Duck_Duck_Go#Reception
  15. http://www.gabrielweinberg.com/blog/2009/03/duck-duck-go-architecture.html
  16. https://duckduckgo.com/
  17. http://www.starbucks.com.br/store/20310/
  18. http://www.riosul.com.br/
  19. http://goo.gl/maps/fCyHr
  20. http://rio.pm.org/quack-and-hack
  21. https://duckduckgo.com/about.html
  22. http://dontbubble.us/
  23. http://donttrack.us/
  24. https://github.com/duckduckgo
  25. https://duckduckgo.com/traffic.html
  26. http://www.quora.com/DuckDuckGo-company
  27. https://en.wikipedia.org/wiki/Duck_Duck_Go#Reception
  28. http://www.gabrielweinberg.com/blog/2009/03/duck-duck-go-architecture.html
  29. mailto:nuba em pauleira.com
  30. mailto:Rio-pm em pm.org
  31. http://mail.pm.org/mailman/listinfo/rio-pm
--
Nuba R. Princigalli  nuba em pauleira.com  http://pauleira.com  @nprincigalli
Discipline is not an end in itself, just a means to an end. - King Crimson

-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/brasil-pm/attachments/20121029/ba579b42/attachment.html>

From breno em rio.pm.org  Sun Dec  2 21:50:14 2012
From: breno em rio.pm.org (breno)
Date: Mon, 3 Dec 2012 03:50:14 -0200
Subject: [Brasil-PM] Perl Advent Calendar 2012
In-Reply-To: <CAHS-WQafeVwcV1y3sRkqtLBQmPdTSRh9x3SK2ibhcitqVMfjbA@mail.gmail.com>
References: <CAHS-WQafeVwcV1y3sRkqtLBQmPdTSRh9x3SK2ibhcitqVMfjbA@mail.gmail.com>
Message-ID: <CAHS-WQb3bKR-yAXS2qn5eORFiJt13R3RUrBq_YCiNKjrJ25bcw@mail.gmail.com>

Desde o ano 2000, todo mês de Dezembro a comunidade Perl internacional
organiza um "calendário do advento natalino", com uma dica de
desenvolvimento em Perl por dia, do dia 1 ao dia 25 de dezembro. Os
artigos são curtos e cobrem algum ponto interessante da linguagem ou
algum módulo bacana disponível no CPAN.

Pois bem, este ano não podia ser diferente, e o calendário de 2012 já
está no ar, sendo organizado por ninguém menos que o próprio
"pumpking", Ricardo Signes!

Estamos no dia 3, e os artigos até agora cobrem Path::Class, switches
de linha de comando para o 'perl', e Scope::Upper. Para acompanhar,
basta acessar:

http://perladvent.org

ou assinar o feed em:

http://perladvent.org/2012/atom.xml

Boas Festas!


[]s

-b

From breno em rio.pm.org  Wed Dec  5 20:39:13 2012
From: breno em rio.pm.org (breno)
Date: Thu, 6 Dec 2012 02:39:13 -0200
Subject: [Brasil-PM] =?iso-8859-1?q?voc=EA_confia_na_ordem_das_chaves_de_u?=
	=?iso-8859-1?q?m_hash=3F?=
Message-ID: <CAHS-WQZsOksc=9vf=Hw+2pTVDbJZgCASUti4kNHm3DpGe7jzOQ@mail.gmail.com>

(do original em:
http://onionstand.blogspot.com.br/2012/12/are-you-relying-on-hash-keys-being.html)

tl;dr
------

Se você pretende eventualmente migrar para o 5.18, faça isso *agora*:

   1. Instale o 5.17.6 (você usa perlbrew[1], certo?);
   2. Experimente seus módulos e aplicativos nele (você tem testes, certo?);
   3. Se alguma coisa quebrar, é porque provavelmente algo está
dependendo dos valores de keys(), values() ou each() estarem em um
ordem particular. Você realmente não deveria estar fazendo isso, então
use sort() ou coisa que o valha nesses valores :)
   4.  Se algum módulo do CPAN que você usa falhar no 5.17.6,
certifique-se de que o autor está ciente e preparando um patch;
   5.  Divulgue!



Sobre Hashes e Segurança
======================

O "core team" do Perl 5 sempre coloca segurança como uma de suas
maiores prioridades. Para termos noção, no final de 2011 um ataque de
negação de serviços remoto explorando complexidade
algorítmica[2][3][4][5] foi descoberto em importantes implementações
de linguagens como PHP, Ruby, Python, Java, até mesmo JavaScript. Essa
vulnerabilidade havia sido corrigida no Perl 5 desde... 2003.


Isso foi antes. E agora?
==================

Ainda pensando em segurança, Yves Orton fez algumas mudanças
importantes nas últimas semanas, mudanças que vão entrar no perl
5.18.0. Entre outras coisas[6], temos:

  * Introdução de múltiplas funções de hashing para escolher na hora
de compilar o perl. Entre as opções estão Murmur-32[7], SDBM[8],
DJB2[9], SipHash[10], SuperFast[11], e uma versão melhorada do
original One-at-a-time;

  * Eliminação do antigo mecanismo HvREHASH, substituído por uma
semente aleatória de hash por processo.

Otimizações à parte, a possibilidade de trocar de função de hash
facilmente é importante pois, caso, por um motivo qualquer, a função
atual seja considerada vulnerável a ataques, você não precisa esperar
até que o "core team" do Perl - ou seu fornecedor/sistema - lance uma
versão corrigida: basta recompilar seu perl escolhendo outra função.

A parte importante, no entanto, é a semente de hash ser aleatória por
processo. Até então, o perl usava uma semente de hash que não era lá
grande coisa, semente essa que era definida durante a compilação.
Todos os hashes usam essa semente e, quando um ataque de colisões é
detectado, um "rehash" era executado, em que todos os elementos do
hash teriam seu valor recalculado, com todas as consequências
esperadas em termos de desempenho e memória. Claro que, quando muitas
colisões aconteciam, o rehash mudava para uma semente aleatória.

Agora, após essa última modificação, todos os processos usarão
garantidamente uma semente aleatória.

Essa aleatoriedade da semente dos hashes deve tornar o perl ainda mais
robusto contra ataques de complexidade, e com código mais simples. No
entanto, como você pode ter previsto, há um efeito colateral a essa
mudança: a ordem das chaves de um hash mudam com bem mais frequência
do que antes.


Legal! Mas, o que isso significa pro meu código?
======================================

Conforme escrito no perlsec[12] desde a versão 5.8.1 do perl (aquela
de 2003), Perl nunca garantiu qualquer ordenação das chaves de um
hash, e de fato essa ordenação já mudou algumas vezes ao longo da
história. O problema, porém, é que muitos desenvolvedores acabam sem
querer dependendo da ordenação de hashes, ou ao menos de alguma ordem
aleatória mas constante, simplesmente porque aquela ordem em
particular funcionava em seus ambientes. Isso que é bug sutil!

Pode não ser o seu caso, mas é bom ter certeza. Andreas König, Father
Chrysostomos e o resto dos P5P/CPANTesters se deram ao trabalho de
testar diversas das principais distribuições que estão no CPAN[13] e
avisar aos autores sempre que um teste falhava ao executar a versão
nova do perl. Mas eles não podem fazer isso com todos os módulos, e
ainda tem o *seu* código pra testar também.

Você sabe, aquele código da sua aplicação. Código que você não botou no CPAN.

Estranhamente, parece que na maioria dos casos encontrados no CPAN os
problemas estavam nos testes, testes que esperam que keys() estejam em
uma ordem em particular. A função keys() garante apenas que os valores
retornados estarão na mesma ordem que as funções values() e
each()[14], e mesmo isso só é garantido para o mesmo processo, então
certifique-se de que não esteja dando tiros no pé.



Mentira! Meu código é perfeito, vocês é que quebraram o Perl!
================================================

Então, não exatamente. Como disse antes, é um bug muito sutil, um que
pode estar afetando seu código em produção neste exato momento, ainda
que apenas em alguns cenários específicos, e por isso mesmo ser muito
difícil de reproduzir e depurar. Não acredita? Há um experimento muito
simples que você pode fazer em seu perl do sistema:

Primeiro, vamos criar um one-liner simples que cria 15 pares
chave/valor, e imprime eles na tela:

   > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
     6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5

Você pode ter recebido na sua tela uma ordem diferente (recebeu?), mas
você provavelmente vai ganhar a mesma ordem não importa quantas vezes
você executar:

   > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
     6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
   > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
     6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
   > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
     6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
   > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
     6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
   > ...

Mas o que acontece se o seu código adicionar uma 16a chave por engano
e, ao perceber o erro, remover a chave logo depois? Ainda teremos 15
chaves, as mesmas 15 chaves de antes, então é claro que os valores
estarão na mesma ordem de antes, certo? CERTO? Errado:

   > perl -E 'local $,=q[, ]; $hash{$_}=$_ for 1..15; $hash{16}=16;
delete $hash{16}; say keys %hash'
     11, 7, 2, 1, 13, 6, 3, 9, 12, 14, 15, 8, 4, 10, 5

Isso pode acontecer em qualquer lugar, como ao reutilizar uma variável de hash:

    sub init { ( 1=>1, 2=>2, 3=>3, 4=>4, 5=>5 ) }

    my %hash = init();
    say "original: " . join ', ' => keys %hash;
    $hash{$_} = $_ for 6..100;

    %hash = init(); # restaura valores originais
    say "original? " . join ', ' => keys %hash;

Isso é o que eu recebo como saída no meu bom e velho 5.14.3:

    original: 4, 1, 3, 2, 5
    original? 2, 1, 3, 4, 5

Como podemos ver, trata-se de um problema real e que pode estar
espreitando em um canto obscuro do seu código neste exato momento. O
que o patch do Yves faz é simplesmente expor o problema de forma mais
explícita para você. Isso é uma coisa boa, porque, além da segurança
extra, você vai conseguir identificar código quebrado muito mais
facilmente. Se você tentar o one-liner original acima no 5.17.6, você
vai receber uma ordem de chaves diferente a cada execução:

   > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
     1, 5, 15, 12, 6, 4, 10, 9, 3, 13, 7, 14, 11, 2, 8
   > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
     5, 11, 7, 3, 15, 6, 12, 2, 13, 9, 8, 14, 10, 1, 4
   > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
     2, 15, 14, 13, 5, 1, 9, 10, 3, 11, 6, 8, 12, 4, 7
   > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
     8, 2, 14, 10, 1, 9, 4, 3, 6, 15, 5, 13, 7, 12, 11



Então... acho que meu código está quebrado.
===================================

Não se preocupe, a solução costuma ser fácil! Procure pelo teste que
falha e verifique se o que quer que esteja sendo testado chama keys(),
values() ou each() em algum lugar. Você provavelmente quer rodar o
sort() nesses valores para garantir a ordem, ou modificar seu
algoritmo para algo mais determinístico.



Sabe o que que é, eu não tenho lá muitos testes... O que fazer?
=================================================

Procure por chamadas a keys(), values() ou each() no seu código, e
certifique-se que eles não dependem da ordem dos elementos retornado.
Tudo bem fazer algo como:

  my @keys   = keys %hash;
  my @values = values %hash;
  say "hash key $keys[3] vale $values[3]";

porque, como vimos antes, keys() e values() vão sempre usar a mesma
ordem para o mesmo processo, qualquer que seja essa ordem. O código
abaixo, no entanto, está errado:

  if ($keys[0] eq 'alguma_chave') {
     ...
  }

simplesmente porque não há qualquer garantia da ordem na lista
retornada por keys(). Por outro lado, o código acima teria funcionado
perfeitamente se o valor retornado estivesse ordenado, fazendo algo
como:

  my @keys = sort keys %hash;



Uso indireto
=========

Infelizmente, seu código não está seguro simplesmente porque você não
usa essas funções (ou ordena elas corretamente). Algumas vezes nós
recebemos listas de valores de módulos de terceiros, e essas listas
podem estar afetadas pelo problema. Por isso, procure por listas
populadas por funções externas e veja se você depende que os valores
recebidos estejam em uma ordem particular. Por exemplo, você pode ter
código assim:

   my ($nome, $idade, $grau) = Algum::Modulo->new->get_list( 'algum_usuario' );

E, só dentro de Algum::Modulo, você encontrar o suspeito:

  sub get_list {
    my ($self, $username) = @_;
    return values $self->{data}{$username};
  }

Faça um teste que falha para essa função, envie a correção, repita :)


Calce as Sandálias da Humildade
==========================

Achar que você é imune, que esse tipo de erro é coisa de amador ou que
só acontece no código do vizinho não é saudável. Mesmo módulos
estáveis e consagrados como DBI, LWP, DBIx::Class e Catalyst::Runtime
foram vítimas do problema de uma forma ou de outra. Felizmente,
módulos como esses possuem uma comunidade muito forte e engajada, e as
correções ou já estão no CPAN ou chegarão lá a qualquer momento.



Odiei a mudança! Mudem de volta!
===========================

Olha, vai ser difícil isso acontecer. Lembre-se: aleatoriedade nos
hashes é uma coisa boa! Por favor dê uma outra olhada nas seções acima
e tente corrigir seu código. Se precisar de ajuda, peça nos lugares de
sempre, como nas listas (como essa!), no IRC - hoje em dia até
Facebook tem grupos de Perl!

Mas se você realmente precisa do comportamento anterior (sabe-se lá
por quê), você pode simplesmente continuar no 5.16 ou tentar compilar
o perl definindo o PERL_HASH_FUNC_ONE_AT_A_TIME_OLD pra simular o
algoritmo velho, mas de qualquer forma o mecanismo de rehashing foi
embora, então especificar seu próprio valor de semente no
PERL_HASH_SEED é provavelmente o mais perto que vai chegar :)

Agradecimentos especiais a todos do P5P por seu esforço contínuo em
nos manter à salvo!



Referências:
==========

[1] - http://perlbrew.pl
[2] - http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf
[3] - http://www.nruns.com/_downloads/advisory28122011.pdf
[4] - http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf
[5] - http://media.ccc.de/browse/congress/2011/28c3-4680-en-effective_dos_attacks_against_web_application_platforms.html
[6] - http://perl5.git.perl.org/perl.git/commit/7dc8663964c66a698d31bbdc8e8abed69bddeec3
[7] - http://code.google.com/p/smhasher/wiki/MurmurHash3
[8] - http://www.cse.yorku.ca/~oz/hash.html
[9] - http://www.cse.yorku.ca/~oz/hash.html
[10] - https://www.131002.net/siphash/
[11] - http://www.azillionmonkeys.com/qed/hash.html
[12] - http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks
[13] - https://rt.perl.org/rt3/Public/Bug/Display.html?id=115908
[14] - http://perldoc.perl.org/functions/keys.html

From marciodesouzaferreira em gmail.com  Wed Dec  5 20:59:10 2012
From: marciodesouzaferreira em gmail.com (Marcio Ferreira)
Date: Thu, 6 Dec 2012 02:59:10 -0200
Subject: [Brasil-PM]
	=?utf-8?q?voc=C3=AA_confia_na_ordem_das_chaves_de_um_?=
	=?utf-8?q?hash=3F?=
In-Reply-To: <CAHS-WQZsOksc=9vf=Hw+2pTVDbJZgCASUti4kNHm3DpGe7jzOQ@mail.gmail.com>
References: <CAHS-WQZsOksc=9vf=Hw+2pTVDbJZgCASUti4kNHm3DpGe7jzOQ@mail.gmail.com>
Message-ID: <CADFrvgskwkOpWA5ZphisJ0=dLwincJ+bzgusYb=NtCgkeTRuZw@mail.gmail.com>

breno++ while each() != keys()

parabéns post!

[]s,

Marcio Ferreira
skype: marcio.ferreir4
(21) 8365-7768



2012/12/6 breno <breno em rio.pm.org>

> (do original em:
>
> http://onionstand.blogspot.com.br/2012/12/are-you-relying-on-hash-keys-being.html
> )
>
> tl;dr
> ------
>
> Se você pretende eventualmente migrar para o 5.18, faça isso *agora*:
>
>    1. Instale o 5.17.6 (você usa perlbrew[1], certo?);
>    2. Experimente seus módulos e aplicativos nele (você tem testes,
> certo?);
>    3. Se alguma coisa quebrar, é porque provavelmente algo está
> dependendo dos valores de keys(), values() ou each() estarem em um
> ordem particular. Você realmente não deveria estar fazendo isso, então
> use sort() ou coisa que o valha nesses valores :)
>    4.  Se algum módulo do CPAN que você usa falhar no 5.17.6,
> certifique-se de que o autor está ciente e preparando um patch;
>    5.  Divulgue!
>
>
>
> Sobre Hashes e Segurança
> ======================
>
> O "core team" do Perl 5 sempre coloca segurança como uma de suas
> maiores prioridades. Para termos noção, no final de 2011 um ataque de
> negação de serviços remoto explorando complexidade
> algorítmica[2][3][4][5] foi descoberto em importantes implementações
> de linguagens como PHP, Ruby, Python, Java, até mesmo JavaScript. Essa
> vulnerabilidade havia sido corrigida no Perl 5 desde... 2003.
>
>
> Isso foi antes. E agora?
> ==================
>
> Ainda pensando em segurança, Yves Orton fez algumas mudanças
> importantes nas últimas semanas, mudanças que vão entrar no perl
> 5.18.0. Entre outras coisas[6], temos:
>
>   * Introdução de múltiplas funções de hashing para escolher na hora
> de compilar o perl. Entre as opções estão Murmur-32[7], SDBM[8],
> DJB2[9], SipHash[10], SuperFast[11], e uma versão melhorada do
> original One-at-a-time;
>
>   * Eliminação do antigo mecanismo HvREHASH, substituído por uma
> semente aleatória de hash por processo.
>
> Otimizações à parte, a possibilidade de trocar de função de hash
> facilmente é importante pois, caso, por um motivo qualquer, a função
> atual seja considerada vulnerável a ataques, você não precisa esperar
> até que o "core team" do Perl - ou seu fornecedor/sistema - lance uma
> versão corrigida: basta recompilar seu perl escolhendo outra função.
>
> A parte importante, no entanto, é a semente de hash ser aleatória por
> processo. Até então, o perl usava uma semente de hash que não era lá
> grande coisa, semente essa que era definida durante a compilação.
> Todos os hashes usam essa semente e, quando um ataque de colisões é
> detectado, um "rehash" era executado, em que todos os elementos do
> hash teriam seu valor recalculado, com todas as consequências
> esperadas em termos de desempenho e memória. Claro que, quando muitas
> colisões aconteciam, o rehash mudava para uma semente aleatória.
>
> Agora, após essa última modificação, todos os processos usarão
> garantidamente uma semente aleatória.
>
> Essa aleatoriedade da semente dos hashes deve tornar o perl ainda mais
> robusto contra ataques de complexidade, e com código mais simples. No
> entanto, como você pode ter previsto, há um efeito colateral a essa
> mudança: a ordem das chaves de um hash mudam com bem mais frequência
> do que antes.
>
>
> Legal! Mas, o que isso significa pro meu código?
> ======================================
>
> Conforme escrito no perlsec[12] desde a versão 5.8.1 do perl (aquela
> de 2003), Perl nunca garantiu qualquer ordenação das chaves de um
> hash, e de fato essa ordenação já mudou algumas vezes ao longo da
> história. O problema, porém, é que muitos desenvolvedores acabam sem
> querer dependendo da ordenação de hashes, ou ao menos de alguma ordem
> aleatória mas constante, simplesmente porque aquela ordem em
> particular funcionava em seus ambientes. Isso que é bug sutil!
>
> Pode não ser o seu caso, mas é bom ter certeza. Andreas König, Father
> Chrysostomos e o resto dos P5P/CPANTesters se deram ao trabalho de
> testar diversas das principais distribuições que estão no CPAN[13] e
> avisar aos autores sempre que um teste falhava ao executar a versão
> nova do perl. Mas eles não podem fazer isso com todos os módulos, e
> ainda tem o *seu* código pra testar também.
>
> Você sabe, aquele código da sua aplicação. Código que você não botou no
> CPAN.
>
> Estranhamente, parece que na maioria dos casos encontrados no CPAN os
> problemas estavam nos testes, testes que esperam que keys() estejam em
> uma ordem em particular. A função keys() garante apenas que os valores
> retornados estarão na mesma ordem que as funções values() e
> each()[14], e mesmo isso só é garantido para o mesmo processo, então
> certifique-se de que não esteja dando tiros no pé.
>
>
>
> Mentira! Meu código é perfeito, vocês é que quebraram o Perl!
> ================================================
>
> Então, não exatamente. Como disse antes, é um bug muito sutil, um que
> pode estar afetando seu código em produção neste exato momento, ainda
> que apenas em alguns cenários específicos, e por isso mesmo ser muito
> difícil de reproduzir e depurar. Não acredita? Há um experimento muito
> simples que você pode fazer em seu perl do sistema:
>
> Primeiro, vamos criar um one-liner simples que cria 15 pares
> chave/valor, e imprime eles na tela:
>
>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>
> Você pode ter recebido na sua tela uma ordem diferente (recebeu?), mas
> você provavelmente vai ganhar a mesma ordem não importa quantas vezes
> você executar:
>
>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>    > ...
>
> Mas o que acontece se o seu código adicionar uma 16a chave por engano
> e, ao perceber o erro, remover a chave logo depois? Ainda teremos 15
> chaves, as mesmas 15 chaves de antes, então é claro que os valores
> estarão na mesma ordem de antes, certo? CERTO? Errado:
>
>    > perl -E 'local $,=q[, ]; $hash{$_}=$_ for 1..15; $hash{16}=16;
> delete $hash{16}; say keys %hash'
>      11, 7, 2, 1, 13, 6, 3, 9, 12, 14, 15, 8, 4, 10, 5
>
> Isso pode acontecer em qualquer lugar, como ao reutilizar uma variável de
> hash:
>
>     sub init { ( 1=>1, 2=>2, 3=>3, 4=>4, 5=>5 ) }
>
>     my %hash = init();
>     say "original: " . join ', ' => keys %hash;
>     $hash{$_} = $_ for 6..100;
>
>     %hash = init(); # restaura valores originais
>     say "original? " . join ', ' => keys %hash;
>
> Isso é o que eu recebo como saída no meu bom e velho 5.14.3:
>
>     original: 4, 1, 3, 2, 5
>     original? 2, 1, 3, 4, 5
>
> Como podemos ver, trata-se de um problema real e que pode estar
> espreitando em um canto obscuro do seu código neste exato momento. O
> que o patch do Yves faz é simplesmente expor o problema de forma mais
> explícita para você. Isso é uma coisa boa, porque, além da segurança
> extra, você vai conseguir identificar código quebrado muito mais
> facilmente. Se você tentar o one-liner original acima no 5.17.6, você
> vai receber uma ordem de chaves diferente a cada execução:
>
>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>      1, 5, 15, 12, 6, 4, 10, 9, 3, 13, 7, 14, 11, 2, 8
>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>      5, 11, 7, 3, 15, 6, 12, 2, 13, 9, 8, 14, 10, 1, 4
>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>      2, 15, 14, 13, 5, 1, 9, 10, 3, 11, 6, 8, 12, 4, 7
>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>      8, 2, 14, 10, 1, 9, 4, 3, 6, 15, 5, 13, 7, 12, 11
>
>
>
> Então... acho que meu código está quebrado.
> ===================================
>
> Não se preocupe, a solução costuma ser fácil! Procure pelo teste que
> falha e verifique se o que quer que esteja sendo testado chama keys(),
> values() ou each() em algum lugar. Você provavelmente quer rodar o
> sort() nesses valores para garantir a ordem, ou modificar seu
> algoritmo para algo mais determinístico.
>
>
>
> Sabe o que que é, eu não tenho lá muitos testes... O que fazer?
> =================================================
>
> Procure por chamadas a keys(), values() ou each() no seu código, e
> certifique-se que eles não dependem da ordem dos elementos retornado.
> Tudo bem fazer algo como:
>
>   my @keys   = keys %hash;
>   my @values = values %hash;
>   say "hash key $keys[3] vale $values[3]";
>
> porque, como vimos antes, keys() e values() vão sempre usar a mesma
> ordem para o mesmo processo, qualquer que seja essa ordem. O código
> abaixo, no entanto, está errado:
>
>   if ($keys[0] eq 'alguma_chave') {
>      ...
>   }
>
> simplesmente porque não há qualquer garantia da ordem na lista
> retornada por keys(). Por outro lado, o código acima teria funcionado
> perfeitamente se o valor retornado estivesse ordenado, fazendo algo
> como:
>
>   my @keys = sort keys %hash;
>
>
>
> Uso indireto
> =========
>
> Infelizmente, seu código não está seguro simplesmente porque você não
> usa essas funções (ou ordena elas corretamente). Algumas vezes nós
> recebemos listas de valores de módulos de terceiros, e essas listas
> podem estar afetadas pelo problema. Por isso, procure por listas
> populadas por funções externas e veja se você depende que os valores
> recebidos estejam em uma ordem particular. Por exemplo, você pode ter
> código assim:
>
>    my ($nome, $idade, $grau) = Algum::Modulo->new->get_list(
> 'algum_usuario' );
>
> E, só dentro de Algum::Modulo, você encontrar o suspeito:
>
>   sub get_list {
>     my ($self, $username) = @_;
>     return values $self->{data}{$username};
>   }
>
> Faça um teste que falha para essa função, envie a correção, repita :)
>
>
> Calce as Sandálias da Humildade
> ==========================
>
> Achar que você é imune, que esse tipo de erro é coisa de amador ou que
> só acontece no código do vizinho não é saudável. Mesmo módulos
> estáveis e consagrados como DBI, LWP, DBIx::Class e Catalyst::Runtime
> foram vítimas do problema de uma forma ou de outra. Felizmente,
> módulos como esses possuem uma comunidade muito forte e engajada, e as
> correções ou já estão no CPAN ou chegarão lá a qualquer momento.
>
>
>
> Odiei a mudança! Mudem de volta!
> ===========================
>
> Olha, vai ser difícil isso acontecer. Lembre-se: aleatoriedade nos
> hashes é uma coisa boa! Por favor dê uma outra olhada nas seções acima
> e tente corrigir seu código. Se precisar de ajuda, peça nos lugares de
> sempre, como nas listas (como essa!), no IRC - hoje em dia até
> Facebook tem grupos de Perl!
>
> Mas se você realmente precisa do comportamento anterior (sabe-se lá
> por quê), você pode simplesmente continuar no 5.16 ou tentar compilar
> o perl definindo o PERL_HASH_FUNC_ONE_AT_A_TIME_OLD pra simular o
> algoritmo velho, mas de qualquer forma o mecanismo de rehashing foi
> embora, então especificar seu próprio valor de semente no
> PERL_HASH_SEED é provavelmente o mais perto que vai chegar :)
>
> Agradecimentos especiais a todos do P5P por seu esforço contínuo em
> nos manter à salvo!
>
>
>
> Referências:
> ==========
>
> [1] - http://perlbrew.pl
> [2] - http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf
> [3] - http://www.nruns.com/_downloads/advisory28122011.pdf
> [4] -
> http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf
> [5] -
> http://media.ccc.de/browse/congress/2011/28c3-4680-en-effective_dos_attacks_against_web_application_platforms.html
> [6] -
> http://perl5.git.perl.org/perl.git/commit/7dc8663964c66a698d31bbdc8e8abed69bddeec3
> [7] - http://code.google.com/p/smhasher/wiki/MurmurHash3
> [8] - http://www.cse.yorku.ca/~oz/hash.html
> [9] - http://www.cse.yorku.ca/~oz/hash.html
> [10] - https://www.131002.net/siphash/
> [11] - http://www.azillionmonkeys.com/qed/hash.html
> [12] - http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks
> [13] - https://rt.perl.org/rt3/Public/Bug/Display.html?id=115908
> [14] - http://perldoc.perl.org/functions/keys.html
> _______________________________________________
> Brasil-PM mailing list
> Brasil-PM em pm.org
> http://mail.pm.org/mailman/listinfo/brasil-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/brasil-pm/attachments/20121206/4c9fed0c/attachment-0001.html>

From crncosta em gmail.com  Thu Dec  6 01:25:53 2012
From: crncosta em gmail.com (Carlos Costa)
Date: Thu, 6 Dec 2012 07:25:53 -0200
Subject: [Brasil-PM]
	=?iso-8859-1?q?voc=EA_confia_na_ordem_das_chaves_de_u?=
	=?iso-8859-1?q?m_hash=3F?=
In-Reply-To: <CADFrvgskwkOpWA5ZphisJ0=dLwincJ+bzgusYb=NtCgkeTRuZw@mail.gmail.com>
References: <CAHS-WQZsOksc=9vf=Hw+2pTVDbJZgCASUti4kNHm3DpGe7jzOQ@mail.gmail.com>
	<CADFrvgskwkOpWA5ZphisJ0=dLwincJ+bzgusYb=NtCgkeTRuZw@mail.gmail.com>
Message-ID: <CALegQb7agKW=UAZ5rr5iyPqby+Y7-VVU6rzvw=V-9n8xU_UBQg@mail.gmail.com>

Breno++   # Claro e objetivo. Muito obrigado! =)

( )s
Carlos.


2012/12/6 Marcio Ferreira <marciodesouzaferreira em gmail.com>

> breno++ while each() != keys()
>
> parabéns post!
>
> []s,
>
> Marcio Ferreira
> skype: marcio.ferreir4
> (21) 8365-7768
>
>
>
> 2012/12/6 breno <breno em rio.pm.org>
>
>> (do original em:
>>
>> http://onionstand.blogspot.com.br/2012/12/are-you-relying-on-hash-keys-being.html
>> )
>>
>> tl;dr
>> ------
>>
>> Se você pretende eventualmente migrar para o 5.18, faça isso *agora*:
>>
>>    1. Instale o 5.17.6 (você usa perlbrew[1], certo?);
>>    2. Experimente seus módulos e aplicativos nele (você tem testes,
>> certo?);
>>    3. Se alguma coisa quebrar, é porque provavelmente algo está
>> dependendo dos valores de keys(), values() ou each() estarem em um
>> ordem particular. Você realmente não deveria estar fazendo isso, então
>> use sort() ou coisa que o valha nesses valores :)
>>    4.  Se algum módulo do CPAN que você usa falhar no 5.17.6,
>> certifique-se de que o autor está ciente e preparando um patch;
>>    5.  Divulgue!
>>
>>
>>
>> Sobre Hashes e Segurança
>> ======================
>>
>> O "core team" do Perl 5 sempre coloca segurança como uma de suas
>> maiores prioridades. Para termos noção, no final de 2011 um ataque de
>> negação de serviços remoto explorando complexidade
>> algorítmica[2][3][4][5] foi descoberto em importantes implementações
>> de linguagens como PHP, Ruby, Python, Java, até mesmo JavaScript. Essa
>> vulnerabilidade havia sido corrigida no Perl 5 desde... 2003.
>>
>>
>> Isso foi antes. E agora?
>> ==================
>>
>> Ainda pensando em segurança, Yves Orton fez algumas mudanças
>> importantes nas últimas semanas, mudanças que vão entrar no perl
>> 5.18.0. Entre outras coisas[6], temos:
>>
>>   * Introdução de múltiplas funções de hashing para escolher na hora
>> de compilar o perl. Entre as opções estão Murmur-32[7], SDBM[8],
>> DJB2[9], SipHash[10], SuperFast[11], e uma versão melhorada do
>> original One-at-a-time;
>>
>>   * Eliminação do antigo mecanismo HvREHASH, substituído por uma
>> semente aleatória de hash por processo.
>>
>> Otimizações à parte, a possibilidade de trocar de função de hash
>> facilmente é importante pois, caso, por um motivo qualquer, a função
>> atual seja considerada vulnerável a ataques, você não precisa esperar
>> até que o "core team" do Perl - ou seu fornecedor/sistema - lance uma
>> versão corrigida: basta recompilar seu perl escolhendo outra função.
>>
>> A parte importante, no entanto, é a semente de hash ser aleatória por
>> processo. Até então, o perl usava uma semente de hash que não era lá
>> grande coisa, semente essa que era definida durante a compilação.
>> Todos os hashes usam essa semente e, quando um ataque de colisões é
>> detectado, um "rehash" era executado, em que todos os elementos do
>> hash teriam seu valor recalculado, com todas as consequências
>> esperadas em termos de desempenho e memória. Claro que, quando muitas
>> colisões aconteciam, o rehash mudava para uma semente aleatória.
>>
>> Agora, após essa última modificação, todos os processos usarão
>> garantidamente uma semente aleatória.
>>
>> Essa aleatoriedade da semente dos hashes deve tornar o perl ainda mais
>> robusto contra ataques de complexidade, e com código mais simples. No
>> entanto, como você pode ter previsto, há um efeito colateral a essa
>> mudança: a ordem das chaves de um hash mudam com bem mais frequência
>> do que antes.
>>
>>
>> Legal! Mas, o que isso significa pro meu código?
>> ======================================
>>
>> Conforme escrito no perlsec[12] desde a versão 5.8.1 do perl (aquela
>> de 2003), Perl nunca garantiu qualquer ordenação das chaves de um
>> hash, e de fato essa ordenação já mudou algumas vezes ao longo da
>> história. O problema, porém, é que muitos desenvolvedores acabam sem
>> querer dependendo da ordenação de hashes, ou ao menos de alguma ordem
>> aleatória mas constante, simplesmente porque aquela ordem em
>> particular funcionava em seus ambientes. Isso que é bug sutil!
>>
>> Pode não ser o seu caso, mas é bom ter certeza. Andreas König, Father
>> Chrysostomos e o resto dos P5P/CPANTesters se deram ao trabalho de
>> testar diversas das principais distribuições que estão no CPAN[13] e
>> avisar aos autores sempre que um teste falhava ao executar a versão
>> nova do perl. Mas eles não podem fazer isso com todos os módulos, e
>> ainda tem o *seu* código pra testar também.
>>
>> Você sabe, aquele código da sua aplicação. Código que você não botou no
>> CPAN.
>>
>> Estranhamente, parece que na maioria dos casos encontrados no CPAN os
>> problemas estavam nos testes, testes que esperam que keys() estejam em
>> uma ordem em particular. A função keys() garante apenas que os valores
>> retornados estarão na mesma ordem que as funções values() e
>> each()[14], e mesmo isso só é garantido para o mesmo processo, então
>> certifique-se de que não esteja dando tiros no pé.
>>
>>
>>
>> Mentira! Meu código é perfeito, vocês é que quebraram o Perl!
>> ================================================
>>
>> Então, não exatamente. Como disse antes, é um bug muito sutil, um que
>> pode estar afetando seu código em produção neste exato momento, ainda
>> que apenas em alguns cenários específicos, e por isso mesmo ser muito
>> difícil de reproduzir e depurar. Não acredita? Há um experimento muito
>> simples que você pode fazer em seu perl do sistema:
>>
>> Primeiro, vamos criar um one-liner simples que cria 15 pares
>> chave/valor, e imprime eles na tela:
>>
>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>>
>> Você pode ter recebido na sua tela uma ordem diferente (recebeu?), mas
>> você provavelmente vai ganhar a mesma ordem não importa quantas vezes
>> você executar:
>>
>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>>    > ...
>>
>> Mas o que acontece se o seu código adicionar uma 16a chave por engano
>> e, ao perceber o erro, remover a chave logo depois? Ainda teremos 15
>> chaves, as mesmas 15 chaves de antes, então é claro que os valores
>> estarão na mesma ordem de antes, certo? CERTO? Errado:
>>
>>    > perl -E 'local $,=q[, ]; $hash{$_}=$_ for 1..15; $hash{16}=16;
>> delete $hash{16}; say keys %hash'
>>      11, 7, 2, 1, 13, 6, 3, 9, 12, 14, 15, 8, 4, 10, 5
>>
>> Isso pode acontecer em qualquer lugar, como ao reutilizar uma variável de
>> hash:
>>
>>     sub init { ( 1=>1, 2=>2, 3=>3, 4=>4, 5=>5 ) }
>>
>>     my %hash = init();
>>     say "original: " . join ', ' => keys %hash;
>>     $hash{$_} = $_ for 6..100;
>>
>>     %hash = init(); # restaura valores originais
>>     say "original? " . join ', ' => keys %hash;
>>
>> Isso é o que eu recebo como saída no meu bom e velho 5.14.3:
>>
>>     original: 4, 1, 3, 2, 5
>>     original? 2, 1, 3, 4, 5
>>
>> Como podemos ver, trata-se de um problema real e que pode estar
>> espreitando em um canto obscuro do seu código neste exato momento. O
>> que o patch do Yves faz é simplesmente expor o problema de forma mais
>> explícita para você. Isso é uma coisa boa, porque, além da segurança
>> extra, você vai conseguir identificar código quebrado muito mais
>> facilmente. Se você tentar o one-liner original acima no 5.17.6, você
>> vai receber uma ordem de chaves diferente a cada execução:
>>
>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>      1, 5, 15, 12, 6, 4, 10, 9, 3, 13, 7, 14, 11, 2, 8
>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>      5, 11, 7, 3, 15, 6, 12, 2, 13, 9, 8, 14, 10, 1, 4
>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>      2, 15, 14, 13, 5, 1, 9, 10, 3, 11, 6, 8, 12, 4, 7
>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>      8, 2, 14, 10, 1, 9, 4, 3, 6, 15, 5, 13, 7, 12, 11
>>
>>
>>
>> Então... acho que meu código está quebrado.
>> ===================================
>>
>> Não se preocupe, a solução costuma ser fácil! Procure pelo teste que
>> falha e verifique se o que quer que esteja sendo testado chama keys(),
>> values() ou each() em algum lugar. Você provavelmente quer rodar o
>> sort() nesses valores para garantir a ordem, ou modificar seu
>> algoritmo para algo mais determinístico.
>>
>>
>>
>> Sabe o que que é, eu não tenho lá muitos testes... O que fazer?
>> =================================================
>>
>> Procure por chamadas a keys(), values() ou each() no seu código, e
>> certifique-se que eles não dependem da ordem dos elementos retornado.
>> Tudo bem fazer algo como:
>>
>>   my @keys   = keys %hash;
>>   my @values = values %hash;
>>   say "hash key $keys[3] vale $values[3]";
>>
>> porque, como vimos antes, keys() e values() vão sempre usar a mesma
>> ordem para o mesmo processo, qualquer que seja essa ordem. O código
>> abaixo, no entanto, está errado:
>>
>>   if ($keys[0] eq 'alguma_chave') {
>>      ...
>>   }
>>
>> simplesmente porque não há qualquer garantia da ordem na lista
>> retornada por keys(). Por outro lado, o código acima teria funcionado
>> perfeitamente se o valor retornado estivesse ordenado, fazendo algo
>> como:
>>
>>   my @keys = sort keys %hash;
>>
>>
>>
>> Uso indireto
>> =========
>>
>> Infelizmente, seu código não está seguro simplesmente porque você não
>> usa essas funções (ou ordena elas corretamente). Algumas vezes nós
>> recebemos listas de valores de módulos de terceiros, e essas listas
>> podem estar afetadas pelo problema. Por isso, procure por listas
>> populadas por funções externas e veja se você depende que os valores
>> recebidos estejam em uma ordem particular. Por exemplo, você pode ter
>> código assim:
>>
>>    my ($nome, $idade, $grau) = Algum::Modulo->new->get_list(
>> 'algum_usuario' );
>>
>> E, só dentro de Algum::Modulo, você encontrar o suspeito:
>>
>>   sub get_list {
>>     my ($self, $username) = @_;
>>     return values $self->{data}{$username};
>>   }
>>
>> Faça um teste que falha para essa função, envie a correção, repita :)
>>
>>
>> Calce as Sandálias da Humildade
>> ==========================
>>
>> Achar que você é imune, que esse tipo de erro é coisa de amador ou que
>> só acontece no código do vizinho não é saudável. Mesmo módulos
>> estáveis e consagrados como DBI, LWP, DBIx::Class e Catalyst::Runtime
>> foram vítimas do problema de uma forma ou de outra. Felizmente,
>> módulos como esses possuem uma comunidade muito forte e engajada, e as
>> correções ou já estão no CPAN ou chegarão lá a qualquer momento.
>>
>>
>>
>> Odiei a mudança! Mudem de volta!
>> ===========================
>>
>> Olha, vai ser difícil isso acontecer. Lembre-se: aleatoriedade nos
>> hashes é uma coisa boa! Por favor dê uma outra olhada nas seções acima
>> e tente corrigir seu código. Se precisar de ajuda, peça nos lugares de
>> sempre, como nas listas (como essa!), no IRC - hoje em dia até
>> Facebook tem grupos de Perl!
>>
>> Mas se você realmente precisa do comportamento anterior (sabe-se lá
>> por quê), você pode simplesmente continuar no 5.16 ou tentar compilar
>> o perl definindo o PERL_HASH_FUNC_ONE_AT_A_TIME_OLD pra simular o
>> algoritmo velho, mas de qualquer forma o mecanismo de rehashing foi
>> embora, então especificar seu próprio valor de semente no
>> PERL_HASH_SEED é provavelmente o mais perto que vai chegar :)
>>
>> Agradecimentos especiais a todos do P5P por seu esforço contínuo em
>> nos manter à salvo!
>>
>>
>>
>> Referências:
>> ==========
>>
>> [1] - http://perlbrew.pl
>> [2] -
>> http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf
>> [3] - http://www.nruns.com/_downloads/advisory28122011.pdf
>> [4] -
>> http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf
>> [5] -
>> http://media.ccc.de/browse/congress/2011/28c3-4680-en-effective_dos_attacks_against_web_application_platforms.html
>> [6] -
>> http://perl5.git.perl.org/perl.git/commit/7dc8663964c66a698d31bbdc8e8abed69bddeec3
>> [7] - http://code.google.com/p/smhasher/wiki/MurmurHash3
>> [8] - http://www.cse.yorku.ca/~oz/hash.html
>> [9] - http://www.cse.yorku.ca/~oz/hash.html
>> [10] - https://www.131002.net/siphash/
>> [11] - http://www.azillionmonkeys.com/qed/hash.html
>> [12] -
>> http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks
>> [13] - https://rt.perl.org/rt3/Public/Bug/Display.html?id=115908
>> [14] - http://perldoc.perl.org/functions/keys.html
>> _______________________________________________
>> Brasil-PM mailing list
>> Brasil-PM em pm.org
>> http://mail.pm.org/mailman/listinfo/brasil-pm
>>
>
>
> _______________________________________________
> Brasil-PM mailing list
> Brasil-PM em pm.org
> http://mail.pm.org/mailman/listinfo/brasil-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/brasil-pm/attachments/20121206/da8b4b59/attachment-0001.html>

From andregarciacarneiro em gmail.com  Thu Dec  6 02:30:46 2012
From: andregarciacarneiro em gmail.com (Andre Carneiro)
Date: Thu, 6 Dec 2012 08:30:46 -0200
Subject: [Brasil-PM]
	=?iso-8859-1?q?voc=EA_confia_na_ordem_das_chaves_de_u?=
	=?iso-8859-1?q?m_hash=3F?=
In-Reply-To: <CALegQb7agKW=UAZ5rr5iyPqby+Y7-VVU6rzvw=V-9n8xU_UBQg@mail.gmail.com>
References: <CAHS-WQZsOksc=9vf=Hw+2pTVDbJZgCASUti4kNHm3DpGe7jzOQ@mail.gmail.com>
	<CADFrvgskwkOpWA5ZphisJ0=dLwincJ+bzgusYb=NtCgkeTRuZw@mail.gmail.com>
	<CALegQb7agKW=UAZ5rr5iyPqby+Y7-VVU6rzvw=V-9n8xU_UBQg@mail.gmail.com>
Message-ID: <CABoU2P2WB+Upt0mwuSN42vh+h0NANgnKp8aj4-q4AVLh1MafMQ@mail.gmail.com>

Breno++ #servindo muito bem a comunidade, como sempre!

Obrigado Breno!



2012/12/6 Carlos Costa <crncosta em gmail.com>

> Breno++   # Claro e objetivo. Muito obrigado! =)
>
> ( )s
> Carlos.
>
>
> 2012/12/6 Marcio Ferreira <marciodesouzaferreira em gmail.com>
>
>> breno++ while each() != keys()
>>
>> parabéns post!
>>
>> []s,
>>
>> Marcio Ferreira
>> skype: marcio.ferreir4
>> (21) 8365-7768
>>
>>
>>
>> 2012/12/6 breno <breno em rio.pm.org>
>>
>>> (do original em:
>>>
>>> http://onionstand.blogspot.com.br/2012/12/are-you-relying-on-hash-keys-being.html
>>> )
>>>
>>> tl;dr
>>> ------
>>>
>>> Se você pretende eventualmente migrar para o 5.18, faça isso *agora*:
>>>
>>>    1. Instale o 5.17.6 (você usa perlbrew[1], certo?);
>>>    2. Experimente seus módulos e aplicativos nele (você tem testes,
>>> certo?);
>>>    3. Se alguma coisa quebrar, é porque provavelmente algo está
>>> dependendo dos valores de keys(), values() ou each() estarem em um
>>> ordem particular. Você realmente não deveria estar fazendo isso, então
>>> use sort() ou coisa que o valha nesses valores :)
>>>    4.  Se algum módulo do CPAN que você usa falhar no 5.17.6,
>>> certifique-se de que o autor está ciente e preparando um patch;
>>>    5.  Divulgue!
>>>
>>>
>>>
>>> Sobre Hashes e Segurança
>>> ======================
>>>
>>> O "core team" do Perl 5 sempre coloca segurança como uma de suas
>>> maiores prioridades. Para termos noção, no final de 2011 um ataque de
>>> negação de serviços remoto explorando complexidade
>>> algorítmica[2][3][4][5] foi descoberto em importantes implementações
>>> de linguagens como PHP, Ruby, Python, Java, até mesmo JavaScript. Essa
>>> vulnerabilidade havia sido corrigida no Perl 5 desde... 2003.
>>>
>>>
>>> Isso foi antes. E agora?
>>> ==================
>>>
>>> Ainda pensando em segurança, Yves Orton fez algumas mudanças
>>> importantes nas últimas semanas, mudanças que vão entrar no perl
>>> 5.18.0. Entre outras coisas[6], temos:
>>>
>>>   * Introdução de múltiplas funções de hashing para escolher na hora
>>> de compilar o perl. Entre as opções estão Murmur-32[7], SDBM[8],
>>> DJB2[9], SipHash[10], SuperFast[11], e uma versão melhorada do
>>> original One-at-a-time;
>>>
>>>   * Eliminação do antigo mecanismo HvREHASH, substituído por uma
>>> semente aleatória de hash por processo.
>>>
>>> Otimizações à parte, a possibilidade de trocar de função de hash
>>> facilmente é importante pois, caso, por um motivo qualquer, a função
>>> atual seja considerada vulnerável a ataques, você não precisa esperar
>>> até que o "core team" do Perl - ou seu fornecedor/sistema - lance uma
>>> versão corrigida: basta recompilar seu perl escolhendo outra função.
>>>
>>> A parte importante, no entanto, é a semente de hash ser aleatória por
>>> processo. Até então, o perl usava uma semente de hash que não era lá
>>> grande coisa, semente essa que era definida durante a compilação.
>>> Todos os hashes usam essa semente e, quando um ataque de colisões é
>>> detectado, um "rehash" era executado, em que todos os elementos do
>>> hash teriam seu valor recalculado, com todas as consequências
>>> esperadas em termos de desempenho e memória. Claro que, quando muitas
>>> colisões aconteciam, o rehash mudava para uma semente aleatória.
>>>
>>> Agora, após essa última modificação, todos os processos usarão
>>> garantidamente uma semente aleatória.
>>>
>>> Essa aleatoriedade da semente dos hashes deve tornar o perl ainda mais
>>> robusto contra ataques de complexidade, e com código mais simples. No
>>> entanto, como você pode ter previsto, há um efeito colateral a essa
>>> mudança: a ordem das chaves de um hash mudam com bem mais frequência
>>> do que antes.
>>>
>>>
>>> Legal! Mas, o que isso significa pro meu código?
>>> ======================================
>>>
>>> Conforme escrito no perlsec[12] desde a versão 5.8.1 do perl (aquela
>>> de 2003), Perl nunca garantiu qualquer ordenação das chaves de um
>>> hash, e de fato essa ordenação já mudou algumas vezes ao longo da
>>> história. O problema, porém, é que muitos desenvolvedores acabam sem
>>> querer dependendo da ordenação de hashes, ou ao menos de alguma ordem
>>> aleatória mas constante, simplesmente porque aquela ordem em
>>> particular funcionava em seus ambientes. Isso que é bug sutil!
>>>
>>> Pode não ser o seu caso, mas é bom ter certeza. Andreas König, Father
>>> Chrysostomos e o resto dos P5P/CPANTesters se deram ao trabalho de
>>> testar diversas das principais distribuições que estão no CPAN[13] e
>>> avisar aos autores sempre que um teste falhava ao executar a versão
>>> nova do perl. Mas eles não podem fazer isso com todos os módulos, e
>>> ainda tem o *seu* código pra testar também.
>>>
>>> Você sabe, aquele código da sua aplicação. Código que você não botou no
>>> CPAN.
>>>
>>> Estranhamente, parece que na maioria dos casos encontrados no CPAN os
>>> problemas estavam nos testes, testes que esperam que keys() estejam em
>>> uma ordem em particular. A função keys() garante apenas que os valores
>>> retornados estarão na mesma ordem que as funções values() e
>>> each()[14], e mesmo isso só é garantido para o mesmo processo, então
>>> certifique-se de que não esteja dando tiros no pé.
>>>
>>>
>>>
>>> Mentira! Meu código é perfeito, vocês é que quebraram o Perl!
>>> ================================================
>>>
>>> Então, não exatamente. Como disse antes, é um bug muito sutil, um que
>>> pode estar afetando seu código em produção neste exato momento, ainda
>>> que apenas em alguns cenários específicos, e por isso mesmo ser muito
>>> difícil de reproduzir e depurar. Não acredita? Há um experimento muito
>>> simples que você pode fazer em seu perl do sistema:
>>>
>>> Primeiro, vamos criar um one-liner simples que cria 15 pares
>>> chave/valor, e imprime eles na tela:
>>>
>>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>>>
>>> Você pode ter recebido na sua tela uma ordem diferente (recebeu?), mas
>>> você provavelmente vai ganhar a mesma ordem não importa quantas vezes
>>> você executar:
>>>
>>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>>      6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>>>    > ...
>>>
>>> Mas o que acontece se o seu código adicionar uma 16a chave por engano
>>> e, ao perceber o erro, remover a chave logo depois? Ainda teremos 15
>>> chaves, as mesmas 15 chaves de antes, então é claro que os valores
>>> estarão na mesma ordem de antes, certo? CERTO? Errado:
>>>
>>>    > perl -E 'local $,=q[, ]; $hash{$_}=$_ for 1..15; $hash{16}=16;
>>> delete $hash{16}; say keys %hash'
>>>      11, 7, 2, 1, 13, 6, 3, 9, 12, 14, 15, 8, 4, 10, 5
>>>
>>> Isso pode acontecer em qualquer lugar, como ao reutilizar uma variável
>>> de hash:
>>>
>>>     sub init { ( 1=>1, 2=>2, 3=>3, 4=>4, 5=>5 ) }
>>>
>>>     my %hash = init();
>>>     say "original: " . join ', ' => keys %hash;
>>>     $hash{$_} = $_ for 6..100;
>>>
>>>     %hash = init(); # restaura valores originais
>>>     say "original? " . join ', ' => keys %hash;
>>>
>>> Isso é o que eu recebo como saída no meu bom e velho 5.14.3:
>>>
>>>     original: 4, 1, 3, 2, 5
>>>     original? 2, 1, 3, 4, 5
>>>
>>> Como podemos ver, trata-se de um problema real e que pode estar
>>> espreitando em um canto obscuro do seu código neste exato momento. O
>>> que o patch do Yves faz é simplesmente expor o problema de forma mais
>>> explícita para você. Isso é uma coisa boa, porque, além da segurança
>>> extra, você vai conseguir identificar código quebrado muito mais
>>> facilmente. Se você tentar o one-liner original acima no 5.17.6, você
>>> vai receber uma ordem de chaves diferente a cada execução:
>>>
>>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>>      1, 5, 15, 12, 6, 4, 10, 9, 3, 13, 7, 14, 11, 2, 8
>>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>>      5, 11, 7, 3, 15, 6, 12, 2, 13, 9, 8, 14, 10, 1, 4
>>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>>      2, 15, 14, 13, 5, 1, 9, 10, 3, 11, 6, 8, 12, 4, 7
>>>    > perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>>>      8, 2, 14, 10, 1, 9, 4, 3, 6, 15, 5, 13, 7, 12, 11
>>>
>>>
>>>
>>> Então... acho que meu código está quebrado.
>>> ===================================
>>>
>>> Não se preocupe, a solução costuma ser fácil! Procure pelo teste que
>>> falha e verifique se o que quer que esteja sendo testado chama keys(),
>>> values() ou each() em algum lugar. Você provavelmente quer rodar o
>>> sort() nesses valores para garantir a ordem, ou modificar seu
>>> algoritmo para algo mais determinístico.
>>>
>>>
>>>
>>> Sabe o que que é, eu não tenho lá muitos testes... O que fazer?
>>> =================================================
>>>
>>> Procure por chamadas a keys(), values() ou each() no seu código, e
>>> certifique-se que eles não dependem da ordem dos elementos retornado.
>>> Tudo bem fazer algo como:
>>>
>>>   my @keys   = keys %hash;
>>>   my @values = values %hash;
>>>   say "hash key $keys[3] vale $values[3]";
>>>
>>> porque, como vimos antes, keys() e values() vão sempre usar a mesma
>>> ordem para o mesmo processo, qualquer que seja essa ordem. O código
>>> abaixo, no entanto, está errado:
>>>
>>>   if ($keys[0] eq 'alguma_chave') {
>>>      ...
>>>   }
>>>
>>> simplesmente porque não há qualquer garantia da ordem na lista
>>> retornada por keys(). Por outro lado, o código acima teria funcionado
>>> perfeitamente se o valor retornado estivesse ordenado, fazendo algo
>>> como:
>>>
>>>   my @keys = sort keys %hash;
>>>
>>>
>>>
>>> Uso indireto
>>> =========
>>>
>>> Infelizmente, seu código não está seguro simplesmente porque você não
>>> usa essas funções (ou ordena elas corretamente). Algumas vezes nós
>>> recebemos listas de valores de módulos de terceiros, e essas listas
>>> podem estar afetadas pelo problema. Por isso, procure por listas
>>> populadas por funções externas e veja se você depende que os valores
>>> recebidos estejam em uma ordem particular. Por exemplo, você pode ter
>>> código assim:
>>>
>>>    my ($nome, $idade, $grau) = Algum::Modulo->new->get_list(
>>> 'algum_usuario' );
>>>
>>> E, só dentro de Algum::Modulo, você encontrar o suspeito:
>>>
>>>   sub get_list {
>>>     my ($self, $username) = @_;
>>>     return values $self->{data}{$username};
>>>   }
>>>
>>> Faça um teste que falha para essa função, envie a correção, repita :)
>>>
>>>
>>> Calce as Sandálias da Humildade
>>> ==========================
>>>
>>> Achar que você é imune, que esse tipo de erro é coisa de amador ou que
>>> só acontece no código do vizinho não é saudável. Mesmo módulos
>>> estáveis e consagrados como DBI, LWP, DBIx::Class e Catalyst::Runtime
>>> foram vítimas do problema de uma forma ou de outra. Felizmente,
>>> módulos como esses possuem uma comunidade muito forte e engajada, e as
>>> correções ou já estão no CPAN ou chegarão lá a qualquer momento.
>>>
>>>
>>>
>>> Odiei a mudança! Mudem de volta!
>>> ===========================
>>>
>>> Olha, vai ser difícil isso acontecer. Lembre-se: aleatoriedade nos
>>> hashes é uma coisa boa! Por favor dê uma outra olhada nas seções acima
>>> e tente corrigir seu código. Se precisar de ajuda, peça nos lugares de
>>> sempre, como nas listas (como essa!), no IRC - hoje em dia até
>>> Facebook tem grupos de Perl!
>>>
>>> Mas se você realmente precisa do comportamento anterior (sabe-se lá
>>> por quê), você pode simplesmente continuar no 5.16 ou tentar compilar
>>> o perl definindo o PERL_HASH_FUNC_ONE_AT_A_TIME_OLD pra simular o
>>> algoritmo velho, mas de qualquer forma o mecanismo de rehashing foi
>>> embora, então especificar seu próprio valor de semente no
>>> PERL_HASH_SEED é provavelmente o mais perto que vai chegar :)
>>>
>>> Agradecimentos especiais a todos do P5P por seu esforço contínuo em
>>> nos manter à salvo!
>>>
>>>
>>>
>>> Referências:
>>> ==========
>>>
>>> [1] - http://perlbrew.pl
>>> [2] -
>>> http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf
>>> [3] - http://www.nruns.com/_downloads/advisory28122011.pdf
>>> [4] -
>>> http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf
>>> [5] -
>>> http://media.ccc.de/browse/congress/2011/28c3-4680-en-effective_dos_attacks_against_web_application_platforms.html
>>> [6] -
>>> http://perl5.git.perl.org/perl.git/commit/7dc8663964c66a698d31bbdc8e8abed69bddeec3
>>> [7] - http://code.google.com/p/smhasher/wiki/MurmurHash3
>>> [8] - http://www.cse.yorku.ca/~oz/hash.html
>>> [9] - http://www.cse.yorku.ca/~oz/hash.html
>>> [10] - https://www.131002.net/siphash/
>>> [11] - http://www.azillionmonkeys.com/qed/hash.html
>>> [12] -
>>> http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks
>>> [13] - https://rt.perl.org/rt3/Public/Bug/Display.html?id=115908
>>> [14] - http://perldoc.perl.org/functions/keys.html
>>> _______________________________________________
>>> Brasil-PM mailing list
>>> Brasil-PM em pm.org
>>> http://mail.pm.org/mailman/listinfo/brasil-pm
>>>
>>
>>
>> _______________________________________________
>> Brasil-PM mailing list
>> Brasil-PM em pm.org
>> http://mail.pm.org/mailman/listinfo/brasil-pm
>>
>
>
> _______________________________________________
> Brasil-PM mailing list
> Brasil-PM em pm.org
> http://mail.pm.org/mailman/listinfo/brasil-pm
>



-- 
André Garcia Carneiro
Software Engineer
(11)982907780
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/brasil-pm/attachments/20121206/ee0a15f8/attachment-0001.html>

From gabiruh em gmail.com  Thu Dec  6 04:57:44 2012
From: gabiruh em gmail.com (Gabriel Andrade)
Date: Thu, 6 Dec 2012 09:57:44 -0300
Subject: [Brasil-PM]
 =?iso-8859-1?q?voc=EA_confia_na_ordem_das_chaves_de_u?=
 =?iso-8859-1?q?m_hash=3F?=
In-Reply-To: <CAHS-WQZsOksc=9vf=Hw+2pTVDbJZgCASUti4kNHm3DpGe7jzOQ@mail.gmail.com>
References: <CAHS-WQZsOksc=9vf=Hw+2pTVDbJZgCASUti4kNHm3DpGe7jzOQ@mail.gmail.com>
Message-ID: <9D9F5DDD-6046-4B05-AE8F-314E857AA648@gmail.com>

    +
    +
++breno++
    +
    +

On Dec 6, 2012, at 1:39 AM, breno <breno em rio.pm.org> wrote:

> (do original em:
> http://onionstand.blogspot.com.br/2012/12/are-you-relying-on-hash-keys-being.html)
> 
> tl;dr
> ------
> 
> Se você pretende eventualmente migrar para o 5.18, faça isso *agora*:
> 
>   1. Instale o 5.17.6 (você usa perlbrew[1], certo?);
>   2. Experimente seus módulos e aplicativos nele (você tem testes, certo?);
>   3. Se alguma coisa quebrar, é porque provavelmente algo está
> dependendo dos valores de keys(), values() ou each() estarem em um
> ordem particular. Você realmente não deveria estar fazendo isso, então
> use sort() ou coisa que o valha nesses valores :)
>   4.  Se algum módulo do CPAN que você usa falhar no 5.17.6,
> certifique-se de que o autor está ciente e preparando um patch;
>   5.  Divulgue!
> 
> 
> 
> Sobre Hashes e Segurança
> ======================
> 
> O "core team" do Perl 5 sempre coloca segurança como uma de suas
> maiores prioridades. Para termos noção, no final de 2011 um ataque de
> negação de serviços remoto explorando complexidade
> algorítmica[2][3][4][5] foi descoberto em importantes implementações
> de linguagens como PHP, Ruby, Python, Java, até mesmo JavaScript. Essa
> vulnerabilidade havia sido corrigida no Perl 5 desde... 2003.
> 
> 
> Isso foi antes. E agora?
> ==================
> 
> Ainda pensando em segurança, Yves Orton fez algumas mudanças
> importantes nas últimas semanas, mudanças que vão entrar no perl
> 5.18.0. Entre outras coisas[6], temos:
> 
>  * Introdução de múltiplas funções de hashing para escolher na hora
> de compilar o perl. Entre as opções estão Murmur-32[7], SDBM[8],
> DJB2[9], SipHash[10], SuperFast[11], e uma versão melhorada do
> original One-at-a-time;
> 
>  * Eliminação do antigo mecanismo HvREHASH, substituído por uma
> semente aleatória de hash por processo.
> 
> Otimizações à parte, a possibilidade de trocar de função de hash
> facilmente é importante pois, caso, por um motivo qualquer, a função
> atual seja considerada vulnerável a ataques, você não precisa esperar
> até que o "core team" do Perl - ou seu fornecedor/sistema - lance uma
> versão corrigida: basta recompilar seu perl escolhendo outra função.
> 
> A parte importante, no entanto, é a semente de hash ser aleatória por
> processo. Até então, o perl usava uma semente de hash que não era lá
> grande coisa, semente essa que era definida durante a compilação.
> Todos os hashes usam essa semente e, quando um ataque de colisões é
> detectado, um "rehash" era executado, em que todos os elementos do
> hash teriam seu valor recalculado, com todas as consequências
> esperadas em termos de desempenho e memória. Claro que, quando muitas
> colisões aconteciam, o rehash mudava para uma semente aleatória.
> 
> Agora, após essa última modificação, todos os processos usarão
> garantidamente uma semente aleatória.
> 
> Essa aleatoriedade da semente dos hashes deve tornar o perl ainda mais
> robusto contra ataques de complexidade, e com código mais simples. No
> entanto, como você pode ter previsto, há um efeito colateral a essa
> mudança: a ordem das chaves de um hash mudam com bem mais frequência
> do que antes.
> 
> 
> Legal! Mas, o que isso significa pro meu código?
> ======================================
> 
> Conforme escrito no perlsec[12] desde a versão 5.8.1 do perl (aquela
> de 2003), Perl nunca garantiu qualquer ordenação das chaves de um
> hash, e de fato essa ordenação já mudou algumas vezes ao longo da
> história. O problema, porém, é que muitos desenvolvedores acabam sem
> querer dependendo da ordenação de hashes, ou ao menos de alguma ordem
> aleatória mas constante, simplesmente porque aquela ordem em
> particular funcionava em seus ambientes. Isso que é bug sutil!
> 
> Pode não ser o seu caso, mas é bom ter certeza. Andreas König, Father
> Chrysostomos e o resto dos P5P/CPANTesters se deram ao trabalho de
> testar diversas das principais distribuições que estão no CPAN[13] e
> avisar aos autores sempre que um teste falhava ao executar a versão
> nova do perl. Mas eles não podem fazer isso com todos os módulos, e
> ainda tem o *seu* código pra testar também.
> 
> Você sabe, aquele código da sua aplicação. Código que você não botou no CPAN.
> 
> Estranhamente, parece que na maioria dos casos encontrados no CPAN os
> problemas estavam nos testes, testes que esperam que keys() estejam em
> uma ordem em particular. A função keys() garante apenas que os valores
> retornados estarão na mesma ordem que as funções values() e
> each()[14], e mesmo isso só é garantido para o mesmo processo, então
> certifique-se de que não esteja dando tiros no pé.
> 
> 
> 
> Mentira! Meu código é perfeito, vocês é que quebraram o Perl!
> ================================================
> 
> Então, não exatamente. Como disse antes, é um bug muito sutil, um que
> pode estar afetando seu código em produção neste exato momento, ainda
> que apenas em alguns cenários específicos, e por isso mesmo ser muito
> difícil de reproduzir e depurar. Não acredita? Há um experimento muito
> simples que você pode fazer em seu perl do sistema:
> 
> Primeiro, vamos criar um one-liner simples que cria 15 pares
> chave/valor, e imprime eles na tela:
> 
>> perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>     6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
> 
> Você pode ter recebido na sua tela uma ordem diferente (recebeu?), mas
> você provavelmente vai ganhar a mesma ordem não importa quantas vezes
> você executar:
> 
>> perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>     6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>> perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>     6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>> perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>     6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>> perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>     6, 11, 3, 7, 9, 12, 2, 15, 14, 8, 1, 4, 13, 10, 5
>> ...
> 
> Mas o que acontece se o seu código adicionar uma 16a chave por engano
> e, ao perceber o erro, remover a chave logo depois? Ainda teremos 15
> chaves, as mesmas 15 chaves de antes, então é claro que os valores
> estarão na mesma ordem de antes, certo? CERTO? Errado:
> 
>> perl -E 'local $,=q[, ]; $hash{$_}=$_ for 1..15; $hash{16}=16;
> delete $hash{16}; say keys %hash'
>     11, 7, 2, 1, 13, 6, 3, 9, 12, 14, 15, 8, 4, 10, 5
> 
> Isso pode acontecer em qualquer lugar, como ao reutilizar uma variável de hash:
> 
>    sub init { ( 1=>1, 2=>2, 3=>3, 4=>4, 5=>5 ) }
> 
>    my %hash = init();
>    say "original: " . join ', ' => keys %hash;
>    $hash{$_} = $_ for 6..100;
> 
>    %hash = init(); # restaura valores originais
>    say "original? " . join ', ' => keys %hash;
> 
> Isso é o que eu recebo como saída no meu bom e velho 5.14.3:
> 
>    original: 4, 1, 3, 2, 5
>    original? 2, 1, 3, 4, 5
> 
> Como podemos ver, trata-se de um problema real e que pode estar
> espreitando em um canto obscuro do seu código neste exato momento. O
> que o patch do Yves faz é simplesmente expor o problema de forma mais
> explícita para você. Isso é uma coisa boa, porque, além da segurança
> extra, você vai conseguir identificar código quebrado muito mais
> facilmente. Se você tentar o one-liner original acima no 5.17.6, você
> vai receber uma ordem de chaves diferente a cada execução:
> 
>> perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>     1, 5, 15, 12, 6, 4, 10, 9, 3, 13, 7, 14, 11, 2, 8
>> perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>     5, 11, 7, 3, 15, 6, 12, 2, 13, 9, 8, 14, 10, 1, 4
>> perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>     2, 15, 14, 13, 5, 1, 9, 10, 3, 11, 6, 8, 12, 4, 7
>> perl -E 'local $,=q[, ]; $hash{$_} = $_ for 1..15; say keys %hash'
>     8, 2, 14, 10, 1, 9, 4, 3, 6, 15, 5, 13, 7, 12, 11
> 
> 
> 
> Então... acho que meu código está quebrado.
> ===================================
> 
> Não se preocupe, a solução costuma ser fácil! Procure pelo teste que
> falha e verifique se o que quer que esteja sendo testado chama keys(),
> values() ou each() em algum lugar. Você provavelmente quer rodar o
> sort() nesses valores para garantir a ordem, ou modificar seu
> algoritmo para algo mais determinístico.
> 
> 
> 
> Sabe o que que é, eu não tenho lá muitos testes... O que fazer?
> =================================================
> 
> Procure por chamadas a keys(), values() ou each() no seu código, e
> certifique-se que eles não dependem da ordem dos elementos retornado.
> Tudo bem fazer algo como:
> 
>  my @keys   = keys %hash;
>  my @values = values %hash;
>  say "hash key $keys[3] vale $values[3]";
> 
> porque, como vimos antes, keys() e values() vão sempre usar a mesma
> ordem para o mesmo processo, qualquer que seja essa ordem. O código
> abaixo, no entanto, está errado:
> 
>  if ($keys[0] eq 'alguma_chave') {
>     ...
>  }
> 
> simplesmente porque não há qualquer garantia da ordem na lista
> retornada por keys(). Por outro lado, o código acima teria funcionado
> perfeitamente se o valor retornado estivesse ordenado, fazendo algo
> como:
> 
>  my @keys = sort keys %hash;
> 
> 
> 
> Uso indireto
> =========
> 
> Infelizmente, seu código não está seguro simplesmente porque você não
> usa essas funções (ou ordena elas corretamente). Algumas vezes nós
> recebemos listas de valores de módulos de terceiros, e essas listas
> podem estar afetadas pelo problema. Por isso, procure por listas
> populadas por funções externas e veja se você depende que os valores
> recebidos estejam em uma ordem particular. Por exemplo, você pode ter
> código assim:
> 
>   my ($nome, $idade, $grau) = Algum::Modulo->new->get_list( 'algum_usuario' );
> 
> E, só dentro de Algum::Modulo, você encontrar o suspeito:
> 
>  sub get_list {
>    my ($self, $username) = @_;
>    return values $self->{data}{$username};
>  }
> 
> Faça um teste que falha para essa função, envie a correção, repita :)
> 
> 
> Calce as Sandálias da Humildade
> ==========================
> 
> Achar que você é imune, que esse tipo de erro é coisa de amador ou que
> só acontece no código do vizinho não é saudável. Mesmo módulos
> estáveis e consagrados como DBI, LWP, DBIx::Class e Catalyst::Runtime
> foram vítimas do problema de uma forma ou de outra. Felizmente,
> módulos como esses possuem uma comunidade muito forte e engajada, e as
> correções ou já estão no CPAN ou chegarão lá a qualquer momento.
> 
> 
> 
> Odiei a mudança! Mudem de volta!
> ===========================
> 
> Olha, vai ser difícil isso acontecer. Lembre-se: aleatoriedade nos
> hashes é uma coisa boa! Por favor dê uma outra olhada nas seções acima
> e tente corrigir seu código. Se precisar de ajuda, peça nos lugares de
> sempre, como nas listas (como essa!), no IRC - hoje em dia até
> Facebook tem grupos de Perl!
> 
> Mas se você realmente precisa do comportamento anterior (sabe-se lá
> por quê), você pode simplesmente continuar no 5.16 ou tentar compilar
> o perl definindo o PERL_HASH_FUNC_ONE_AT_A_TIME_OLD pra simular o
> algoritmo velho, mas de qualquer forma o mecanismo de rehashing foi
> embora, então especificar seu próprio valor de semente no
> PERL_HASH_SEED é provavelmente o mais perto que vai chegar :)
> 
> Agradecimentos especiais a todos do P5P por seu esforço contínuo em
> nos manter à salvo!
> 
> 
> 
> Referências:
> ==========
> 
> [1] - http://perlbrew.pl
> [2] - http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf
> [3] - http://www.nruns.com/_downloads/advisory28122011.pdf
> [4] - http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf
> [5] - http://media.ccc.de/browse/congress/2011/28c3-4680-en-effective_dos_attacks_against_web_application_platforms.html
> [6] - http://perl5.git.perl.org/perl.git/commit/7dc8663964c66a698d31bbdc8e8abed69bddeec3
> [7] - http://code.google.com/p/smhasher/wiki/MurmurHash3
> [8] - http://www.cse.yorku.ca/~oz/hash.html
> [9] - http://www.cse.yorku.ca/~oz/hash.html
> [10] - https://www.131002.net/siphash/
> [11] - http://www.azillionmonkeys.com/qed/hash.html
> [12] - http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks
> [13] - https://rt.perl.org/rt3/Public/Bug/Display.html?id=115908
> [14] - http://perldoc.perl.org/functions/keys.html
> _______________________________________________
> Brasil-PM mailing list
> Brasil-PM em pm.org
> http://mail.pm.org/mailman/listinfo/brasil-pm


From breno em rio.pm.org  Wed Dec 19 09:13:08 2012
From: breno em rio.pm.org (breno)
Date: Wed, 19 Dec 2012 15:13:08 -0200
Subject: [Brasil-PM] 25 anos de Perl!
Message-ID: <CAHS-WQYHjwF5Dvd2a0JCmoQebG7Mvw4uhHWrt5Xo_DKPmkRXHQ@mail.gmail.com>

Ontem, dia 18 de Dezembro, a linguagem Perl fez 25 anos! Para
comemorar as bodas de prata, Mark Keating escreveu um apanhado dessa
fantástica história, cobrindo a evolução da linguagem e sua
comunidade. O texto, em inglês, pode ser lido aqui:

http://news.perlfoundation.org/2012/12/the-first-twenty-five-years.html

Incidentalmente, hoje li um artigo sobre o efeito Lindy, que diz que
artefatos criativos possuem tempo de vida exponencial, de modo que
coisas que continuam por aí possuem também maior propensão a
permanecer relevantes por muito mais tempo. É uma estimativa bruta que
não considera outros fatores, mas não deixa de ser interessante. O
artigo usa como exemplo o Perl, que pelo efeito Lindy tem mais
propensão de ainda ser usado em 2037 do que Go, que tem apenas 3 anos.

http://www.johndcook.com/blog/2012/12/19/more-on-the-lindy-effect/

Será que teremos bodas de ouro? Enquanto isso, feliz aniversário, Perl!

[]s

-b