El 15/02/25 a las 18:36, Chris Hofstaedtler escribió: > * Colin Watson <cjwat...@debian.org> [250214 18:13]: > > On Fri, Feb 14, 2025 at 03:28:35PM +0100, Marc Haber wrote: > > > Especially if the list just goes the (wrong) way of so many commercial > > > security tools and/or consultants who just compare version numbers and > > > flag our stable versions as vulnerable regardless whether we have > > > patched vulnerabilities or not. > > > > But it doesn't. Santiago's using the data from the security tracker to > > determine whether CVEs are open. > > I understood Santiago looked at all packages that ever had a > security issue reported. The two of my packages in the list would > support this interpretation. > > I don't see how this is a meaningful prioritization.
There are two numbers accompanying the source packages: the amount of currently open security issues in sid, and the number of security issues that have been present in Debian ever (as you mention). One of my main motivations for creating this list is the *hypothesis* that reducing the gap with upstream will make the work easier for the people backporting patches during the Debian release life cycle. Let's take paramiko as example (which was on the list of packages with no open issues, but with some cve history, and because the version in sid was 3.5.0 while upstream had released 3.5.1), and let's suppose that during the time trixie is supported, there is a new CVE about how paramiko handles private keys. Suppose that to fix that very hypothetical issue it would be needed to backport/cherry-pick the padding-related changes made in 3.5.1: https://github.com/paramiko/paramiko/commit/3acc7906d25189b11219a7472e1532fa3ad9a1d9 If 3.5.1 is shipped in trixie, the related code wouldn't have to be backported, so the patch would be smaller (and hopefully easier). And the code would be exposed more time via the unstable to testing migration than with a regular security update, which would reduce the probability of introducing regressions. Of course, I would expect that similar examples would make much more sense for packages with a more important gap between sid and unstable. If I have a limited amount of time to spend on Debian, I would like to prioritize (thanks Colin for communicating this better than me) the things to do where I could offer my help. I don't have any way to tell which packages will have new security issues during trixie, so I assume that packages with a history of security issues have more chances to need fixes. And so, I prioritize my Debian time looking at them. Cheers, -- Santiago
signature.asc
Description: PGP signature
