Re: CVE-2020-8859 for elog, should we support it?

Hi Utkarsh On Wed, May 18, 2022 at 06:05:10AM +0530, Utkarsh Gupta wrote: > Hi Security team, > > On Wed, May 18, 2022 at 2:05 AM Ola Lundqvist wrote: > > If you think we should support the package I'll add it to > > dla-needed. From the description it looks like one can trigger > > a denial of

Accepted elog 3.1.2-1-1+deb9u1 (source) into oldoldstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 18 May 2022 05:57:05 +0530 Source: elog Architecture: source Version: 3.1.2-1-1+deb9u1 Distribution: stretch-security Urgency: high Maintainer: Roger Kalt Changed-By: Utkarsh Gupta Changes: elog (3.1.2-1-1+deb9u1)

[SECURITY] [DLA 3013-1] needrestart security update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - --- Debian LTS Advisory DLA-3013-1 debian-...@lists.debian.org https://www.debian.org/lts/security/ Utkarsh Gupta May 18, 2022

Accepted needrestart 2.11-3+deb9u2 (source) into oldoldstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 18 May 2022 05:38:30 +0530 Source: needrestart Architecture: source Version: 2.11-3+deb9u2 Distribution: stretch-security Urgency: high Maintainer: Patrick Matthäi Changed-By: Utkarsh Gupta Closes: 1011154 Changes:

Re: CVE-2020-8859 for elog, should we support it?

Hi Security team, On Wed, May 18, 2022 at 2:05 AM Ola Lundqvist wrote: > If you think we should support the package I'll add it to > dla-needed. From the description it looks like one can trigger > a denial of service without being authenticated. That sounds > pretty severe to me. I'll just go

Re: Question and proposed change for lts-cve-triage.py

Hi Anton That is a way to view it. Interesting point. Is this the common view? I'm asking since: - the list is long and it does not look like previous front desk did that. - I thought postponed meant that there is no need for a DLA, but we can fix that later on when such a need appears. I'm

Re: CVE-2020-8859 for elog, should we support it?

Hi Anton and Utkarsh If you think we should support the package I'll add it to dla-needed. From the description it looks like one can trigger a denial of service without being authenticated. That sounds pretty severe to me. But I'm definitely not an elog expert. I'll add a note that it should be

Re: Question and proposed change for lts-cve-triage.py

Hi, On 17/05/2022 15:37, Anton Gladky wrote: As far as I understand all of those packages can be added into the dla-needed without pre-review? Why not just put all of them together. Some can be added to dla-needed.txt, some need finer triage (e.g. no-dsa -> ignored); and some may be false

Re: CVE-2020-8859 for elog, should we support it?

I agree with Utkarsh, Even one CVE should be fixed if there are no objective reasons not to do it. Yes, if it is minor, it can be postponed, but not longer over a reasonable amount of time. Regards Anton Am Di., 17. Mai 2022 um 14:28 Uhr schrieb Utkarsh Gupta : > > Hi Ola, > > On Tue, May 17,

Re: Question and proposed change for lts-cve-triage.py

As far as I understand all of those packages can be added into the dla-needed without pre-review? Why not just put all of them together. OK, maybe with the short note "needs manual checking" or similar. Regards Anton Am Di., 17. Mai 2022 um 14:43 Uhr schrieb Sylvain Beucler : > > Hi, > > On

Re: Question and proposed change for lts-cve-triage.py

Hi, On 17/05/2022 08:44, Ola Lundqvist wrote: When doing triaging this week as part of the front desk assignment I realized that the lts-cve-triage.py script outputs the following section "Other issues to triage for stretch (not yet triaged for buster)" after "Issues postponed for stretch, but

Re: CVE-2020-8859 for elog, should we support it?

Hi Ola, On Tue, May 17, 2022 at 12:35 PM Ola Lundqvist wrote: > While triaging today I noticed this rather old CVE. The elog package > is clearly vulnerable (at least when looking through the source code). > However I noticed that elog is removed (exists in buster and bullseye > though) and it

Re: fis-gtm and support?

Hi Neil, all Thank you very much for this information. Just a small note. LTS differs from ELTS in that LTS aim to support all software in Debian, except the ones clearly documented as not supported. The packages-to-support is just an indication that these are the ones the sponsors wants us to

Re: [SECURITY] [DLA 3012-1] libxml2 security update

Hi Anton, Am Dienstag, dem 17.05.2022 um 06:35 +0200 schrieb Anton Gladky: > Hello Markus, > > thanks for the update! Could you please push your last change into the > git-repo [1] and tag an upload? Done. signature.asc Description: This is a digitally signed message part

Re: fis-gtm and support?

On Tue, 17 May 2022 09:25:36 +0200 Ola Lundqvist wrote: > Hi again team > > Sorry for sending a lot of emails today but I need guidance from you. > > I have triaged the fis-gtm package. It has a large set of > vulnerabilities that can be considered rather severe. At least at > first glance.

fis-gtm and support?

Hi again team Sorry for sending a lot of emails today but I need guidance from you. I have triaged the fis-gtm package. It has a large set of vulnerabilities that can be considered rather severe. At least at first glance. This votes for the package to be fixed. However the popcon score is very

CVE-2020-8859 for elog, should we support it?

Hi team While triaging today I noticed this rather old CVE. The elog package is clearly vulnerable (at least when looking through the source code). However I noticed that elog is removed (exists in buster and bullseye though) and it has a very low popcon score. Is it worth fixing? If not, we

Question and proposed change for lts-cve-triage.py

Hi all When doing triaging this week as part of the front desk assignment I realized that the lts-cve-triage.py script outputs the following section "Other issues to triage for stretch (not yet triaged for buster)" after "Issues postponed for stretch, but fixed in buster via DSA or point