1 |
On Friday 26 August 2011 16:02:56 Kevin Bryan wrote: |
2 |
> I was not considering the entire process, just the part that really |
3 |
> impacts me: identifying vulnerable and patched packages. Full |
4 |
> advisories are nice, but really what I want to know is when I need to |
5 |
> update a particular package. |
6 |
> |
7 |
> You are right that marking the packages that contain fixes doesn't |
8 |
> really scale because of increased baggage to carry forward. |
9 |
> |
10 |
> The problem I have with GLSA's is that they don't come out until after |
11 |
> the problem has been fixed. |
12 |
> |
13 |
> Perhaps it would be better to just have a system to label a particular |
14 |
> ebuild/version as vulnerable. Maybe something closer to package.mask, |
15 |
> but for security would be appropriate. With a package.security_mask, |
16 |
> you could have anyone on the security project update that file with |
17 |
> packages as soon as they know about it and while they are waiting on the |
18 |
> devs to fix it. References/links/impact could be noted in the comments |
19 |
> above, as package.mask does now. |
20 |
> |
21 |
> As for interacting with 'emerge', I don't think we want the same |
22 |
> semantics as package.mask, since we don't want to force a downgrade (if |
23 |
> possible). It should probably just warn when you ask it to install a |
24 |
> vulnerable version. Upgrades to safe versions will be quiet that way. |
25 |
> The @security would contain packages with and without fixes so you get |
26 |
> warnings for things that remain vulnerable, and updates for things that |
27 |
> are fixed. |
28 |
> |
29 |
> Thoughts? |
30 |
|
31 |
I see this as an addition to sending advisories after fixing an issue, not as |
32 |
a solution to the issue at hand. |
33 |
|
34 |
-- |
35 |
Alex Legler <a3li@g.o> |
36 |
Gentoo Security / Ruby |