packaging a static library

Gregory Maxwell gmaxwell at gmail.com
Wed Dec 30 09:07:04 UTC 2009


On Wed, Dec 30, 2009 at 2:05 AM, Ralf Corsepius <rc040203 at freenet.de> 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.




More information about the fedora-devel-list mailing list