Hi Roberto
> I tried re-reading your previous email several times and I am still not
> able to figure out what you are trying to demonstrate by your counting.
> If the conclusion is as you have it above, "We clearly do not fix all
> no-dsa in any case," then I agree.
Yes, that was what I wanted t
On Thu, Apr 11, 2024 at 10:01:49PM +0200, Ola Lundqvist wrote:
> Hi Roberto
>
> Maybe there is some counting mishap still. We may get double counting
> due to the -A and -B flags. But it should not matter so much because
> the double counting will then be both for corrected and others (at
> least
Hi Roberto
Maybe there is some counting mishap still. We may get double counting
due to the -A and -B flags. But it should not matter so much because
the double counting will then be both for corrected and others (at
least on average). When writing this I think I may get more
over-counting on the
Hi Ola,
On Wed, Apr 10, 2024 at 09:42:48PM +0200, Ola Lundqvist wrote:
>
> You can see that in 1 year and 3 months we have fixed
> 2023: 58
> 2022: 15
> 2021: 78
> 2020: 11
> 2019: 1
>
> Total (not counting CVEs for 2018 and earlier) 162.
>
> It is still a low number.
>
> And I think I found t
Hello Cyrille,
El 11/04/24 a las 09:15, Cyrille Bollu escribió:
> Why not using CVSS as a base calculation for assigning severity levels?
>
> IIRC, something like:
>
> CVSS>=8 => High
> 4<=CVSS<8 => Medium
> CVSS<4 => Low
...
Thanks for the comment!
I cannot talk for the security team, but I u
Hi Chris
On Thu, 11 Apr 2024 at 10:17, Chris Lamb wrote:
>
> Hey Ola,
>
> > And I think I found the counting mishap. :-)
> >
> > When a CVE is fixed, the buster tag is removed. :-D
>
> Ooh, yeah I suppose that might do it. :) Either way, congrats on
> spotting and correcting the issue…
Thank y
Hey Ola,
> And I think I found the counting mishap. :-)
>
> When a CVE is fixed, the buster tag is removed. :-D
Ooh, yeah I suppose that might do it. :) Either way, congrats on
spotting and correcting the issue… and I hope my slightly terse
mail didn't come across as negative.
Regards,
--
Hi Cyrille
Yes CVSS is a good starting point. A question there is how accurate
that score is, especially for CVEs on obscure packages.
I think it is valuable to have a guideline so we can evaluate if the
CVSS is reasonable.
It is sometimes a little dangerous to only focus on a number. :-)
But ye
Why not using CVSS as a base calculation for assigning severity levels?
IIRC, something like:
CVSS>=8 => High
4<=CVSS<8 => Medium
CVSS<4 => Low
was a good guidance in my previous job.
FYI, I've attached the table that drove us to these score.
Cyrille
Le mercredi 10 avril 2024 à 23:30 +0200, O
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 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 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/
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
res a comment. To tag a CVE as simply
> '' but not put a comment there is a syntax error. I can
> certainly imagine that many occurences of "Minor issue" are simply there
> to make the tracker happy and that all the relevant meaning is conveyed
> by ''. I.e.
d that all the relevant meaning is conveyed
by ''. I.e., this should get fixed at some point, but it is not
especially urgent and doesn't warrant a DSA all on its own.
So, breaking from that let me try to return for a moment to the origi
Hi Roberto
After first some thinking on what "constitutes a minor issue?" I did some
research and realized that there is in fact a good classification in the
Debian Security team list here:
https://security-team.debian.org/security_tracker.html#severity-levels
We have "unimportant", "low", "mediu
Hi Roberto
You ask me what constitutes a minor issue. My first thought was that I do
not really know. But after some thinking I know, it is just that I cannot
express it.
I'll think about it. I think we should have a guideline that we can review.
I'll make a proposal.
But it has to be done after
On Mon, Mar 18, 2024 at 09:40:45PM +0100, Moritz Muehlenhoff wrote:
> Emilio Pozuelo Monfort wrote:
> > Small nitpick: a CVE 'ignored' for (old)stable can still be fixed via point
> > release. The sec-team could be contacted to update that triaging, but that's
> > only ignored for (old)stable-secur
On Thu, Mar 14, 2024 at 11:39:41PM +0100, Ola Lundqvist wrote:
>
>I think we should clarify what we mean with "Minor issue". Is it what is
>typically written as "(Minor issue)" after "" statement or
>something else.
>I'm asking since it seems to be a common view that we should fix
Emilio Pozuelo Monfort wrote:
> Small nitpick: a CVE 'ignored' for (old)stable can still be fixed via point
> release. The sec-team could be contacted to update that triaging, but that's
> only ignored for (old)stable-security, not for (old)stable, where other
> criteria applies. The reason followi
On Mon, Mar 18, 2024 at 01:01:28PM +0100, Emilio Pozuelo Monfort wrote:
> On 14/03/2024 21:36, Roberto C. Sánchez wrote:
> > - if a CVE is 'fixed' in LTS but 'ignored' in (old)stable, then the
> >security team should be contacted to see if they would be willing to
> >change to 'no-dsa' so t
On 14/03/2024 21:36, Roberto C. Sánchez wrote:
- if a CVE is 'fixed' in LTS but 'ignored' in (old)stable, then the
security team should be contacted to see if they would be willing to
change to 'no-dsa' so that a point release fix can be made
Small nitpick: a CVE 'ignored' for (old)stable
Aha! Where can I find instructions on how that file is organized?
I have security-tracker directory
in /home/ola/freexian/services/deblts/lts/ but what should I have in this
git dir?
I guess debian-lts repo directory should be there so I moved it there and
it seems to work.
// Ola
On Sat, 16 Mar
Hi,
On 16/03/2024 21:53, Ola Lundqvist wrote:
Do we have a bug in the script?
ola@tigereye:~/git/debian-lts$ ./find-work | grep "^\*"
+ exec bin/package-operations --lts --find-work -f :online
Working directory of
g...@gitlab.com:freexian-lts/debian-lts.git
'/home/ola/freexian/service
Hi Sylvain
Is it really true that "find-work" order by priority. I know it did so in
the past but the output I get right now looks very much like alphabetical
order.
It could be a coincidence but I find it unlikely that the priority order
would result in alphabetical order.
Do we have a bug in th
Hi,
I add here a reminder to use './find-work' (as documented, including at
the top of dla-needed.txt) to look for work _sorted by priority_.
I triaged a few low, non-sponsored, harmonize-with-point-updates
packages this week, and I'm a bit surprised that some were claimed and
even uploaded
Hi again
One more thing. Should we have a statement about the fact that we do not
judge whether to ignore a package based on the number of users?
We only ignore in case it is not really feasible to backport without
breaking things.
Do we have any limit on how difficult it is allowed to be to back
Hi Roberto
Thank you for the clarifications. I think we should add some more.
See below.
On Thu, 14 Mar 2024 at 21:37, Roberto C. Sánchez wrote:
> Hello everyone,
>
> After the recent discussions regarding triage decisions and the criteria
> for keeping packages in dla-needed.txt, I wanted to
Hello everyone,
After the recent discussions regarding triage decisions and the criteria
for keeping packages in dla-needed.txt, I wanted to provide some
guidance to help make matters more clear.
First, as to the matter of triaging individual CVEs:
- we prefer to see all CVEs fixed, absent good
31 matches
Mail list logo
