On Wed, Dec 30, 2009 at 2:05 AM, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > On 12/30/2009 07:29 AM, Jon Masters wrote: >> One presumes that such auditing is expensive, lengthy, and not often to >> be repeated. Committing to undertaking a full code audit on every update >> would seem to be a little unreasonable of a request. So I think it's >> obvious that if they want to use an audited version, there will have to >> be a separate audited version. > > Well, I disagree: If they want to use "their auditied version", they haven't > understood how open source works. They qualify as jerks who prefer to use > proprietary forks instead of "paying back" to "upstream" and the wider > user-base. I'm sure any fixes have been contributed back and that any difference in /functionality/ are inconsequential. This reality invalidates your hostile accusation. On that point— please tone down the rhetoric, even if "haven't", "jerks", and "proprietary forks" are fair labels it's rather premature in the conversation to pull them out. This kind of name calling shuts down rational thinking. The concern here has nothing to do with the material functionality or directly measurable quality of libtommath, but instead it has everything to do with the color of the bits (http://ansuz.sooke.bc.ca/lawpoli/colour/2004061001.php). The audited version has a quality which is not held by any other version, but the quality in question is not an aspect of the functionality. It's the quality of being assured. There is nothing incompatible between assurance and open-source, although assurance is something that few open source packages bother providing today, partially because assurance is so costly. Thus the interest in formal methods (http://www.dwheeler.com/essays/oss_software_assurance.pdf), as they can theoretically lower the lifetime costs of high assurance. Crypto/bignum libraries evolve slowly enough that it isn't at all surprising to see even soft-assurances being seen as more valuable than improvements to the code. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
