packaging a static library
 

Hi,

OLPC's security system uses libtomcrypt / tomsfastmath, both at the
Linux level and the firmware level.

OLPC has previously had a specific version of tomcrypt/tommath
profesionally audited for security reasons. So we obviously want to
stick with that version.

A few packages we have in Fedora currently use this frozen, audited
version - we do so by shipping duplicate copies of that source code
within the individual packages, rather than linking against the dynamic
systemwide equivalents.

As we're now looking at making another package which uses yet another
duplicate copy of this code base I'm wondering if we can do it better.

Could I add a package, named olpc-bios-crypto-devel (a subpackage of the
to-be-packaged olpc-bios-crypto), which installs the .a files for the
audited libraries somewhere on the system?

Then the individual components that rely on this library (e.g. bitfrost,
olpc-contents, olpc-bios-crypto) would have a BuildRequires dependency
on olpc-bios-crypto-devel and build against the 'systemwide' static .a
library files.

Or am I going too far against common packaging practice at this point?
Any alternative suggestions?

Thanks,
Daniel


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

packaging a static library
 

On 12/29/2009 11:52 AM, Daniel Drake wrote:

Hi,

OLPC's security system uses libtomcrypt / tomsfastmath, both at the
Linux level and the firmware level.

OLPC has previously had a specific version of tomcrypt/tommath
profesionally audited for security reasons. So we obviously want to
stick with that version.

A few packages we have in Fedora currently use this frozen, audited
version - we do so by shipping duplicate copies of that source code
within the individual packages, rather than linking against the dynamic
systemwide equivalents.

As we're now looking at making another package which uses yet another
duplicate copy of this code base I'm wondering if we can do it better.

Could I add a package, named olpc-bios-crypto-devel (a subpackage of the
to-be-packaged olpc-bios-crypto), which installs the .a files for the
audited libraries somewhere on the system?

Then the individual components that rely on this library (e.g. bitfrost,
olpc-contents, olpc-bios-crypto) would have a BuildRequires dependency
on olpc-bios-crypto-devel and build against the 'systemwide' static .a
library files.

Or am I going too far against common packaging practice at this point?
Yes. You are outsmarting yourselves and not doing good to other users of
the libraries, IMO.


If all users of the library were using the same, identical shared
versions, everybody would benefit from your "auditing", maintainers
would benefit from "issues being fixed" at one place, users would
benefit from you not shipping statically linked packages.



Any alternative suggestions?
Use system-wide, shared versions only, unless there are technical
reasons for not doing so - Your rationale doesn't provide such.


Ralf

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

packaging a static library
 

On Tue, 29 Dec 2009 10:52:54 +0000, Daniel wrote:

> Hi,
>
> OLPC's security system uses libtomcrypt / tomsfastmath, both at the
> Linux level and the firmware level.
>
> OLPC has previously had a specific version of tomcrypt/tommath
> profesionally audited for security reasons. So we obviously want to
> stick with that version.
>
> A few packages we have in Fedora currently use this frozen, audited
> version - we do so by shipping duplicate copies of that source code
> within the individual packages, rather than linking against the dynamic
> systemwide equivalents.
>
> As we're now looking at making another package which uses yet another
> duplicate copy of this code base I'm wondering if we can do it better.
>
> Could I add a package, named olpc-bios-crypto-devel (a subpackage of the
> to-be-packaged olpc-bios-crypto), which installs the .a files for the
> audited libraries somewhere on the system?
>
> Then the individual components that rely on this library (e.g. bitfrost,
> olpc-contents, olpc-bios-crypto) would have a BuildRequires dependency
> on olpc-bios-crypto-devel and build against the 'systemwide' static .a
> library files.
>
> Or am I going too far against common packaging practice at this point?
> Any alternative suggestions?

There is

https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

and

https://fedoraproject.org/wiki/Packaging:Guidelines#Staticly_Linking_Executables

already. These guidelines explain how to name static library packages
and how to build-require them.

You didn't comment on those guidelines at all.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

packaging a static library
 

