1 |
I second that! I've been doing 'emerge -u world's on my web server at home |
2 |
and the fileservers here at work, and like Mark, do not feel comfortable |
3 |
with this. I also don't have a lot of time to dig around and find out why |
4 |
there was an update (unless there's an easy way to do this??). |
5 |
|
6 |
I think 'emerge -u -L1 world' is an awesome idea! :) |
7 |
|
8 |
> On 9-Feb-04, at 7:11 AM, Calum wrote: |
9 |
> |
10 |
>> What I think would be a good idea is the creation and maintenance of |
11 |
>> say 4 new |
12 |
>> virtual packages: |
13 |
>> remote-root |
14 |
>> remote-shell |
15 |
>> local-root |
16 |
>> remote-dos |
17 |
>> (Maybe there could be more, but these are the ones that I can think |
18 |
>> of). |
19 |
> |
20 |
> Couple of comments. |
21 |
> |
22 |
> This doesn't make sense to me personally, emerge remote-root sounds |
23 |
> more like something you would do to obtain remote root of a machine |
24 |
> than to repair a potential one (just terminology stuff there is my |
25 |
> complaint). In theory the idea seems valid, in practice I'm not sure |
26 |
> this would be the best approach. |
27 |
> |
28 |
> What I would rather see in portage is a way to rank updates (10 for |
29 |
> trivial, 5 for major version upgrades with more features, etc, and 1 |
30 |
> for security needs). Then something like emerge -up -L1 world might |
31 |
> only show any major security updates you need to do along with the |
32 |
> required deps (but hopefully not optional ones). This should be fairly |
33 |
> achievable with minor changes to the low levels (to add metadata for |
34 |
> the update's urgency), and maybe 10-15 lines in the portage code base. |
35 |
> |
36 |
> Second comment.. the 'virtuals' you compare the 'remote-root' pkg vs. |
37 |
> system pkg with work radically differently than what might be the |
38 |
> initial assumption. In fact world and system are both very different |
39 |
> than the typical metapkgs (like kde, gnome, etc). They are both hard |
40 |
> coded into the setup so to speak. System being defined in the profile |
41 |
> (pkgs marked with * in packages file are system files), and world is |
42 |
> maintained similarly (yet differently) in your portage db directory in |
43 |
> a flat file (it keeps running tabs on what's installed, etc). |
44 |
> |
45 |
> I for one would much rather see a severity level of some sort happen in |
46 |
> portage, for those of us that are afraid to emerge -u world to fix |
47 |
> these sorts of vulnerabilities (as you never know what you are getting |
48 |
> into with that if you run a very locked down server), which would also |
49 |
> give us a very quick way of assessing what if any updates are needed |
50 |
> for security reasons without having to do a lot of digging my hand or |
51 |
> comparing versions vs. all kinds of GLSA announcements, etc. |
52 |
> |
53 |
> On that note it would be even better if at the end of emerge sync it |
54 |
> could give you a message telling you that there are some level 1 |
55 |
> security updates available and how to view the list of them, similarly |
56 |
> to how it tells you that there are portage updates available. |
57 |
> |
58 |
> Mark |
59 |
> |
60 |
> |
61 |
> -- |
62 |
> gentoo-security@g.o mailing list |
63 |
> |
64 |
> |
65 |
|
66 |
|
67 |
-- |
68 |
gentoo-security@g.o mailing list |