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
