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) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AEF7C158020 for ; Thu, 10 Nov 2022 08:44:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5786DE0959; Thu, 10 Nov 2022 08:44:01 +0000 (UTC) Received: from bagheera.iewc.co.za (bagheera.iewc.co.za [IPv6:2c0f:f720:0:3::9a49:2249]) (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 DE868E08CD for ; Thu, 10 Nov 2022 08:44:00 +0000 (UTC) Received: from [2c0f:f720:fe0c:7900::1] (helo=tauri.local.uls.co.za) by bagheera.iewc.co.za with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ot3AC-0008BE-PP for gentoo-dev@lists.gentoo.org; Thu, 10 Nov 2022 10:43:56 +0200 Received: from [192.168.42.210] by tauri.local.uls.co.za with esmtp (Exim 4.94.2) (envelope-from ) id 1ot3AC-0001Rg-4L for gentoo-dev@lists.gentoo.org; Thu, 10 Nov 2022 10:43:56 +0200 Message-ID: <39df0838-8dc0-4775-3b66-b7e7d14150dd@uls.co.za> Date: Thu, 10 Nov 2022 10:43:55 +0200 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [gentoo-dev] [RFC] A new GLSA schema Content-Language: en-GB To: gentoo-dev@lists.gentoo.org References: From: Jaco Kroon Organization: Ultimate Linux Solutions (Pty) Ltd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-report: Relay access (bagheera.iewc.co.za). X-Archives-Salt: 13fd6c8d-cb1e-48e1-9333-8e1db4e6258f X-Archives-Hash: e8142139905f589dce5227aa3f2430ad Hi, On 2022/11/10 06:13, John Helmert III wrote: >>>  - Drop synopsis and description fields. These fields contain the same >>>    information and will be superceded by the existing impact field. >> 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... Actually yes!  Also a way to check whether my specific configuration is vulnerable for this specific CVE, something like "If you're setting foo=bar in /etc/pkg.conf your system is vulnerable, if you've got foo=phew you're most likely fine".  Obviously we could rely a bit more on package maintainers (myself included) to provide these. I don't think I've seen a single "workaround" and usually the text here just says "No known workaround", where the reality is that for something like asterisk just not using the affected module is good enough.  So workaround:  "Don't use chan_sip, use chan_pjsip instead" would be perfectly fine here. One could thus also link GLSA issues to specific USE flags, taking asterisk again, let's say the problem is with the http web server having a buffer overflow in the http basic authenticator, then if that embedded server isn't even compiled in, how can the package be vulnerable?  So here vulnerable would be something like > Multiple vulnerabilities have been discovered in $PACKAGE. Please > review the CVE identifiers referenced below for details. > > ... 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. Of course giving the full details in the GLSA is a pain in the backside, is there a way to retrieve this information automatically from the CVE database?  In other words, just get the blurp from there and include it here.  It won't give full details, but at least it will give some extra details not currently available.  Effectively we choose to ignore certain GLSAs if we consider their impact to be low. It would also help a great deal to automate that if the CVE scores and the "inputs" into that could be made available, eg, CVE score 7.0, remote=yes/no, .... (And I'm fairly certain importing this from the CVE database should be possible). Of course, someone has to do the work, and the current status quo doesn't irritate me enough to free up cycles to fix it, but if the above could be (partially) accommodated that would be really, really great, if not, no harm done. Much appreciate that there is work being done in this area. Kind Regards, Jaco