Fernando, Parece-me que é justamente o argumento que você dá (dificuldade na tradução e escassês de tempo) que forçaram o Paulo Gustavo a enviar a matéria em inglês. Em outras palavras: todos têm problemas semelhantes.
Mas para facilitar, traduzo o assunto: "Fonte aberto x fonte fechado". Discorre sobre as diferenças entre as duas modalidades de código de programação usados hoje em dia. Muita gente aqui na lista não têm interesse no assunto. Os que tiverem podem fazer um esforcinho e traduzi-lo. Ou então pedir ajuda. Roger Chadel A respeito de [VotoEletronico] Re: Open Source x Closed Source, em 21/02/2006, 11:07, fernando gonçalves escreveu: fg> Olá Paulo fg> Paz e Bem fg> fg> Queira inviar mensagem em Português. fg> fg> Obrigado. fg> fg> At. Dificuldade na tradução e escasses de tempo justificam o pedido. fg> fg> fg> Paulo Gustavo Sampaio Andrade <[EMAIL PROTECTED]> escreveu: fg> Wide Open Source fg> Elias Levy, SecurityFocus 2000-04-17 fg> Is Open Source really more secure than closed? Elias Levy says fg> there's a little security in obscurity. fg> One of the great rallying cries from the Open Source community is fg> the assertion that Open Source Software (OSS) is, by its very fg> nature, less likely to contain security vulnerabilities, including fg> back doors, than closed source software. The reality is far more complex and nuanced. fg> Advocates derive their dogmatic! faith in the implicit security fg> of Open Source code from the concept of "peer review," a fg> cornerstone of the scientific process in which published papers fg> and theories are scrutinized by experts other than the authors. fg> The more peers that review the work, the less likely it is that it fg> will contains errors, and the more likely it is to become accepted. fg> Open Source apostles believe that releasing the source code for a fg> piece of software subjects it to the same kind of peer review as a fg> quantum physics theory published in a scientific journal. Other fg> programmers, the theory goes, will review the code for security fg> vulnerabilities, reveal and fix them, and thus the number of new fg> vulnerabilities introduced and discovered in the software will fg> decrease over time when compared to similar closed source software. fg> It's a nice theory, and in the ideal Open Source world, it would fg> even be true. But in the real world, there are a variety of fg> factors that effect how secure Open Source Softwa! re really is. fg> Sure, the source code is available. But is anyone reading it? fg> If Open Source were the panacea some think it is, then every fg> security hole described, fixed and announced to the public would fg> come from people analyzing the source code for security fg> vulnerabilities, such as the folks at OpenBSD, the Linux Auditing fg> Project, or the developers or users of the application. fg> But there have been plenty of security vulnerabilities in Open fg> Source Software that were discovered, not by peer review, but by fg> black hats. Some security holes aren't discovered by the good guys fg> until an attacker's tools are found on a compromised site, network fg> traffic captured during an intrusion turns up signs of the fg> exploit, or knowledge of the bug finally bubbles up from the underground. fg> Why is this? When the security company Trusted Information fg> Systems (TIS) began making the source code of their Gauntlet fg> firewall available to their customers many years ago, they fg> believed th! at their clients would check for themselves how fg> secure the product was. What they found instead was that very few fg> people outside of TIS ever sent in feedback, bug reports or fg> vulnerabilities. Nobody, it seems, is reading the source. fg> The fact is, most open source users run the software, but don't fg> personally read the code. They just assume that someone else will fg> do the auditing for them, and too often, it's the bad guys. fg> Even if people are reviewing the code, that doesn't mean they're qualified to do so. fg> In the scientific world, peer review works because the people fg> doing the reviewing possess a comparable, or higher, technical fg> caliber and level of authority on the subject matter than the author. fg> It is generally true that the more people reviewing a piece of fg> code, the less likely it is the code will have a security flaw. fg> But a single well-trained reviewer who understands security and fg> what the code is trying to accomplish will be more effective than fg> a hund! red people who just recently learned how to program. fg> It is easy to hide vulnerabilities in complex, little understood and undocumented source code. fg> Old versions of the Sendmail mail transport agent implemented a fg> DEBUG SMTP command that allowed the connecting user to specify a fg> set of commands instead of an email address to receive the fg> message. This was one of the vulnerabilities exploited by the notorious Morris Internet worm. fg> Sendmail is one of the oldest examples of open source software, fg> yet this vulnerability, and many others, lay unfixed a long time. fg> For years Sendmail was plagued by security problems, because this fg> monolithic programs was very large, complicated, and little understood but for a few. fg> Vulnerabilities can be a lot more subtle than the Sendmail DEBUG fg> command. How many people really understand the ins and outs of a fg> kernel based NFS server? Are we sure its not leaking file handles fg> in some instances? Ssh 1.2.27 is over seventy-one thousand! lines fg> of code (client and server). Are we sure a subtle flaw does not fg> weakening its key strength to only 40-bits? fg> There is no strong guarantee that source code and binaries of an fg> application have any real relationship. fg> All the benefits of source code peer review are irrelevant if you fg> can not be certain that a given binary application is the result of the reviewed source code. fg> Ken Thompson made this very clear during his 1983 Turing Award fg> lecture to the ACM, in which he revealed a shocking, and subtle, fg> software subversion technique that's still illustrative seventeen years later. fg> Thompson modified the UNIX C compiler to recognize when the login fg> program was being compiled, and to insert a back door in the fg> resulting binary code such that it would allow him to login as any user using a "magic" password. fg> Anyone reviewing the compiler source code could have found the fg> back door, except that Thompson then modified the compiler so that fg> whenever it compiled itself, it would insert both the code that fg> inserts the login back door, as well as code that modifies the fg> compiler. With this new binary he removed the modifications he had made and recompiled again. fg> He now had a trojaned compiler and clean source code. Anyone fg> using his compiler to compile either the login program , or the fg> compiler, would propagate his back doors. fg> The reason his attack worked is because the compiler has a fg> bootstrapping problem. You need a compiler to compile the fg> compiler. You must obtain a binary copy of the compiler before you fg> can use it to translate the compiler source code into a binary. fg> There was no guarantee that the binary compiler you were using was fg> really related to the source code of the same. fg> Most applications do not have this bootstrapping problem. But how fg> many users of open source software compile all of their applications from source? fg> A great number of open source users install precompiled software fg> distributions such a! s those from RedHat or Debian from CD-ROMs fg> or FTP sites without thinking twice whether the binary fg> applications have any real relationship to their source code. fg> While some of the binaries are cryptographically signed to verify fg> the identity of the packager, they make no other guarantees. Until fg> the day comes when a trusted distributor of binary open source fg> software can issue a strong cryptographic guarantee that a fg> particular binary is the result of a given source, any security fg> expectations one may have about the source can't be transferred to the binary. fg> Open Source makes it easy for the bad guys to find vulnerabilities. fg> Whatever potential Open Source has to make it easy for the good fg> guys to proactively find security vulnerabilities, also goes to the bad guys. fg> It is true that a black hat can find vulnerabilities in a fg> binary-only application, and that they can attempt to steal the fg> source code to the application from its closed source. But in the fg> same amount of! time they can do that, they can audit ten fg> different open source applications for vulnerabilities. A bad guy fg> that can operate a hex editor can probably manage to grep source code for 'strcpy'. fg> Security through obscurity is not something you should depend on, fg> but it can be an effective deterrent if the attacker can find an easier target. fg> So does all this mean Open Source Software is no better than fg> closed source software when it comes to security vulnerabilities? fg> No. Open Source Software certainly does have the potential to be fg> more secure than its closed source counterpart. fg> But make no mistake, simply being open source is no guarantee of security. fg> Fonte: http://www.securityfocus.com/news/19 fg> fg> Yahoo! Search fg> Dê uma espiadinha e saiba tudo sobre o Big Brother Brasil. -- Grande abraço, Roger Chadel -------- //// O TSE deve voltar a ser um tribunal |---//---| | / | Se a urna não imprimir, seu voto pode sumir! |--------| www.votoseguro.org -------- Extraido de minha coleção de taglines: Era tão azarado que, se quisesse achar uma agulha no palheiro, era só sentar-se nele. /"\ \ / Campanha da fita ASCII - contra mail html X ASCII ribbon campaign - against html mail / \ ______________________________________________________________ O texto acima e' de inteira e exclusiva responsabilidade de seu autor, conforme identificado no campo "remetente", e nao representa necessariamente o ponto de vista do Forum do Voto-E O Forum do Voto-E visa debater a confibilidade dos sistemas eleitorais informatizados, em especial o brasileiro, e dos sistemas de assinatura digital e infraestrutura de chaves publicas. __________________________________________________ Pagina, Jornal e Forum do Voto Eletronico http://www.votoseguro.org __________________________________________________
