Re: packaging a static library
On 12/30/2009 05:01 PM, Kevin Kofler wrote: > Tom "spot" Callaway wrote: >> FWIW, I'm pretty sure this is not against current Fedora policies, >> assuming that the libtommath maintainer signs off on it and there is no >> conflict between the two packages. > > I guess it's indeed not against the letter of the policies, it's still > against their spirit though. Compat packages make sense where they're > required for technical or licensing reasons (the latter case being > particularly annoying though). In this case, they're neither. And our > objectives are to ship the latest software, not an old version just because > it went through some sort of formal audit and/or certification. Well, my concerns around this are: 1. That this library will be impossible to bugfix without losing its "audit approval" 2. (A) That the OLPC dependent packages in Fedora which depend on this library will want to link against this compat package rather than the current revision OR 2. (B) That the OLPC dependent packages in Fedora will also need to be forked to link against this compat package rather than the current revision. However, it is worth noting that the OLPC OS build is a Fedora Remix, rather than a spin, so they may be able to get by with simply having the compat libtommath-audited package (containing shared rather than static libs) present, and not making any other changes in Fedora. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
On Wed, Dec 30, 2009 at 04:42:35PM -0500, Tom spot Callaway wrote: > > FWIW, I'm pretty sure this is not against current Fedora policies, > assuming that the libtommath maintainer signs off on it and there is no > conflict between the two packages. Indeed, it is just a compat library (and I think that having a rightly packaged static library alongside wouldn't be bad). Nothing in fedora, however, should link against it, that would be against the guidelines, and also not very fedora-like. -- Pat -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
Tom "spot" Callaway wrote: > FWIW, I'm pretty sure this is not against current Fedora policies, > assuming that the libtommath maintainer signs off on it and there is no > conflict between the two packages. I guess it's indeed not against the letter of the policies, it's still against their spirit though. Compat packages make sense where they're required for technical or licensing reasons (the latter case being particularly annoying though). In this case, they're neither. And our objectives are to ship the latest software, not an old version just because it went through some sort of formal audit and/or certification. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
On 12/30/2009 03:58 PM, Kevin Kofler wrote: > Daniel Drake wrote: >> 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. > > While that at least conforms to our packaging guidelines, I think this is > still against Fedora policies, in particular the Fedora Objectives. We want > to ship the current software, not old audited one. Fedora is not a certified > distribution, it's an up-to-date distribution. FWIW, I'm pretty sure this is not against current Fedora policies, assuming that the libtommath maintainer signs off on it and there is no conflict between the two packages. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
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. This is a bad idea and inconsistent with what Fedora is about. If you want that sort of things, you need to go back to maintaining separate OLPC branches. In Fedora, you're supposed to use the current version whenever technically possible. > 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. This is not allowed and the packages MUST be fixed ASAP (in fact they should never have passed review in the first place, this is a failure of our review process). (And if you refuse to fix it, I'll have to escalate it to FESCo.) > 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. Yes, just use the system version. > 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? Static libraries suck, your later suggestion of a shared audited version is better, but still the right solution is to just use the current version. > 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. Common practice in Fedora is to just use current software and forget about audits. Fedora is not a certified distribution. > Any alternative suggestions? See above. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
Daniel Drake wrote: > 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. While that at least conforms to our packaging guidelines, I think this is still against Fedora policies, in particular the Fedora Objectives. We want to ship the current software, not old audited one. Fedora is not a certified distribution, it's an up-to-date distribution. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
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). It's just not allowed. Use the system version, audited or not. If you need frozen, audited software, you need to go back to maintaining your own OLPC branch of Fedora, just like RHEL branches off Fedora. Working directly with upstream Fedora means working the upstream Fedora way. Using old components just because they're audited is not the Fedora way, sorry. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
ons 2009-12-30 klockan 13:37 + 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
Re: packaging a static library
On Wed, Dec 30, 2009 at 2:37 PM, Daniel Drake 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.langh...@gmail.com mar...@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
Re: 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
Re: packaging a static library
On Wed, Dec 30, 2009 at 8:05 AM, Ralf Corsepius 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.langh...@gmail.com mar...@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
Re: packaging a static library
On Wed, Dec 30, 2009 at 2:05 AM, Ralf Corsepius 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
Re: 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
Re: 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. > > 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
Re: packaging a static library
On Tue, 29 Dec 2009 10:52:54 +, 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
Re: 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
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
