Control: tags -1 + confirmed On 01-May-2025, Andres Salomon wrote:
> 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.
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:
> 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.
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.
--
\ “Often, the surest way to convey misinformation is to tell the |
`\ strict truth.” —Mark Twain, _Following the Equator_ |
_o__) |
Ben Finney <bign...@debian.org>
signature.asc
Description: PGP signature
