Fim de ano em Divinópolis (MG)

Esse fim de ano aproveitei denovo a semana de recesso (uma combinação meio shady aqui em brasília mas que acaba funcionando) para denovo visitar minha cidade natal com a família. É um tempo bom para descansar, rever os amigos e deixar minha mãe babar (muito) no neto enquanto eu e a Li temos um merecido tempo para fazer mais coisas juntos.

Carteado + Cachaça. É, Minas.

Ano passado fizemos a mesma viagem e este ano, mesmo comigo podendo ajudar a dividir a direção no caso de uma road trip, resolvemos fazer o mesmo esquema: avião até Confins e de lá alugar um carro para facilitar a viagem para Divinópolis e a semana no geral. Funciona bem, mais ainda quando se consegue umas promoções comprando antecipadamente.

Divinópolis, para quem não conhece fica a uns 100 km de Belo Horizonte e este ano teve alguns problemas com as chuvas. Chegamos uma semana depois de passada a enchente mais grave mas ainda estava chovendo muito e o abastecimento de água estava meio esquisito. Comprar água mineral na cidade era virtualmente impossível, porque todo o estoque tinha sido usado nos seis dias que a cidade ficou sem água potável.

Falando assim, parece que a cidade é minúscula mas a Princesinha do Oeste é até razoavelmente grande.

Algumas surpresas interessantes na cidade, nestes últimos dois anos: o restaurante de comida japonesa/chinesa não fechou (na verdade, continua dando fila na entrada praticamente toda a noite), e ainda abriram um restaurante com um chef português que faz uma comida realmente boa. Eu e a Li devemos ter jantado no Ohashi umas três vezes, e chegamos a conclusão de que a comida deles é melhor do que muitos aqui em brasília (como por exemplo o Haná).

Claro que ainda tem as esquisitices de cidade do interior. Fecharam o único teatro da cidade, um shopping com dois cinemas, e o outro shopping da cidade continua com muitas lojas vazias. Pelo menos a Americanas continua por lá, o que significa novos DVDs e uma mochila de presente pra mim e as lojas de roupa que conseguiram dar uma ajuda no guarda-roupa sem gastar um absurdo.

Aliás, o lance da enchente meio que acabou com o natal da cidade, dava para notar. Quase nenhuma casa tinha decoração externa e mesmo os lugares públicos ficaram sem luzes e tal, completamente compreensível visto que a prefeitura tinha coisas mais importantes pra se preocupar.

No mais, se você algum dia passar por Divinópolis não se esqueça de passar no Rei do Pão de Queijo para comer um pão de queijo recheado com linguiça (ou pernil). Best, thing, evah!

intel

Desenvolvimento seguro e software livre – Dica 4: Operação Segura

Cheque esta tag para ver os demais posts desta série.

Operação Segura

A prática final no desenvolvimento seguro é especialmente importante para projetos de Software Livre. A Operação Segura refere-se a todo o suporte que deve ser oferecido às aplicações e sistemas depois dos mesmos serem lançados e disponibilizados como uma “versão final”.

A operação segura não se refere apenas ao suporte comum dado em listas e fórums de discussão mas também ao fornecimento de canais de comunicação específicos para problemas e soluções relacionados a segurança que vão surgir de acordo com a popularização do software.

O primeiro ponto que tem de se observar nesta estrutura de suporte é o como o projeto vai lidar com falhas de segurança descobertas in the wild (ou seja, na operação normal de um software já lançado). Muitos defendem o Full Disclosure mas existem alguns projetos que lidam com as vulnerabilidades em segredo até uma correção estar disponível.

Outro ponto importante é a definição clara de como os avisos/relatórios que tratem de vulnerabilidades serão enviados e recebidos pelo projeto. É aconselhável que exista um canal rápido e conhecido (um email ou formulário de fácil acesso) pelo qual relatórios sobre novas vulnerabilidades (ou mesmo bugs relativos à segurança) possam ser enviados e tratados pela equipe responsável em tempo hábil, sem a necessidade de vigiar centenas de emails sobre suporte genéricos na lista de usuários.

Caso o projeto opte pelo Full Disclosure, os desenvolvedores tem de estar atentos à esta política e tomar as devidas precauções. Mesmo sem o Full Disclosure, os desenvolvedores tem de ter em mente que um especialista em segurança pode descobrir uma falha simplesmente analisando atualizações no repositório de controle de versões. Correções ou formas de se remediar uma falha devem ser feitas públicas e amplamente conhecidas o mais rápido possível após a descoberta/publicação de uma falha.

Internamente, as falhas de segurança encontradas após o lançamento devem realimentar o processo de análise de risco para que este possa se concentrar nas áreas próximas a onde a falha foi encontrada, no intuito de conferir a efetividade das correções e o possível aparecimento de problemas decorrentes de novo código adicionado muitas vezes as pressas.

Conclusão

Este foi o último post desta série. As cinco práticas descritas são na verdade uma simplificação de sistemas mais elaborados e menos flexíveis de desenvolvimento seguro, visando facilitar a implantação destas práticas a projetos descentralizados e muitas vezes não tão grandes assim de Software Livre. Os interessados em saber mais ou dar suas opiniões podem deixar seus comentários ou entrar em contato.

intel