Pablo e demais,

Creio que, para o contexto, não é importante o fato dos usuários não quererem saber de auditar código, ou de pagar a terceiros para fazê-lo. Para se avaliar a natureza do sentimento de segurança que um usuário pode ter em relação a um software, mais importante é o fato de que numa situação ele PODE, e noutra ele NÃO PODE.

O contexto desse debate é a pergunta original do Kaminski: "como provar que um software é seguro?" (para a qual a resposta oferecida, da qual ninguém aqui parece discordar diretamente, é: "auditando"). Já que leigo não audita, e o contexto da pergunta era o de como convencer um órgão público a abrir o código de um software sensível, esse contexto remete a discussão para um exame da natureza de possíveis "provas".

Concordamos que o sentimento de segurança de um leigo, inclusive do burocrata que decide se abre ou não o código, se baseia em confiança na auditagem de terceiros. Quais terceiros? Eis a questão a que nos remete, então, o contexto desse thread. Em resposta, sua contribuição abaixo aborda de forma completa a opção de quem escolhe software proprietário, mas apenas parcialmente as opções de quem escolhe software livre. Gostaria de completá-la, já que esta lista é sobre software livre.

Ressaltar o que o usuário faz ou não faz em relação à auditabilidade, em detrimento de que ele pode ou não pode fazer, é manter-se preso à lógica do modelo proprietário, que trata desenvolvedor e usuário como públicos isolados. Na lógica FOSS qualquer usuário pode ser distribuidor e também desenvolvedor, contribuindo para um software cuja utilidade e/ou disseminação lhe interesse.

A lógica do modelo proprietário ilumina, nesse contexto, o fato de que o usuário termina tendo que confiar, qualquer que seja a licença, no desenvolvedor do software, enquanto a lógica do modelo FOSS consegue iluminar, nesse contexto, uma diferença qualitativa entre as duas situações. O contexto, vale lembrar, não é o de um concurso de popularidade para se saber qual critério (de em quem confiar) é o preferido. Sabemos que, numa sociedade consumista, o fetiche da marca vencerá este. O contexto é o de um concurso de qualidade, para se saber qual critério redunda em sentimento menos vulnerável a engodos e auto-enganos. Sabemos que, num debate honesto, esta é melhor maneira de responder à pergunta retórica "como provar", colocada por um advogado.

Na situação que voce descreve, em que o usuário prefere que uma empresa lhe diga que o software é seguro, na lógica do modelo FOSS "empresa" ganha o sentido de empreendimento. Empreendimento que será controlado por uma só companhia, caso o software seja proprietário, ou por uma comunidade de desenvolvedores interessados, caso o software seja livre.

A diferença qualitativa que a lógica do modelo FOSS assim ilumina é a seguinte: as chances de haver discrepâncias entre o que diz a empresa sobre o código, e o que faz o código, são maiores no primeiro caso (proprietário) que no segundo (livre). Pois no primeiro caso os interesses do desenvolvedor são monolíticos, sendo o desenvolvedor singular, e no segundo caso esses interesses são mediados, sendo o desenvolvedor plural. No primeiro caso, entre os maiores interesses está o de manter a "preferência" (dependência) do usuário, e no segundo caso, está o de se evitar forks.

Minhas colocações são no sentido de afirmar que essa diferença potencializa conflitos de interesse, entre usuário e "empresa", em maior grau no primeiro caso que no segundo. Para coletar evidências empíricas disso basta examinar o ciclo de descoberta, classificação e correção de falhas que representam vulnerabilidades ou portas de fundo exploráveis em ataques a softwares-commodities (SOs, suites de escritório, SGBDs, servidores web, de email, etc.).

Sobre portas de fundo, por exemplo, quando um exploit vendido por uma quadrilha russa revelou revelou que havia porta de fundo nas bibliotecas de visualização do WMF, diante da descoberta de que ela ali estava, não documentada, há quase quinze anos (desde o NT) o desenvolvedor preferiu questionar a suspeita de que se tratava de algo intencional, alegando tratar-se de falha que, nesses quase quinze anos, lhe havia passado desapercebido, agredindo o bom senso de quem entende de programação e desassemblou o código envolvido.

