Hi,
On Wed, 10 Apr 2024, Ola Lundqvist wrote:
> > Some package maintainers will typically decide to fix it via a point
> > release. But they rarely update the triaging to document "postponed" or
> > "ignored". So that's why it's up to the LTS team to make that call
> > when we are (alone) in charg
Hi Santiago
See below.
On Thu, 11 Apr 2024 at 02:34, Santiago Ruano Rincón
wrote:
>
> Hi Ola,
>
> El 10/04/24 a las 22:08, Ola Lundqvist escribió:
> > Hi all
> >
> > Sorry for late reply. It took me too long today to answer the CVE
> > triaging discussion. Now to this issue.
> >
> > Regarding th
Hi Ola,
El 10/04/24 a las 22:08, Ola Lundqvist escribió:
> Hi all
>
> Sorry for late reply. It took me too long today to answer the CVE
> triaging discussion. Now to this issue.
>
> Regarding the fedora patches. The patches seem to help for those
> specific issues they solve.
>
> My intention f
On Wed, Apr 10, 2024 at 10:08:51PM +0200, Ola Lundqvist wrote:
> Hi all
Hi Ola,
> Sorry for late reply. It took me too long today to answer the CVE
> triaging discussion. Now to this issue.
>
> Regarding the fedora patches. The patches seem to help for those
> specific issues they solve.
>
> My
Hi again
I have started with a document that clarify the severity levels. I
also introduced the level "critial" but I'm not sure it adds any
value.
https://inguza.com/document/debian-security-severity-levels
This is just a first draft. It is not final. But comments are welcome.
// Ola
On Wed,
Hi all
Sorry for late reply. It took me too long today to answer the CVE
triaging discussion. Now to this issue.
Regarding the fedora patches. The patches seem to help for those
specific issues they solve.
My intention for claiming the package was to go through the CVEs and
mark them with postpo
Hi Raphael
You can see corrected statistics in a separate email.
Now to comment a few things below.
On Wed, 10 Apr 2024 at 10:49, Raphael Hertzog wrote:
>
> Hello,
>
> On Tue, 09 Apr 2024, Ola Lundqvist wrote:
> > Let me use some data from CVEs for last year 2023.
> > I used the following metho
Hi Chris and Raphael
Raphael, I'll comment on your things in a separate email. This is to
corre/check the statistics.
It could very well be a counting error. That is why I wrote how I did it.
To check a little I checked out the list from 1 st of january 2023.
ola@tigereye:~/git/security-tracker/
On Wed, Apr 10, 2024 at 12:17:33PM -0400, Roberto C. Sánchez wrote:
> On Mon, Apr 08, 2024 at 07:56:40PM +0300, Adrian Bunk wrote:
> > On Mon, Apr 08, 2024 at 05:34:47PM +0200, Moritz Muehlenhoff wrote:
> > >
> > > So a useful next step would be to break those reports down into separate
> > > bug
On Wed, Apr 10, 2024 at 08:08:07PM +0300, Adrian Bunk wrote:
>
> My point was that an opposite approach of doing only
> "file upstream bugs and wait for upstream to fix the CVEs"
> is unlikely to have a positive outcome in this case.
>
> Forwarding fixes upstream is of course desirable,
> even wh
On Mon, Apr 08, 2024 at 07:56:40PM +0300, Adrian Bunk wrote:
> On Mon, Apr 08, 2024 at 05:34:47PM +0200, Moritz Muehlenhoff wrote:
> >
> > So a useful next step would be to break those reports down into separate
> > bug reports and file them there so that upstream actually learns about
> > them.
>
Raphael Hertzog wrote:
> Those numbers are quite surprising. I hope there's some error somewhere
> otherwise I wonder what has been done in the 2400+ hours paid each year to
> work on LTS... I'm pretty sure we have fixed more than 58 CVE. The average
> month has 20 to 30 updates (see
> https://lis
Hello,
On Tue, 09 Apr 2024, Ola Lundqvist wrote:
> Let me use some data from CVEs for last year 2023.
> I used the following method to extract the data
> grep -B 5 '\[buster\]' list | grep -A 5 "^CVE-2023-" | grep '\[buster\]'
> and then grepped for the end-of-life, not-affected (and so on to coun
13 matches
Mail list logo