Here attached you can find a list of packages that have ever had a
security issue **and** whose packaged version is not "up to date",
according to the uscan results. It is sorted by the number of currently
open CVEs in sid (the first "column"), and by the number of security
issues ever (second "column").
So, this is a call for comments: is this kind of package list useful?
I'd say that the CVEs open in sid are not critical nor have a
high-severity, but it would be nice to have them fixed, as soon as
possible. If having this list available somewhere is a good idea, could
it be "integrated" into UDD somehow? As a cgi-bin that outputs a json
file?
This is also a call for action/help proposal*: I would like to invite
the related maintainers and teams to evaluate if it is worth it to
package the latest upstream version of the listed packages, and try to
make it for trixie. I know that the time is really short, and this kind
of call could be improved and made it earlier for the next releases.
So, this is a call for comments: is this kind of package list useful?[...]
Hi Santiago,
It would probably be helpful to also share the result of somehow running
the compiled list through dd-list, to raise attention for involved maintainers.
You might also want to somehow take activity on the package into
account.
Here attached you can find a list of packages that have ever had a
security issue **and** whose packaged version is not "up to date",
according to the uscan results. It is sorted by the number of currently
open CVEs in sid (the first "column"), and by the number of security
issues ever (second "column").
So, this is a call for comments: is this kind of package list useful?
* Santiago Ruano Rincón <santiagorr@riseup.net> [250213 20:21]:
Here attached you can find a list of packages that have ever had a
security issue **and** whose packaged version is not "up to date",
according to the uscan results. It is sorted by the number of currently
open CVEs in sid (the first "column"), and by the number of security
issues ever (second "column").
So, this is a call for comments: is this kind of package list useful?
Just having the list does not add anything new. All software can
have security bugs, so this list devolves to "packages that are not
uptodate wrt to upstream".
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.
Just having the list does not add anything new. All software can
have security bugs, so this list devolves to "packages that are not
uptodate wrt to upstream".
Any thoughts?
0, 1, openqa, (4.6.1732034221.ae34b08ff -> 4.6.1739296030.77d38ef),
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.
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.
But it doesn't. Santiago's using the data from the security tracker to determine whether CVEs are open.And in the case of one of my own packages these CVEs have not yet been
Hi,
On 13-02-2025 20:21, Santiago Ruano Rincn wrote:
Any thoughts?
You might also want to somehow take activity on the package into account. E.g. cacti (that I am nearly the only uploader for) has seen an update for CVE's only last week. I don't think I need (nor would I appreciate) more naging.
How do you envision *using* this list, except having this discussion and sharing a dd-list as suggested by Jonas? File wishlist bugs against the packages if they don't exist yet (taking the first paragraph into account too)?
On Feb 14, Colin Watson <cjwatson@debian.org> wrote:
But it doesn't. Santiago's using the data from the security tracker to determine whether CVEs are open.And in the case of one of my own packages these CVEs have not yet been
fixed upstream, not even in an unreleased branch.
CVEs are not perfect. CVE count is, charitably, a proxy for how much
security attention / research it gets (hopefully that is, in turn, a proxy
for how important a package is). Not so charitably, it's perhaps a proxy
for how many people who want to build a reputation as an expert have spent
time finding something that would pass minimalscrutinyas a security
issue.
There are plentyof security issues that are solved via normal bugfixesby
people who never realize the security implications of their bugfixes. In
important security sensitive places, too!
Updating to the latest upstreams is a good idea for lots of reasons, but I
don't totally understand the nexus to CVE here. Don't let me dissuade you
from doing good work here, but I reckon CVE counting is likely going to
lead to a lot of very weird non-security related biases which youmay or
may not actually want.
FWIW this will solve one real problem: Lots of companies complain
endlessly and mindlessly about CVEs based on package version(s) without
regards to the issue being exploitable or even reachable (or built into
the binary, in some cases!). Closing CVEs out will no doubt make them
complain less, which sounds nice.
In theory, any abnormal program behavior has the potential to carry a security implication. And in one project I have actually seen where[...]
there was a push to retroactively designate CVEs for past bug fixes that
it turned out had some kind of specific security vulnerability
associated with them. It was very bizarre, and I took it as a sign that
the "everything has to have a CVE and every CVE must be fixed" mentality
is infecting more and more parts of the software development world.
"Santiago" == Santiago Ruano Rincón <santiagorr@riseup.net> writes:
Other than to take into account recent activity, I think it is important
to look for possible reasons for not packaging the version reported by
uscan, before filing a bug report.
num of open CVEs in sid, num of historical CVE, source name
2, 21, wget, (1.24.5 -> 2-latest),
2, 19, fis-gtm, (7.1-005 -> 7.1-006),
0, 13, cimg, (3.5.0+dfsg -> 3.5.2),
So provided that we don't spam maintainers with "new upstream release"
bug reports hours after the upstream release, and that we don't open new
bug reports for as long as the former one has not been closed (but instead update the existing bug with the new information), then I would be
pretty much in favor of automating the creation of such bug reports.
So provided that we don't spam maintainers with "new upstream release"
bug reports hours after the upstream release, and that we don't open new bug reports for as long as the former one has not been closed (but instead update the existing bug with the new information), then I would be
pretty much in favor of automating the creation of such bug reports.
I don't think that would be very useful. Not for me at least.
There's my QA page https://qa.debian.org/developer.php?login=ltworf where all the packages with a newer version upstream have a red version in the "watch" column. So I know exactly which packages have new versions.
As to why I haven't done anything about it, depends on the specific package. Usually lack of time.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 147:56:03 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,737 |