Enquanto a notícia que tenho a respeito de situações semelhantes em projetos FOSS importantes, como o do Kernel Linux por exemplo, é de que a insersão sorrateira de código que poderia operar como porta de fundo geralmente não tem passado desapercebida por mais do que uma semana, por parte de quem contribui para manter o trecho de código afetado.

Se esse tipo de evidência empírica for considerada insuficiente, pode-se ainda googlar "zero day exploit" (ou "0-day exploit", ou "0day exploit") para ver como os dois modelos se comparam frente à mais devastadora e sofisticada técnica para praticar crimes por meio digital já posta em uso, e em uso crescente, no ciberespaço.

No meu caso, eu não audito código de software livre que uso. Talvez eu nunca faça isso. Talvez eu nunca pague a ninguém para auditar para mim. Mesmo se eu fosse responsável pela TI de uma instituição, talvez eu tampouco faria isso. Mas eu prefiro confiar na auditagem, interna ao projeto, feita por quem desenvolve colaborativamente o software que eu uso, em coerência com o fato da minha escolha de software levar em conta a qualidade dessa colaboração, e de que ela não existe sem esse tipo de auditagem, do que confiar cegamente no que diz uma empresa monopolista, que, para cumprir a "sua função" no capitalismo hodierno, tem mostrado do que é capaz.

Pablo Sánchez escreveu:
As pessoas não querem saber de auditar o código, porque auditar o código requer cérebro e isso deve doer naqueles que não tem.

Elas preferem, de maneira geral, que seja um software que possa ser auditado no sentido de o que foi feito e quem fez no uso do software, mas não na forma como o software faz.

Para poder auditar um código tem que ser, antes de tudo, uma pessoa que já tenha muita experiência, e quem eu conheço que tem essa experiência não tem o menor interesse em fazer isso pelo salário que pagam por aí, em especial no governo, assim só acabamos tendo garotos que sequer programaram o suficiente ou estudaram o suficiente de programação e em especial hackig (dissassembling, virologias, cryptografias, criptovirologia, etc) para ter capacidade técnica de fazer tais análises.

Um auditor de código bom, não sai por menos de 12.000 por mês, e ninguém quer pagar isso, afinal de contas essa pessoa para de produzir trabalho próprio para verificar (e possivelmente corrigir) código dos outros.

Os custos são elevados em auditoria, por isso ninguém quer fazer. Preferem que uma empresa lhes diga(minta) que o código dela é bom, a pegar um na internet e ter que desenbolsar uma grana para que outro diga a mesma coisa de um código livre.

Em 23/04/07, *Omar Kaminski* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> escreveu:

     > Pelo fato do software ser livre, o que está intrínseco é sua
     > auditabilidade. Segurança, até onde o entendimento leigo alcança,
    é algo
     > que dela decorre.
     >
     > A velha questão tem uma velha resposta: O sentimento de segurança em
     > software inauditável é um ato de fé no fornecedor, enquanto em
    software
     > auditável decorre da livre escolha de em quem confiar para auditá-lo.

    Pedro, concordo em gênero, número e grau. Mas é fato que a maioria
    ainda nem
    sabe o que é software livre, quando mais que é auditável. Portanto,
    sugeri
    que é desejável um trabalho direcionado e em paralelo nesse sentido
    (segurança), para "reforçar as estruturas". Uma vez que haja esse
    reconhecimento o resto fica bem mais fácil. E se vier oficialmente, da
    Receita Federal que é a bola da vez, tanto melhor.

    []s

    _______________________________________________
    PSL-Brasil mailing list
    PSL-Brasil@listas.softwarelivre.org
    <mailto:PSL-Brasil@listas.softwarelivre.org>
    http://listas.softwarelivre.org/mailman/listinfo/psl-brasil
    <http://listas.softwarelivre.org/mailman/listinfo/psl-brasil>
    Regras da lista:
    http://twiki.softwarelivre.org/bin/view/PSLBrasil/RegrasDaListaPSLBrasil



------------------------------------------------------------------------

_______________________________________________
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


--
-------------------------------------------
prof. Pedro Antonio Dourado de Rezende /\
Computacao - Universidade de Brasilia /__\
tcp: Libertatis quid superest digitis serva
http://www.cic.unb.br/docentes/pedro/sd.htm
-------------------------------------------
_______________________________________________
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

Responder a