Re: packaging a static library
On Wed, Dec 30, 2009 at 2:05 AM, Ralf Corsepius rc040...@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
OCaml in Rawhide upgraded to 3.11.2-rc1
All the existing ocaml-* packages in Rawhide depend on ocaml(runtime) = 3.11.1 which means they will all have broken deps and need rebuilding. A simple bumpspec + rebuild should be sufficient. If any provenpackagers are feeling particularly bored this week ... Otherwise I'll try to do it in my spare time this week or next. Thanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can some provenpackager bump openvpn in EL-5
On Wed, 2009-12-30 at 08:55 +0530, Huzaifa Sidhpurwala wrote: Hi, I have this bz open for some time now, with no response. https://bugzilla.redhat.com/show_bug.cgi?id=544944 Can some one with proven packager access bump the EL-5 version to the latest one in devel. Even though any proven packager could do the change, that bug does not fall in the items listed in the proven packager policy [1]. You haven't listed any problems with the current package, you're just requesting a version upgrade. Version upgrades should be performed by the package maintainer. This especially holds in EPEL, which should be a slowly moving distribution. [1] http://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can some provenpackager bump openvpn in EL-5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jussi Lehtola wrote: On Wed, 2009-12-30 at 08:55 +0530, Huzaifa Sidhpurwala wrote: Hi, I have this bz open for some time now, with no response. https://bugzilla.redhat.com/show_bug.cgi?id=544944 Can some one with proven packager access bump the EL-5 version to the latest one in devel. Even though any proven packager could do the change, that bug does not fall in the items listed in the proven packager policy [1]. You haven't listed any problems with the current package, you're just requesting a version upgrade. The version of openvpn in EPEL is an upstream rc version. The Changelog file upstream shows a lot of bugs have been fixed and it would be nice to have it fixed in EPEL too. Version upgrades should be performed by the package maintainer. This especially holds in EPEL, which should be a slowly moving distribution. In this case the bz is around 2.5 weeks old, with absolutely no response. What is the policy to get the package updated in this case? [1] http://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLOzPgzHDc8tpb2uURAkRbAJ9fEMK2uOwbaeoDPb0f5FWPAt0NzACfX5Ue BtBtFPMo3x2Pe9SPdWZTLVM= =w3lz -END PGP SIGNATURE- -- 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 rc040...@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.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: Can some provenpackager bump openvpn in EL-5
On Wed, 2009-12-30 at 16:35 +0530, Huzaifa Sidhpurwala wrote: Jussi Lehtola wrote: Even though any proven packager could do the change, that bug does not fall in the items listed in the proven packager policy [1]. You haven't listed any problems with the current package, you're just requesting a version upgrade. The version of openvpn in EPEL is an upstream rc version. The Changelog file upstream shows a lot of bugs have been fixed and it would be nice to have it fixed in EPEL too. OK, that's starting to sound better. Version upgrades should be performed by the package maintainer. This especially holds in EPEL, which should be a slowly moving distribution. In this case the bz is around 2.5 weeks old, with absolutely no response. What is the policy to get the package updated in this case? See the nonresponsive maintainer policy at https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Thinking of contributing to Sugar?
Here's your chance! Join us for the upcoming weekly Fedora Sugar meetings in #fedora-olpc starting tomorrow, Dec 31 on 1500 UTC [1]. We're going to talk about packaging (especially Sugar Activities) and all kinds of stuff that helps us making the F13 Sugar experience better. You don't know how to package things for Fedora? Don't worry, we've a Fedora Classroom session coming up on Jan 6 - more details here [2]. --Sebastian [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=12day=31year=2009hour=15min=0sec=0p1=0 [2] https://fedoraproject.org/wiki/Classroom#Upcoming_Classes -- 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: OCaml in Rawhide upgraded to 3.11.2-rc1
On Wed, Dec 30, 2009 at 09:40:13AM +, Richard W.M. Jones wrote: If any provenpackagers are feeling particularly bored this week ... Otherwise I'll try to do it in my spare time this week or next. I did all but about 10 of them. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- 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
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
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
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: ABRT considered painful
Michael Schwendt wrote: What's wrong with ABRT? My main beef with it is that it reports its crashes to the downstream bug tracker when really the right people to fix them are the upstream developers. KCrash/DrKonqi is much better there. 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
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 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
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
[Bug 544245] CVE-2009-3585 rt3: session hijack
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=544245 --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2009-12-31 01:54:45 EDT --- rt3-3.6.10-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 544245] CVE-2009-3585 rt3: session hijack
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=544245 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||3.6.10-1.el5 Resolution||ERRATA -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
