On Sat, Feb 22, 2025 at 09:41:54AM +0100, Salvo Tomaselli wrote:
> > 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
> >
> 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
> pre
Hi Santiago,
thanks a lot for this list. As others mentioned it would be helpful to
add the maintainers to the list and I agree. ;-)
I spotted some specific packages I like to comment on (but I might
have missed others I should comment on)
Am Thu, Feb 13, 2025 at 04:21:10PM -0300 schrieb Santia
On 2025-02-20 15:37, Raphael Hertzog wrote:
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 n
Hi,
On Mon, 17 Feb 2025, Santiago Ruano Rincón wrote:
> 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.
I actually see it the other way. When a new upstream relea
> "Santiago" == Santiago Ruano Rincón writes:
Santiago> Dear Debian fellows, I am writing this email under the
Santiago> hypothesis that having the latest (or longest supported)
Santiago> upstream version in the next release will: 1. make it
Santiago> easier to provide securit
On Tue, Feb 18, 2025, 8:56 AM Roberto C. Sánchez wrote:
> I agree that something like this effort is likely to reduce the
> occurence of that sort of thing. And, yes, CVE is probably not a great
> proxy. But Santiago has discussed this with quite a few of us on the LTS
> team at various points al
On 2025-02-18 08:55:55 -0500 (-0500), Roberto C. Sánchez wrote:
[...]
> 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
On Mon, Feb 17, 2025 at 09:42:21PM -0500, Paul R. Tagliamonte wrote:
>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 prox
On Mon, Feb 17, 2025 at 9:14 PM Santiago Ruano Rincón
wrote:
> 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).
>
I've been biting my tongue a
El 16/02/25 a las 21:15, Marco d'Itri escribió:
> On Feb 14, Colin Watson 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
El 15/02/25 a las 18:36, Chris Hofstaedtler escribió:
> * Colin Watson [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 numbe
El 13/02/25 a las 21:57, Paul Gevers escribió:
> Hi,
>
> On 13-02-2025 20:21, Santiago Ruano Rincón 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 l
On Feb 14, Colin Watson 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.
--
ciao,
Marco
signature.asc
De
* Colin Watson [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 w
On Fri, 14 Feb 2025 17:12:48 +, Colin Watson
wrote:
>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 vu
Santiago Ruano Rincón writes:
> Any thoughts?
I'm sure there are things up near the top of the list that do need a
closer look, but picking a package that I'm responsible for:
> 0, 1, openqa, (4.6.1732034221.ae34b08ff -> 4.6.1739296030.77d38ef),
by the time you get down that far, it's probably
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
On Fri, Feb 14, 2025 at 02:44:47PM +0100, Chris Hofstaedtler wrote:
> 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".
I'm not sure that's quite right. It's a _prioritized_ list of
On Fri, 14 Feb 2025 14:44:47 +0100, Chris Hofstaedtler
wrote:
>* Santiago Ruano Rincón [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
* Santiago Ruano Rincón [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 b
On Thu Feb 13, 2025 at 8:57 PM GMT, Paul Gevers wrote:
You might also want to somehow take activity on the package into
account.
Absolutely. E.g. the new OpenJDK 11 package came out a week ago. It
would be interesting to see which packages in the list have a much
larger gap, such as years.
On Thu, Feb 13, 2025 at 08:34:07PM +0100, Jonas Smedegaard wrote:
> 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.
I want to say: yes. :) please do.
--
cheers,
Ho
Hi,
On 13-02-2025 20:21, Santiago Ruano Rincón 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
On 2025-02-13 16:21:10 -0300 (-0300), Santiago Ruano Rincón wrote:
[...]
> So, this is a call for comments: is this kind of package list useful?
[...]
The main problem I see is that the list includes projects who
backport security fixes to stable branches, so for example
python-keystonemiddleware
Hi Santiago,
Quoting Santiago Ruano Rincón (2025-02-13 20:21:10)
> 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 (t
Dear Debian fellows,
I am writing this email under the hypothesis that having the latest (or
longest supported) upstream version in the next release will: 1. make it
easier to provide security support during the whole release lifecycle,
and 2. it will be useful for users, as they could have the la
27 matches
Mail list logo
