| 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----- |
Archives