From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AC652158020 for ; Thu, 10 Nov 2022 04:13:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 87CE6E0948; Thu, 10 Nov 2022 04:13:24 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 51853E0922 for ; Thu, 10 Nov 2022 04:13:24 +0000 (UTC) Date: Wed, 9 Nov 2022 22:13:21 -0600 From: John Helmert III To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] A new GLSA schema Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q5D1JLlGQE+qYIgy" Content-Disposition: inline In-Reply-To: X-Archives-Salt: 9a51d7fa-495d-4479-a6b9-21d8181b0878 X-Archives-Hash: 2cb2638def00b1bc6e26aa56f6a3a852 --q5D1JLlGQE+qYIgy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 10, 2022 at 04:43:01AM +0100, Micha=C5=82 G=C3=B3rny wrote: > On Wed, 2022-11-09 at 20:27 -0600, John Helmert III wrote: > > The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of > > October 2003. It used roughly the same format of the GLSAs we release > > today, in 2022, making that format almost as old as me. > >=20 > > Somewhere along the way, it started to become necessary to target > > multiple version ranges within the same package. The GLSA format > > isn't capable of expressing this. Thus, I propose a new format (an > > example of which I've attached inline below), with the following > > changes from the old format: > >=20 > > =C2=A0- Rework affected to use XML-ified logical operators to specify t= he > > =C2=A0=C2=A0 affected versions, and *don't* use different fields to spe= cify > > =C2=A0=C2=A0 vulnerable and unaffected versions. Instead, only list vul= nerable > > =C2=A0=C2=A0 versions, unaffected versions are implicit. >=20 > Does that imply op=3D"" will now be limited to the standard ebuild > operators? Perhaps it'd be cleaner to take a step further and remove > the attribute in favor of going 100% ebuild syntax (yeah, escaping is > gonna suck there). The added complexity of escaping is exactly what I wanted to avoid! These are already enumerated in the old glsa.dtd [1] for usage in a similar way: >=20 > > =C2=A0- Drop synopsis and description fields. These fields contain the = same > > =C2=A0=C2=A0 information and will be superceded by the existing impact = field. >=20 > Well, I'm not saying "no" but it feels a bit weird reading a GLSA that > doesn't say a word what the problem is but specifies impact. You're right, but with 19 CVEs (for example), is anyone really interested in hearing about the problem that caused each of the 19 issues? In the current format we've resorted to writing descriptions like... Multiple vulnerabilities have been discovered in $PACKAGE. Please review the CVE identifiers referenced below for details. =2E.. simply because it's infeasible (and in my opinion, not really necessary) for us to enumerate the issues in this way. Also, I note that the section being called "impact" doesn't preclude us from incorporating text that we would currently put in the "description" or "synopsis" fields. > BTW have you considered switching to JSON or TOML? ;-) Definitely! But that adds significantly more complexity to implementing this, and given I'm likely to be the only one working on it, I decided against trying it. If I were inventing GLSAs for the first time I'd definitely avoid XML, of course. >=20 > --=20 > Best regards, > Micha=C5=82 G=C3=B3rny >=20 >=20 --q5D1JLlGQE+qYIgy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQyG9yfCrmO0LPSdG2gXq2+aa/JtQUCY2x6YAAKCRCgXq2+aa/J tbgQAP4/0BjfYlOBQxBOxd89JLAs3t0SpM5Gcl30PHI/WMZakAD/UxGpq2Zjt45C X4S1Hc9dsQDJ6lVZ95jZiJiCRoM2LA4= =NLb9 -----END PGP SIGNATURE----- --q5D1JLlGQE+qYIgy--