On 5/1/25 16:13, Salvatore Bonaccorso wrote:
Hi Andres,[very personal opinion]
Thanks for chiming in!
On Thu, May 01, 2025 at 01:22:00PM -0400, Andres Salomon wrote:Package: dput Version: 1.1.3 X-Debbugs-Cc: Debian Security Team <t...@security.debian.org> In chromium, I have the following code snippet to verify that when someone is doing an upload to stable-security, the changelog entry actually includes CVEs: https://salsa.debian.org/chromium-team/chromium/-/commit/e518b008008fd7d6a42319aed718bdb595ff5092 Unfortunately, this is the wrong place to be doing the check, as there are times when an upload is messed up and I need to release a second version that lacks CVEs. Ultimately, my opinion is that this kind of thing should be in dput - automated checks should be looking not just at the latest changelog entry, but at all the included changelog entries to the .changes file (as generated when using the -v<version> argument). This also seems like the kind of thing that would be a helpful reminder for other security uploads as well*. This would be for security-master uploads only, rather than anything going into a stable point releases. Dput already has /usr/share/dput/helper/security-warning to verify that the uploader really does want to upload to security-master. I'm happy to provide a patch/MR to add an additional check for CVEs listed in the .changes file, and prompt the user ("No CVEs listed in the changelog despite this being a security upload; they should really be there. Do you want to continue despite lack of CVEs? [y/N]") if there are no CVEs. It would require modifying dput's execute_command() to pass additional arguments to helper scripts. Please let me know if you're amenable to this, and I'll prepare it. * security-team, please tell me if I'm wrong and it would be overly annoying.With above disclaimer/note: I would rather prefer to not have to ack another warning for a security-master upload. I think we have to work diligent enough already in particular for instance when handling embargoed uploads. You are defintively right that the "normal case" will include CVE id references, but not necessarily.
I agree that the prompt should hopefully not show up in the vast majority of cases. Out of curiosity, I looked at the past month worth of DSAs.
Uploads w/ changelog entries containing CVEs: (2x) firefox request-tracker4 libreoffice request-tracker5 (2x) linux erlang graphicsmagick libapache2-mod-auth-openidc (3x) chromium perl mediawiki lemonldap-ng xz-utils jetty9 tomcat10 atop So that's 20 security uploads where the extra prompt wouldn't show up. Uploads without CVEs in changelog but listed in the DSA: webkit2gtk trafficserver (complicated by older sid version)Uploads without CVEs in current changelog but in prior changelog (eg, building with -v1:128.8.0esr-1~deb12u1 for the 1:128.9.0esr-1~deb12u1 build would have included CVEs):
(2x) thunderbirdSo basically the prompt would only show up in 4 of those 24 uploads, and would ideally create benefit by reminding the uploaders to include the sid changelog entry in the bookworm-security changes file if that's the one with CVE entries. I'm envisioning this not as some kind of hard rule, but simply as a reminder ("[...] If you want to go back and add CVEs or rebuild your .changes file with -v<version>, hit 'N' and rebuild. Do you want to continue with the upload? [yN]")
In the end if the majority will though like to have such a warning, then so be it. The target distributions needs to match as well anyway for having it accepted into the queues for security-master (and there is already a check beforehand).
I hadn't discussed this with anyone else, I'm just throwing the idea out there to see what others think. Having the rule in d/rules has been helpful for me as a reminder to add CVEs to the chromium changelog, but it's also a hassle having it there causing the occasional FTBFS.
Again, just my personal opinion.
Thanks again!
Regards, Salvatore
OpenPGP_signature.asc
Description: OpenPGP digital signature
