-----BEGIN PGP SIGNED MESSAGE-----
I was not considering the entire process, just the part that really
impacts me: identifying vulnerable and patched packages. Full
advisories are nice, but really what I want to know is when I need to
update a particular package.
You are right that marking the packages that contain fixes doesn't
really scale because of increased baggage to carry forward.
The problem I have with GLSA's is that they don't come out until after
the problem has been fixed.
Perhaps it would be better to just have a system to label a particular
ebuild/version as vulnerable. Maybe something closer to package.mask,
but for security would be appropriate. With a package.security_mask,
you could have anyone on the security project update that file with
packages as soon as they know about it and while they are waiting on the
devs to fix it. References/links/impact could be noted in the comments
above, as package.mask does now.
As for interacting with 'emerge', I don't think we want the same
semantics as package.mask, since we don't want to force a downgrade (if
possible). It should probably just warn when you ask it to install a
vulnerable version. Upgrades to safe versions will be quiet that way.
The @security would contain packages with and without fixes so you get
warnings for things that remain vulnerable, and updates for things that
On Fri, Aug 26, 2011 at 08:40:29PM +0200, Alex Legler wrote:
> A complete change of the system is very unlikely.
> Nevertheless: What is the end-to-end process in your solution? (i.e.
> vulnerability report to 'advisory' release)
> A while ago a similar solution was proposed. Basically you want to shift our
> job back to the package maintainers. That might work, but rais a few new
> We'd automatically lose some consistency, because not everyone would follow
> the needed or wanted data scheme. Such a thing is much better to control in a
> smaller and better connected group of people.
> Also, cleanup and large amounts of issues in packages are issues. Browsers
> usually get hundreds of CVEs assigned in a year, that would be all in the
> Ebuild, and for how long?
> Personally, I'm not convinced this is a model that would be an improvement
> over the current situation.
> Alex Legler <firstname.lastname@example.org>
> Gentoo Security / Ruby
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
-----END PGP SIGNATURE-----