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