| 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. |
| 4 |
|
| 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: |
| 12 |
|
| 13 |
r1 + fix -> r3 |
| 14 |
r2 + fix -> r4 |
| 15 |
|
| 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. |
| 22 |
|
| 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. |
| 29 |
|
| 30 |
portage could implement 'emerge security' which only updates packages |
| 31 |
that have a new -s# (security bump) available. |
Archives