1 |
I like this approach but I have no idea about how this could be performed. |
2 |
|
3 |
ACCEPT_RISKS="remote dos" emerge ... |
4 |
|
5 |
Sounds very cool to me. |
6 |
|
7 |
Daniel |
8 |
|
9 |
On 8/26/11, Kevin Bryan <bryank@××××××.edu> wrote: |
10 |
> -----BEGIN PGP SIGNED MESSAGE----- |
11 |
> Hash: SHA1 |
12 |
> |
13 |
> I was not considering the entire process, just the part that really |
14 |
> impacts me: identifying vulnerable and patched packages. Full |
15 |
> advisories are nice, but really what I want to know is when I need to |
16 |
> update a particular package. |
17 |
> |
18 |
> You are right that marking the packages that contain fixes doesn't |
19 |
> really scale because of increased baggage to carry forward. |
20 |
> |
21 |
> The problem I have with GLSA's is that they don't come out until after |
22 |
> the problem has been fixed. |
23 |
> |
24 |
> Perhaps it would be better to just have a system to label a particular |
25 |
> ebuild/version as vulnerable. Maybe something closer to package.mask, |
26 |
> but for security would be appropriate. With a package.security_mask, |
27 |
> you could have anyone on the security project update that file with |
28 |
> packages as soon as they know about it and while they are waiting on the |
29 |
> devs to fix it. References/links/impact could be noted in the comments |
30 |
> above, as package.mask does now. |
31 |
> |
32 |
> As for interacting with 'emerge', I don't think we want the same |
33 |
> semantics as package.mask, since we don't want to force a downgrade (if |
34 |
> possible). It should probably just warn when you ask it to install a |
35 |
> vulnerable version. Upgrades to safe versions will be quiet that way. |
36 |
> The @security would contain packages with and without fixes so you get |
37 |
> warnings for things that remain vulnerable, and updates for things that |
38 |
> are fixed. |
39 |
> |
40 |
> Thoughts? |
41 |
> |
42 |
> - --Kevin |
43 |
> |
44 |
> On Fri, Aug 26, 2011 at 08:40:29PM +0200, Alex Legler wrote: |
45 |
>> |
46 |
>> A complete change of the system is very unlikely. |
47 |
>> Nevertheless: What is the end-to-end process in your solution? (i.e. |
48 |
>> vulnerability report to 'advisory' release) |
49 |
>> |
50 |
>> A while ago a similar solution was proposed. Basically you want to shift |
51 |
>> our |
52 |
>> job back to the package maintainers. That might work, but rais a few new |
53 |
>> issues. |
54 |
>> |
55 |
>> We'd automatically lose some consistency, because not everyone would |
56 |
>> follow |
57 |
>> the needed or wanted data scheme. Such a thing is much better to control |
58 |
>> in a |
59 |
>> smaller and better connected group of people. |
60 |
>> |
61 |
>> Also, cleanup and large amounts of issues in packages are issues. Browsers |
62 |
>> |
63 |
>> usually get hundreds of CVEs assigned in a year, that would be all in the |
64 |
>> Ebuild, and for how long? |
65 |
>> |
66 |
>> Personally, I'm not convinced this is a model that would be an improvement |
67 |
>> |
68 |
>> over the current situation. |
69 |
>> |
70 |
>> Alex |
71 |
>> |
72 |
>> -- |
73 |
>> Alex Legler <a3li@g.o> |
74 |
>> Gentoo Security / Ruby |
75 |
> |
76 |
> |
77 |
> -----BEGIN PGP SIGNATURE----- |
78 |
> Version: GnuPG v2.0.18 (GNU/Linux) |
79 |
> |
80 |
> iEYEARECAAYFAk5X+/AACgkQ6ENyPMTUmzrujACfUhO6S0CUQ6RaX+Q+IAZM69Wd |
81 |
> VakAnA4yzElckmCZaikTsPZdWZU5VazF |
82 |
> =MSwi |
83 |
> -----END PGP SIGNATURE----- |
84 |
> |
85 |
> |