From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 3973F138247 for ; Thu, 9 Jan 2014 15:08:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1CE74E0AD2; Thu, 9 Jan 2014 15:08:28 +0000 (UTC) Received: from mail.a3li.li (sawfish.a3li.li [89.238.78.10]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 946AFE0A8F for ; Thu, 9 Jan 2014 15:08:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.a3li.li (Postfix) with ESMTP id CDF49227E52; Thu, 9 Jan 2014 16:08:24 +0100 (CET) X-Virus-Scanned: amavisd-new at a3li.li Received: from mail.a3li.li ([127.0.0.1]) by localhost (stingray.a3li.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOtI_83sH0gW; Thu, 9 Jan 2014 16:08:23 +0100 (CET) Received: from [IPv6:2001:6f8:12e4:0:6267:20ff:fe71:fb00] (unknown [IPv6:2001:6f8:12e4:0:6267:20ff:fe71:fb00]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.a3li.li (Postfix) with ESMTPSA id 9BD7D227E39; Thu, 9 Jan 2014 16:08:22 +0100 (CET) Message-ID: <52CEBB55.9030809@gentoo.org> Date: Thu, 09 Jan 2014 16:08:05 +0100 From: Alex Legler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 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 To: gentoo-security@lists.gentoo.org CC: phajdan.jr@gentoo.org Subject: Re: [gentoo-security] Soliciting feedback for the GLSA-2 format References: <52CCA65E.7040300@gentoo.org> In-Reply-To: <52CCA65E.7040300@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 8dfab788-ad2d-4d19-a4f0-4e2063db1a84 X-Archives-Hash: 9d1d8857f047338d090ee69dcbc00729 Forwarding from a private reply. >> Now that we've been growing a bit in numbers and have managed to get the >> GLSA circulation back on track, it is time to finally talk about the new >> GLSA format that has been planned for quite a while. > > Yay, very exciting! > >> - Packages section reworked: While adding Slot support we tried to get a >> new, simple, range-based scheme for marking vulnerable versions. The >> flexibility the range operators offered before was hardly ever used >> (mostly just to work around the lacking Slot support). We'd especially >> like feedback in this area, I fear we might be missing some >> functionality here. Quick explanation: >> >> >> >> >> >> >> >> >> >> >> Reads as follows: >> On hppa, there is no fixed version. >> On all other arches, python in slot 3.2 is fixed in >=3.2.9, affected >> for anything less, in the 3.3 slot, [3.3.0; 3.3.1[ and [3.3.3; 3.3.5[ >> are affected, for the 0 slot, anything <6.3 is affected. > > Some thoughts: > > 1. It'd be great to see some pseudo-code algorithm for processing this. > If anyone finds the time, I'd rather have a verbatim definition and a working reference implementation. > 2. I'd prefer to avoid embedding too much knowledge of how dependencies > work into GLSA (which is then subject to change as PMS changes). One > crazy example would be vulnerability existing only when a certain USE > flag is enabled, which currently cannot be expressed in GLSA and I don't > know if it'd be useful/desirable (certainly not if GLSA syntax would > need to change IMHO). There are no plans to add any more dependency features. > > 3. Please consider just using portage atoms syntax, e.g. > > > > > > > Then the set of vulnerable packages is a union of all matching atoms. > > Note that the above cannot encode that 3.3.1 is not vulnerable. I > consider that an OK compromise for more simplicity. 1. This combines multiple attributes (package, version, slot, comparator) into one field. That's something we've explicitly tried to avoid when putting together an XML format. 2. We need exclusion of previous versions. Example: Package has no slots, 1.x versions are unaffected, 2.x is affected and fixed in 2.1. The 1.x versions need to be declarable as not vulnerable. > >> - Human-readable texts reworked: Background + Description + Resolution >> instead of (Synopsis) + Background + Description + Impact + Resolution. >> >> - References reworked: Bugs moved into that tag, CVEs get their own tag >> without a link that could break, other references go as > > These are all awesome, glad to see that. > > Why not go further and even remove background? That can be taken from > package description. We thought about that. The problem is that ebuild descriptions are non-uniform. That looks bad. > > I'm also thinking about title. Since it's going to contain package > name(s) and "multiple vulnerabilities" most of the time, yet needs to be > manually edited by a developer, it allows for inconsistencies and just > makes editing/drafting harder (one needs to think what to put there). > Why not just drop it from the XML and use list of packages and date for > display or something similar? There are templates for the title in our drafting software. I feel like there's no gain in removing this. > >> - Metadata: Mostly leftovers from GLSAMaker v1 removed; We now list the >> author as well as people reviewing a draft and signing off on it with a >> proper name. Dates are in a standardized format. > > All sounds good. > > Paweł > >