Gentoo Archives: gentoo-security

From: Jeremy Huddleston <eradicator@g.o>
To: gentoo-security@l.g.o
Cc: gentoo-core@l.g.o
Subject: [gentoo-security] Security concerns and portage versioning
Date: Wed, 18 Feb 2004 02:57:50
1 I'm CCing -core on this as I think it's something worthy of getting
2 insights from people outside of just the security list as it would
3 affect portage and others... If that was inappropriate, I apologize.
5 So on my way home tonight, I was thinking about some concerns regarding
6 security fixes and portage versioning. AFAIK, the "official" policy
7 seems to be 'revision bump with the update.' But what do we do if
8 multiple versions of a package are afflicted. What if 1.2-r1 and 1.2-r2
9 are both inflicted, but r2 introduces new features in a patchset and is
10 not ready to be stable? How do we handle this currently? My instinct
11 on the matter would be:
13 r1 + fix -> r3
14 r2 + fix -> r4
16 But this seems a bit odd to me. So an idea I had was to add an
17 aditional field to the portage version string to indicate a security
18 fix.. thus to use the recent xfree86 buffer overflows as an example
19 (xfree86-4.3.0-r3 had 2 security problems that were fixed in -r4 and
20 -r5) the fixes might have been released as xfree86-4.3.0-r3-s1 and
21 xfree86-4.3.0-r3-s2.
23 This would greatly ease confusion in cases like the one in the second
24 paragraph above if we have >=1.2-r2 in another ebuild's DEPEND. As we
25 have it now, r3 (r1 + fix) would satisfy that DEPEND, but that's not
26 what was intended. By using the -s# version suffix it keeps DEPENDS
27 straight and also aids people wanting to only update security fixes
28 rather than feature additions.
30 portage could implement 'emerge security' which only updates packages
31 that have a new -s# (security bump) available.


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-security] Security concerns and portage versioning Calum <gentoo-security@××××××××××××.uk>