Acho que o programa da receita ja existe a décadas antes da publicação da IN
4.

2010/1/7 Alexandre Oliva <lxol...@fsfla.org>

> Como venho fazendo todos os anos, resolvi tentar ajudar a que a versão
> final do IRPF-2010 seja um programa ainda mais robusto.  Está difícil.
>
> Primeiro, porque a única versão disponível em
>
> http://www.receita.fazenda.gov.br/PessoaFisica/IRPF/2010/PGDJava/ProgramaIrpf2010VersaoTeste.htm
> é um programa exclusivamente para Windows.  Será que não dá pra publicar
> uma versão multi-plataforma, como noutras oportunidades?  Desse jeito, o
> tempo curtíssimo para encontrar e encaminhar problemas fica ainda mais
> curto, pois preciso solicitar a alguém que tenha o Windows que faça a
> instalação e me mande a versão Java instalada.
>
> Segundo, ao que tudo indica, continua faltando o código fonte.  Qualquer
> profissional em computação entende que isso limita profundamente os
> testes que alguém pode fazer sobre um programa.  As possibilidades ficam
> restritas aos testes chamados de caixa preta, além de praticamente
> inviabilizar testes automatizados, dada a dificuldade de utilizar
> ferramentas de controle, inspeção, injeção de valores, cobertura de
> código e tantas outras técnicas de engenharia de software.
>
> Claro que, por ser o programa em Java, compilado para uma máquina
> virtual de alto nível, há como contornar em parte algumas dessas
> limitações.  Noutros anos, não foi difícil descompilar o programa Java,
> apesar do ofuscamento, a ponto de poder compará-lo com versões de anos
> anteriores e atualizar o IRPF-Livre, que venho publicando há alguns
> anos, baseado em versões anteriores também descompiladas.  Imagino que
> neste ano não vá ser diferente.
>
> Mesmo assim, embora o código resultante da descompilação seja útil para
> atualizar o IRPF-Livre e para verificar algumas condições simples, não é
> adequado para o uso de ferramentas avançadas de testes, porque os
> binários publicados passam por um processo de ofuscamento, que serve
> para pouco além de dificultar os testes.  Que outro propósito haveria em
> esconder o código que supostamente implementa nada além de operações
> aritméticas e instruções especificadas em lei?
>
>
> A prática de publicar a versão de testes dessa forma é tão ineficaz
> quanto a sessão aberta de testes da urna eletrônica promovida pelo TSE:
> enquanto um finge que deixa quem quiser tentar encontrar erros (desde
> que não use nenhuma das ferramentas avançadas para encontrar erros), os
> demais fingem que não há problema algum, pois os problemas complicados
> dificilmente seriam encontrados sem essas ferramentas.
>
>
> Entendo que haja receios a respeito da publicação do código fonte do PGD
> do IRPF.  Sei que é uma decisão fundada não em questões técnicas, mas em
> medos irracionais.  Os desenvolvedores do programa, assim como qualquer
> pessoa minimamente capacitada em tecnologia e segurança de informação,
> compreende que manter segredo a respeito de como funciona um programa
> não é empecilho para que alguém descubra como burlá-lo, ou mesmo de
> descobrir exatamente como ele funciona, vide o IRPF-Livre e suas
> atualizações baseadas em descompilação do IRPF.
>
> Sabem também que a segurança do processo advém não do segredo, mas da
> robustez da solução.  Desenvolvedores do IRPF, com quem tenho mantido
> contato direto e indireto nos últimos anos, afirmam que não há risco
> técnico algum para a publicação de seu código fonte.
>
> Receios manifestados por burocratas de que alguém modifique o programa e
> faça com que pessoas o utilizem são manifestações de ingenuidade e de
> desconhecimento tećnico dos processos de segurança computacional.
>
> Um dos argumentos é que alguém poderia modificar o programa a fim de
> coletar informação e enviá-la indevidamente a terceiros, ou a fim de
> induzir terceiros ingênuos a instalar código malicioso escondido nas
> versões modificadas em seus computadores.
>
> Qualquer um que entenda minimamente de segurança esperaria que, para
> usar o programa da RFB, usuário deveriam baixá-lo da RFB, através de
> conexão segura.  Se a RFB se preocupasse com esse aspecto, deveria de
> fato induzir ao uso de conexões seguras (ao contrário do que faz hoje),
> e deveri deveria publicar assinaturas digitais do programa, que
> permitiriam verificar sua origem última mesmo quando obtido de outras
> fontes indiretas.
>
> Mas infelizmente a grande maioria não entende minimamente de segurança,
> tanto dentro quanto fora da RFB.  Baixam programas de qualquer lugar,
> acreditam em e-mails que recebem falando para baixar um programa
> qualquer para corrigir a situação fiscal ou para responder a uma ordem
> judicial, e por aí val.
>
> A falha do argumento é que a publicação do código fonte tornaria as
> vítimas desses golpes mais vulneráveis.
>
> Se alguém quisesse fazer um programa que se parecesse com o da IRPF, a
> ponto de enganar alguém, poderia fazê-lo com relativa facilidade.  Mais
> fácil ainda seria empacotar um programa puramente malicioso e
> distribuí-lo apenas afirmando ser o IRPF da RFB.  Não é necessário
> acesso ao código fonte do programa da Receita Federal para fazê-lo.  Não
> fica nem mais difícil.
>
> Também não precisa do código fonte para adulterar o programa.  Eu mesmo,
> alterando apenas um byte do binário do programa distribuído pela RFB,
> consegui que ele calculasse o imposto devido como zero.  (Não seria mais
> difícil adulterar o trecho que grava a declaração para que a “grave”
> também num servidor na Internet, sem que o usuário sequer perceba, se
> não monitorar cuidadosamente suas conexões de Internet.)  Achei por bem
> não publicar qual byte alterar, pois o resultado seria apenas surpresa
> desagradável para quem tentasse levar vantagem com isso.  Supor que isso
> não seria detectado é, novamente, ingenuidade sobre os processos.  Se
> houver dúvida sobre a facilidade de fazer essas coisas, disponho-me a
> publicar os procedimentos, ou até mesmo as versões assim adulteradas.
>
> Se o sistema de recepção e processamento de declarações fosse vulnerável
> a ponto de aceitar declarações resultantes de programas assim
> adulterados, profissionais do crime já estariam se valendo desse tipo de
> subterfúgio.  Técnicos responsáveis pelo desenvolvimento desse sistema,
> que têm o conhecimento para avaliar a situação, entendem esse risco, e
> portanto verificam que os resultados de cálculos incluídos na declaração
> entregue são coerentes com a legislação, ao invés de confiar cegamente
> no que se recebe do contribuinte, da mesma forma que se faria com uma
> declaração em papel.
>
> Resulta daí que não há risco em expor o código fonte do programa, nem
> mesmo em permitir modificações.  Seria, de fato, muito saudável
> permiti-las.  Alguém poderia melhorar o programa, a fim de aconselhar o
> contribuinte, por exemplo, sobre fazer a declaração conjunta ou
> separada.  Ou facilitar a entrada de dados para aqueles que preenchem
> dúzias ou centenas de declarações para seus clientes.  Não há razão, nem
> faz sentido, nem é permitido por lei que algo desenvolvido com recursos
> públicos não seja público, não seja fiscalizável pelo público que pagou
> pelo desenvolvimento, à exceção de algumas questões não relacionadas, de
> privacidade e de segurança nacional, como estabelece a lei 11.111.
>
> De fato, há mais apoio legal para que seja público, como por exemplo a
> Instrução Normativa #4 da SLTI, que regula o desenvolvimento, a
> contratação e a publicação de software por agentes da administração
> pública direta, como a Receita Federal.  Dentre as estipulações, consta
> a de publicar o programa como Software Livre, no Portal do Software
> Público Brasileiro, uma referência internacional no compartilhamento de
> soluções de software entre administrações públicas, e também os públicos
> aos quais as administrações públicas servem, ou deveriam servir.  A RFB,
> ao deixar de cumprir essa Instrução Normativa, em vigor já há um ano,
> destoa da opção pelo Software Livre, que respeita seus usuários, tanto
> do Governo Federal quanto da empresa que desenvolve esse programa.
>
> Entendo que a decisão de descumprir a lei não seja uma decisão técnica,
> mas burocrática, e imagino que este canal espere relatórios de problemas
> técnicos.  Lamentavelmente, estes ficam praticamente inviabilizados
> pelas decisões burocráticas.  Espero que essa inviabilização não seja
> intencional, e que esta mensagem seja encaminhada aos que possam
> reverter essa decisão infeliz, a fim de que cidadãos possam ajudar a
> versão de testes a cumprir seu propósito, e a que a versão final
> respeite os cidadãos, a lei vigente aplicável à administração pública e
> a Constituição Federal de 1988, inclusive os princípios constitucionais
> impostos à administração pública.
>
> --
> Alexandre Oliva, freedom fighter    
> http://FSFLA.org/~lxoliva/<http://FSFLA.org/%7Elxoliva/>
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist      Red Hat Brazil Compiler Engineer
> _______________________________________________
> PSL-Brasil mailing list
> PSL-Brasil@listas.softwarelivre.org
> http://listas.softwarelivre.org/mailman/listinfo/psl-brasil
> Regras da lista:
> http://twiki.softwarelivre.org/bin/view/PSLBrasil/RegrasDaListaPSLBrasil
> SAIR DA LISTA ou trocar a senha:
> http://listas.softwarelivre.org/mailman/options/psl-brasil
>



-- 
Gabriel Cabaleiro Peixoto
Linux User Nº 229057
ICQ : 25725305
Jabber : gabr...@jabber-br.org
_______________________________________________
PSL-Brasil mailing list
PSL-Brasil@listas.softwarelivre.org
http://listas.softwarelivre.org/mailman/listinfo/psl-brasil
Regras da lista:
http://twiki.softwarelivre.org/bin/view/PSLBrasil/RegrasDaListaPSLBrasil
SAIR DA LISTA ou trocar a senha:
http://listas.softwarelivre.org/mailman/options/psl-brasil

Responder a