Re: [gentoo-dev] sys-libs/glibc cleanup
On Tuesday 01 December 2009 00:36:40 Robin H. Johnson wrote: > On Tue, Dec 01, 2009 at 12:19:11AM -0500, Mike Frysinger wrote: > > i plan on culling glibc versions older than 2.6.1. if you need an older > > version in the tree, now is the time to speak up. i didnt see anything > > in the profiles that would cause a problem. > > How is 2.4 support with 2.6.1? > > I've got a box running 2.4.32-hardened-r1 and glibc-2.5-r4 due to an old > commercial application I have to support :-(. if LT_VER is set in the ebuild, then linuxthreads (and thus linux-2.4) should work -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] sys-libs/glibc cleanup
On Tue, Dec 01, 2009 at 12:19:11AM -0500, Mike Frysinger wrote: > i plan on culling glibc versions older than 2.6.1. if you need an older > version in the tree, now is the time to speak up. i didnt see anything in > the > profiles that would cause a problem. How is 2.4 support with 2.6.1? I've got a box running 2.4.32-hardened-r1 and glibc-2.5-r4 due to an old commercial application I have to support :-(. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[gentoo-dev] sys-libs/glibc cleanup
i plan on culling glibc versions older than 2.6.1. if you need an older version in the tree, now is the time to speak up. i didnt see anything in the profiles that would cause a problem. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GPG Infrastructure for Gentoo (Was Council Meeting)
On Mon, Nov 30, 2009 at 04:18:21PM -0500, Richard Freeman wrote: > Antoni Grzymala wrote: > >How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort > >a year ago to summarize the then-current state of things regarding tree > >and package signing, however the matter seems to have lain idle and > >untouched for more than a year since. > One concern I have with the GLEP-57 is that it is a bit hazy on some > of the implementation details, and the current implementation has > some weaknesses. GLEP57 is purely informational. The GLEP on Individual developer signing has not made it into a Draft yet. But you can view the very brief version here: http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/02-developer-process-security?view=markup > I go ahead and sign my commits. However, when I do this I'm signing > the WHOLE manifest. So, if I stabilize foo-1.23-r5 on my arch, at > best I've tested that one particular version of that package works > fine for me. My signature applies to ALL versions of the package > even though I haven't tested those. This was covered in the draft linked above. A larger discussion on it is welcome, as while both competing options exist, neither has a clear advantage over the other. > Now, if we had an unbroken chain of custody then that wouldn't be a > problem. However, repoman commit doesn't enforce this and the > manifest file doesn't really contain any indication of what packages > are assured to what level of confidence. Chain of custody from infrastructure to user is covered in GLEP58 (MetaManifest). > If we want to sign manifests then the only way I see it actually > providing real security benefits is if either: > > 1. The distro does this in the background in some way in a secure > manner (ensuring it happens 100% of the time). See GLEP58. > 2. Every developer signs everything 100% of the time (make it a QA > check). +1 on this. > The instant you have a break in the signature chain you can > potentially have a modification. If somebody cares enough to check > signatures, then they're going to care that the signature means > something. Otherwise it only protects against accidental > modifications, and the hashes already provide pretty good protection > against this. GLEP60 covers the Manifest2 filetypes and better logic on which missing/mismatches should be considered as fatal. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpnHf0P6LRjO.pgp Description: PGP signature
[gentoo-dev] Tree Integrity GLEPS for final review and council approval
On Mon, Nov 30, 2009 at 12:30:51PM +0100, Antoni Grzymala wrote: > I reckon that missing GPG infrastructure is one of the greatest problems > of the Gentoo distribution esp. regarding serious corporate and academic > deployments. > > I can devote some time to helping with the matter. I would certainly like to get that GLEP series completed and out there. There are still two GLEPs in the series that have not yet made it to draft status: http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/02-developer-process-security http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/03-gnupg-policies-and-handling However the main content of GLEPS 58-61 IS ready for the council to approve, and are NOT blocking on the above two items. As such, I would like to present GLEPS 58,59,60,61 for final review, and for the council to vote on their approval during the January meeting. I'm going to summarize them here: GLEP58: Security of distribution ... MetaManifest - - covers all Manifests with a infra-generated parent Manifest. - required for end-to-end validation. - prevents certain package manager attacks. - NO day-to-day developer actions required. GLEP59: Manifest2 hash policies and security implications - - Add SHA512 to all Manifest files. - Schedule removal of SHA1, MD5, RMD160 for 6-18 months after SHA512 addition. - Be prepared to add the NIST hash contest candidates/winner. GLEP60: Manifest2 filetypes --- (Has one TODO that needs clarification). - Breaks down the Manifest2 filetypes into INFOrmational and CRITical. - If the package manager is being strict, then INFO filetypes are treated as CRIT filetypes. - INFO filetypes merely cause a warning on absence. - CRIT filetypes may trigger a delayed OR immediate failure of absence. GLEP61: Manifest2 compression - - Disk space optimization for MetaManifest from GLEP58. There is a prototype of the MetaManifest code here: http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/prototype/ It worked on Portage 2 years ago, but I haven't run it since then. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgptPcV7Hu1uh.pgp Description: PGP signature
Re: [gentoo-dev] GPG Infrastructure for Gentoo (Was Council Meeting)
On Monday 30 November 2009 22:18:21 Richard Freeman wrote: > Antoni Grzymala wrote: > > How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort > > a year ago to summarize the then-current state of things regarding tree > > and package signing, however the matter seems to have lain idle and > > untouched for more than a year since. > > One concern I have with the GLEP-57 is that it is a bit hazy on some of > the implementation details, and the current implementation has some > weaknesses. > > I go ahead and sign my commits. However, when I do this I'm signing the > WHOLE manifest. So, if I stabilize foo-1.23-r5 on my arch, at best I've > tested that one particular version of that package works fine for me. > My signature applies to ALL versions of the package even though I > haven't tested those. > I may be wrong - then please correct me. You don't sign every package versions but Manifest. Thus you somehow prove every file checksum is correct. If there were any changes made on server side, those checksums would be incorrect according to your signed Manifest. Currently any change may be fixed by whoever it is by the same command ebuild foo digest. > Now, if we had an unbroken chain of custody then that wouldn't be a > problem. However, repoman commit doesn't enforce this and the manifest > file doesn't really contain any indication of what packages are assured > to what level of confidence. That's what should be discussed - forcing developers to sign their commits and implementing this support in package managers. > > If we want to sign manifests then the only way I see it actually > providing real security benefits is if either: > > 1. The distro does this in the background in some way in a secure > manner (ensuring it happens 100% of the time). > > 2. Every developer signs everything 100% of the time (make it a QA > check). > > The instant you have a break in the signature chain you can potentially > have a modification. If somebody cares enough to check signatures, then > they're going to care that the signature means something. Otherwise it > only protects against accidental modifications, and the hashes already > provide pretty good protection against this. > That's not really true. I see tips like "if you have digest incorrect, run ebuild foo.ebuild digest" very often. Really small group of people care about broken digests. :( -- Cheers Dawid Węgliński
[gentoo-dev] GPG Infrastructure for Gentoo (Was Council Meeting)
Antoni Grzymala wrote: How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort a year ago to summarize the then-current state of things regarding tree and package signing, however the matter seems to have lain idle and untouched for more than a year since. One concern I have with the GLEP-57 is that it is a bit hazy on some of the implementation details, and the current implementation has some weaknesses. I go ahead and sign my commits. However, when I do this I'm signing the WHOLE manifest. So, if I stabilize foo-1.23-r5 on my arch, at best I've tested that one particular version of that package works fine for me. My signature applies to ALL versions of the package even though I haven't tested those. Now, if we had an unbroken chain of custody then that wouldn't be a problem. However, repoman commit doesn't enforce this and the manifest file doesn't really contain any indication of what packages are assured to what level of confidence. If we want to sign manifests then the only way I see it actually providing real security benefits is if either: 1. The distro does this in the background in some way in a secure manner (ensuring it happens 100% of the time). 2. Every developer signs everything 100% of the time (make it a QA check). The instant you have a break in the signature chain you can potentially have a modification. If somebody cares enough to check signatures, then they're going to care that the signature means something. Otherwise it only protects against accidental modifications, and the hashes already provide pretty good protection against this.
Re: [gentoo-dev] RFC: Add RUBY_TARGETS to USE_EXPAND
On Tue, 6 Oct 2009 15:28:19 +0200, Alex Legler wrote: > I would like to propose the addition of a new USE_EXPAND variable. > I have just commited the changes. -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC
Denis Dupeyron schrieb: > The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want > us to discuss things please let us know in reply to this email. What > is already known is we'll talk about mtime preservation and prefix. > You can find threads about those at: > http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml > http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml > > Denis. > > Hm, i requested the discussion of real multilib support for portage 2 months ago, i requested it for the following council meeting, i requested it for the last council meeting and i requested it for the next council meeting. I hope, it will finally get a place on 7 Dec 2009. I have a git branch with a modified 2.2_rc* version of portage with included multilib support. I already wrote about basic implementation 2 months ago in the conversation on this list with vapier. Since zmedico wants a council-ok before accepting any patches for multilib-support in portage, i request this. My main idea behind this request is, that more people will have a look and there are potentially more people involved in improving it. In addition it allows more people to easily get required 32bit libs the way they want them (specific version, specified USE flags, self-compiled, so up-to-date unlike the emul-linux-x86-* packages). Since the code may change in the future, my idea is to restrict it currently only to 2.2_rc* versions and in addition a required feature (e.g. FEATURES="multilib"). Once everyone is ok with the code and the way it works, it could be proposed as an PMS-update. If other PM-mantainers are interested in improving it before, they are of course free to also help improving the code and the way it works. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: Removing eclasses
Hi, Currently the approach is that you must mark the eclass as deprecated and wait 2 years in order to remove it. I would propose to do it more fine grained. Since portage 2.1.4.0 the environment is stored and preserved, thus eclasses are no longer required for package uninstalls (which is the only reason for above rule). Bit research for history here when 2.1.4.0 or later was stabilised reveals the date Mon Feb 18 09:51:22 2008 UTC. [1] As we can say everyone even stable people potentialy update to before 1st August during individual updates. We can safely assume that after 4 months noone use individual commands and gets it grabbed using @world or @system target. So we can set the date on: 2008-08-01 So we can have 2 case scenario here now. Eclass is newer than this date It can be removed right away since portage is using the environment, thus the eclass would be just wasting space and looking ugly :P Eclass is older than the date Here we need to find out if it is used, and if it is used it needs to go full 2 years period before removal. If it is no-longer used, the 2 years period started ticking when the last ebuild using such eclass was in main tree. Cheers [1] - http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys- apps/portage/portage-2.1.4.4.ebuild?hideattic=0&rev=1.10&view=log Tomáš Chvátal Gentoo Linux Developer [KDE/Overlays/QA/Sunrise/X11] E-Mail : scarab...@gentoo.org GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 GnuPG ID: 03414587 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Deprecated eclasses
Le 30/11/2009 05:26, Jonathan Callen a écrit : gst-plugins.eclass ACK on this one, Gilles and I have been meaning to remove it a long time ago. Thanks for cleaning it all up :) Rémi
[gentoo-dev] Last rite: dev-ruby/{nitro,og,glue,gen}
# Alex Legler (30 Nov 2009) # Dead upstream, fetch issues with gemcutter. # Masking for removal in 30 days. dev-ruby/nitro dev-ruby/glue dev-ruby/gen dev-ruby/og -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC
Antoni Grzymala dixit (2009-11-30, 12:30): > Denis Dupeyron dixit (2009-11-25, 14:50): > > > The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want > > us to discuss things please let us know in reply to this email. What > > is already known is we'll talk about mtime preservation and prefix. > > You can find threads about those at: > > http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml > > http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml > > Hi! > > How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort [...] Forgot the URL, of course: [1] http://www.gentoo.org/proj/en/glep/glep-0057.html -- [a]
Re: [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC
Denis Dupeyron dixit (2009-11-25, 14:50): > The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want > us to discuss things please let us know in reply to this email. What > is already known is we'll talk about mtime preservation and prefix. > You can find threads about those at: > http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml > http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml Hi! How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort a year ago to summarize the then-current state of things regarding tree and package signing, however the matter seems to have lain idle and untouched for more than a year since. I reckon that missing GPG infrastructure is one of the greatest problems of the Gentoo distribution esp. regarding serious corporate and academic deployments. I can devote some time to helping with the matter. Regards, Antoni Grzymała -- [a]
[gentoo-dev] QA last rites for dev-scheme/kawa
# Diego E. Pettenò (30 Nov 2009) # on behalf of QA team # # Fails to build, bug #239819 open October 2008. Solution # in overlay, as usual for lisp-team packages. # # Removal on 2010-01-29 dev-scheme/kawa
