| 1 |
On Wednesday 18 February 2004 2:57 am, Jeremy Huddleston wrote: |
| 2 |
|
| 3 |
> |
| 4 |
> portage could implement 'emerge security' which only updates packages |
| 5 |
> that have a new -s# (security bump) available. |
| 6 |
|
| 7 |
I still feel that breaking this up a little more would benefit more people. |
| 8 |
|
| 9 |
Maybe I have app-misc/small-app-0.0.1 on my server for whatever reason. |
| 10 |
A symlink vulnerability is discovered in it, which allows a local user to get |
| 11 |
gid = games. |
| 12 |
This is where the remote-root and local-root ideas would be good. |
| 13 |
I would prefer it that when I ran my scripted emerge sync && emerge -up |
| 14 |
remote-root (or whatever) that the output would be blank if there weren't any |
| 15 |
relevant updates. |
| 16 |
|
| 17 |
I run /usr/bin/emerge sync > /dev/null && /usr/bin/emerge -up system | grep |
| 18 |
ebuild each night at about 4.30, and when I get in I review the list of |
| 19 |
updates. |
| 20 |
If every time I ran emerge -up security I saw this little small-app-0.0.1 that |
| 21 |
needed upgrading, it would just be irksome. |
| 22 |
Sure, yeah, I know, upgrade it, but lets say that it relies on |
| 23 |
lib-used-by-everyother-prog being a certain version. |
| 24 |
|
| 25 |
I really think that remote-root and local-root would provide more granularity, |
| 26 |
and allow people to decide. Who's to say what would go under the "security" |
| 27 |
banner? |
| 28 |
|
| 29 |
The more choice the better, IMHO. |
| 30 |
|
| 31 |
|
| 32 |
-- |
| 33 |
|
| 34 |
The early bird may get the worm, but the second mouse gets the cheese. |
| 35 |
|
| 36 |
jabber: jcalum@××××××××××××.uk |
| 37 |
pgp: http://gk.umtstrial.co.uk/~calum/keys.php |
| 38 |
|
| 39 |
|
| 40 |
-- |
| 41 |
gentoo-security@g.o mailing list |
Archives