From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Qx2dZ-00028d-KO for garchives@archives.gentoo.org; Fri, 26 Aug 2011 20:04:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DC71921C21D; Fri, 26 Aug 2011 20:04:10 +0000 (UTC) Received: from tokyo.cs.uri.edu (tokyo.cs.uri.edu [131.128.81.252]) by pigeon.gentoo.org (Postfix) with ESMTP id D7A9E21C13F for ; Fri, 26 Aug 2011 20:02:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by tokyo.cs.uri.edu (Postfix) with ESMTP id 77B1CDAD35 for ; Fri, 26 Aug 2011 16:02:58 -0400 (EDT) X-Virus-Scanned: by amavisd-new at cs.uri.edu Received: from tokyo.cs.uri.edu ([127.0.0.1]) by localhost (mail.cs.uri.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5ni6sFgWPWiC for ; Fri, 26 Aug 2011 16:02:58 -0400 (EDT) Received: from zen.cs.uri.edu (zen.cs.uri.edu [131.128.81.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tokyo.cs.uri.edu (Postfix) with ESMTPSA id 44FA7DACF4 for ; Fri, 26 Aug 2011 16:02:58 -0400 (EDT) Date: Fri, 26 Aug 2011 16:02:56 -0400 From: Kevin Bryan To: gentoo-security@lists.gentoo.org Subject: Re: [gentoo-security] No GLSA since January?!? Message-ID: <20110826200256.GA11330@zen.cs.uri.edu> Mail-Followup-To: gentoo-security@lists.gentoo.org References: <4E57C5D0.8090004@gocept.com> <4E57D29B.5070603@gocept.com> <20110826180838.GA21426@zen.cs.uri.edu> <1841190.qkTxzWzdzW@neon> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-security@lists.gentoo.org Reply-to: gentoo-security@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed In-Reply-To: <1841190.qkTxzWzdzW@neon> X-Archives-Salt: X-Archives-Hash: cf0dee542a2421926bc8d1816e9972c7 -----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 > Gentoo Security / Ruby -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk5X+/AACgkQ6ENyPMTUmzrujACfUhO6S0CUQ6RaX+Q+IAZM69Wd VakAnA4yzElckmCZaikTsPZdWZU5VazF =MSwi -----END PGP SIGNATURE-----