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.

Hi Andres,

[very personal opinion]
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.

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).

Again, just my personal opinion.

Regards,
Salvatore

Thanks for chiming in!

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) thunderbird


So 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]")

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.

Thanks again!

Am Thu, May 01, 2025 at 10:13:24PM +0200 schrieb Salvatore Bonaccorso:
will have a CVE already known and already includes one and for the handful
of cornercases where it's not the case it's just a matter of confirmation
with 'y'. I think this would be useful particularly for the uploads
prepared by maintainers (since they do uploads less often than security
team members)

Cheers,
        Moritz

Control: tags -1 + confirmed

I'm interested in such a feature. But given the (IMO reasonable)
differences of opinion, and given the sensitivity of making changes to DPut
behaviour, I would propose a modified requirement:

I'd express the requirements for a patch as:

* For now, no user prompt at all, just report the information DPut has
  detected about CVEs.

  This will be a conservative step forward: more useful than no
  information, and will not require any change in user behaviour. When we
  get some feedback on how people like this, we can reconsider adding a
  user prompt.

* Be very tight (narrowly defined) in how the information is found. If
  there is a standard way to present CVE information (maybe a
  pseudo-field?) that is preferable to just detecting a broad pattern
  anywhere in the text. Otherwise, try hard to match *only* the pattern we
  expect and not unexpected occurrences in arbitrary garbage text.

* Ensure a good set of test cases in the unit test suite. These should test
  not only the positive cases (CVE information where expected) but also
  should behave correctly when near-misses happen (try hard to think of
  messages that *might* trip a naive parser, and test that we correctly
  report a negative in those cases).

Thanks for raising this issue, I look forward to see how you go.