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