On Tue, 2009-12-29 at 14:41 +0100, Ralf Corsepius wrote:
> On 12/29/2009 11:52 AM, Daniel Drake wrote:

> > OLPC has previously had a specific version of tomcrypt/tommath
> > profesionally audited for security reasons. So we obviously want to
> > stick with that version.
> >
> > A few packages we have in Fedora currently use this frozen, audited
> > version - we do so by shipping duplicate copies of that source code
> > within the individual packages, rather than linking against the dynamic
> > systemwide equivalents.

<snip>

> > Or am I going too far against common packaging practice at this point?
> Yes. You are outsmarting yourselves and not doing good to other users of
> the libraries, IMO.

I think the argument could go both ways. In the case of OLPC, they're
providing Open Source pieces that are similar to things like the TPM
technologies in other systems. If a certain major PC chip manufacturer
decided to release all of the design and code schematics for their TPM
chips, the community would probably praise them...and then wonder what
the potential could be for a bad library release to undermine them.

> If all users of the library were using the same, identical shared
> versions, everybody would benefit from your "auditing", maintainers
> would benefit from "issues being fixed" at one place, users would
> benefit from you not shipping statically linked packages.

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.

Jon.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

packaging a static library
 

On 12/30/2009 07:29 AM, Jon Masters wrote:

On Tue, 2009-12-29 at 14:41 +0100, Ralf Corsepius wrote:

On 12/29/2009 11:52 AM, Daniel Drake wrote:



OLPC has previously had a specific version of tomcrypt/tommath
profesionally audited for security reasons. So we obviously want to
stick with that version.

A few packages we have in Fedora currently use this frozen, audited
version - we do so by shipping duplicate copies of that source code
within the individual packages, rather than linking against the dynamic
systemwide equivalents.



If all users of the library were using the same, identical shared
versions, everybody would benefit from your "auditing", maintainers
would benefit from "issues being fixed" at one place, users would
benefit from you not shipping statically linked packages.


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.


Ralf

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

packaging a static library
 

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

packaging a static library
 

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

Um - the audited version is just frozen. It's not hidden, it's not
proprietary, and it would be nice if you look at things before calling
people jerks.

TomsFastMath ( http://tfm.libtomcrypt.com/ ) has been a public FOSS
project for a while, it is packaged in a number of distros (FreeBSD
seems to carry a version, Debian has it, etc). The special "frozen"
version we carry is publicly available in our git repo, and AFAIK the
upstream author was 100% involved in our audit process. The results
are definitely openly available too. So put down the pitchfork
already.

Let's focus on the important bit: we need a frozen version of a
library (that, btw, is useful, and is not in Fedora yet :-) ). What's
the best practice for that? I don't see why we'd need to embed it
statically anywhere (except OFW of course).

cheers,



m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

packaging a static library
 

On Wed, 2009-12-30 at 12:25 +0100, Martin Langhoff wrote:
> Let's focus on the important bit: we need a frozen version of a
> library (that, btw, is useful, and is not in Fedora yet :-) ). What's
> the best practice for that? I don't see why we'd need to embed it
> statically anywhere (except OFW of course).

The upstream library is already in Fedora as a shared library.
I guess the approach I will take is to install our audited version as a
shared library under a different name (libtommath_olpc?) which the
components will then dynamically link against.

Daniel


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

packaging a static library
 

On Wed, Dec 30, 2009 at 2:37 PM, Daniel Drake <dsd@laptop.org> wrote:
> The upstream library is already in Fedora as a shared library.

Is it now? Great -- I had seen some failed attempts to get it into
Fedora long ago.

> I guess the approach I will take is to install our audited version as a
> shared library under a different name (libtommath_olpc?) which the
> components will then dynamically link against.

Sounds right. And we control the package tightly to ensure we have what we want.

cheers,


m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

packaging a static library
 

ons 2009-12-30 klockan 13:37 +0000 skrev Daniel Drake:

> I guess the approach I will take is to install our audited version as a
> shared library under a different name (libtommath_olpc?) which the

libtommath-audited

No sense making it look like it's only for OLPC use. If others want
audit-coloured bits they can use it too.

/abo


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list