From: Kevin Bryan <bryank@cs.uri.edu>
To: gentoo-security@lists.gentoo.org
Subject: Re: [gentoo-security] No GLSA since January?!?
Date: Fri, 26 Aug 2011 16:02:56 -0400 [thread overview]
Message-ID: <20110826200256.GA11330@zen.cs.uri.edu> (raw)
In-Reply-To: <1841190.qkTxzWzdzW@neon>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
are fixed.
Thoughts?
- --Kevin
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
> issues.
>
> 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
>
> --
> Alex Legler <a3li@gentoo.org>
> Gentoo Security / Ruby
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk5X+/AACgkQ6ENyPMTUmzrujACfUhO6S0CUQ6RaX+Q+IAZM69Wd
VakAnA4yzElckmCZaikTsPZdWZU5VazF
=MSwi
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2011-08-26 20:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-26 16:12 [gentoo-security] No GLSA since January?!? Christian Kauhaus
2011-08-26 16:43 ` Christoph Jasinski
2011-08-26 16:57 ` JD Horelick
2011-08-26 17:18 ` Daniel A. Avelino
2011-08-26 17:57 ` Alex Legler
2011-08-26 18:22 ` Daniel A. Avelino
2011-08-26 18:44 ` Alex Legler
2011-08-26 19:27 ` Daniel A. Avelino
2011-08-26 16:55 ` Alex Legler
2011-08-26 17:06 ` Christian Kauhaus
2011-08-26 18:00 ` Joost Roeleveld
2011-08-26 18:07 ` Alex Legler
2011-08-26 19:30 ` Joost Roeleveld
2011-08-26 18:08 ` Kevin Bryan
2011-08-26 18:40 ` Alex Legler
2011-08-26 20:02 ` Kevin Bryan [this message]
2011-08-26 20:40 ` Daniel A. Avelino
2011-08-26 22:27 ` Alex Legler
2011-08-26 23:38 ` Daniel A. Avelino
2011-08-26 18:41 ` Daniel A. Avelino
2011-08-27 8:49 ` Christian Kauhaus
2011-08-27 12:13 ` Rich Freeman
2011-08-27 12:34 ` Tobias Heinlein
2011-08-27 13:06 ` Rich Freeman
2011-08-27 13:34 ` Tobias Heinlein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110826200256.GA11330@zen.cs.uri.edu \
--to=bryank@cs.uri.edu \
--cc=gentoo-security@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox