Re: Looking for collaborator for MariaDB 10.5 and Galera 4

[Sylvain Beucler]

Hi,

On 17/09/2024 01:50, Otto Kekäläinen wrote:

In any case our workflow is to start registering the DLAs once the
package is built and installed on all archs, so if you decide to dput
you could do that now.
Do you plan to announce the DLA or do you want me to?


I will do my own final checks, and upload now, and follow up that
everything builds.

If you could do the DSA/DLA part, it would be great.

Thanks for reviewing and helping Debian users get high quality updates!


DLA-3890-1 sent for galera-4 :)

mariadb fails to build on armhf :/
If you can fix this quickly, I can delay the DLA for mariadb.
Otherwise I can issue a DLA and we'll issue a new DLA / regression 
update when armhf builds.


Cheers!
Sylvain

Re: Looking for collaborator for MariaDB 10.5 and Galera 4

[Sylvain Beucler]

Hi Otto,

On 10/09/2024 16:36, Otto Kekäläinen wrote:

Thanks for your review on these yesterday! I have updated both to
address your feedback:

https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/27
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/18

Can you add the entries in
https://salsa.debian.org/security-tracker-team/security-tracker and
give your final approval on the MRs? I can then proceed to `dput
security-master` these.


Actually I was on my way to test galera-4 and cloning a few VMs, when my 
main hard disk started to behave and the system crashed a few times. I'm 
not exactly sure where the problem lies yet and I may have to reinstall 
my main computer :/, so if you want to proceed without my test we can do 
that.


I wasn't sure mariadb was ready since the MR is still marked as Draft, 
and there was a note about the CI not working (I now see it's the uscan 
test that blocks everything), so I didn't check as extensively, but 
again if you feel confident you can upload as well.
(Maybe we want to switch the CI to e.g. pristine-tar and actually run 
the tests first though.)


In any case our workflow is to start registering the DLAs once the 
package is built and installed on all archs, so if you decide to dput 
you could do that now.

Do you plan to announce the DLA or do you want me to?

Cheers!
Sylvain

Re: Looking for collaborator for MariaDB 10.5 and Galera 4

[Sylvain Beucler]

Hello Otto,

On 07/09/2024 05:43, Otto Kekäläinen wrote:

I am willing to do the minor version security/bugfix imports for
MariaDB 10.5.x and Galera 4.x to Bullseye, but to ensure highest
quality and good process, I am seeking somebody who could collaborate
on it.

I expect a collaborator to
1. Review the MR of the import and point out if they see any obvious
mistakes/flaws.
2. Help post the correct emails and announcements.

I am aware of https://lts-team.pages.debian.net/wiki/Development.html
and I have done DSAs myself for Buster before. I am not asking for
help/advice, but a collaborator/reviewer, as doing this alone is
boring. Also, as the goal for LTS is absolute stability, I don't want
to proceed if there isn't a collaborator around to do reviews to help
maximize that updates are regression-free.

If somebody shouts _yes_, I will post new versions for review at
* https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests
* https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests


YES :)

Let me know when the new versions are available for review.

Cheers!
Sylvain Beucler
Debian LTS Team

Debian LTS and ELTS - August 2024

[Sylvain Beucler]

  - Detail expected behavior and caveats
- Document usage of autodep8 triggering unexpected tests
  https://manpages.debian.org/unstable/autodep8/autodep8.1.en.html
  - How to create an arm* VM from an AMD64 host, for testing purposes,
using debvm-create

- Monthly team meeting (through Jitsi)
  Acted as secretary
  https://lists.debian.org/debian-lts/2024/08/msg00041.html


-- 
Sylvain Beucler
Debian LTS Team

Re: Make stable-security build logs public after embargo

[Sylvain Beucler]

Hi Wanna-Build Team,

On 19/08/2024 18:57, Aurelien Jarno wrote:

On 2024-08-14 12:59, Santiago Ruano Rincón wrote:

El 13/12/23 a las 11:56, Salvatore Bonaccorso escribió:

On Wed, Dec 13, 2023 at 07:50:38AM +0100, Sylvain Beucler wrote:

Actually we have a summary of the situation here:
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51

We have mostly 2 options:

1/ General fix, involving a dak hook and some corner cases, and more
importantly having access to the infrastructure,

2/ One-off mass injection of [oldstable]-security build logs when starting a
new LTS dist.


Given that 1/ was attempted a couple times in the past and never reached
completion, and given that we might solve this if the debusine [1] project
is adopted, I think we can drop it for now.

Doing 2/ next August for bullseye sounds doable, solves the most immediate
use case (i.e. LTS devs comparing previous logs on new FTBFS), so I think we
can privilege this option.

What do you think?


Agreed, I think doing 2/ is more sensible at this point to cover the
need of LTS devs needing to compare previous logs.

In the middle or long(er) run having logs available in public after
they do not need anymore to be restricted is surely welcome, but as
outlined this won't be in near future be possible with the current
setup and more work involved.


As suggested last December, could you please make the bullseye-security
build logs publicly available?


I have updated the configuration so that NEW bullseye-security logs are
published and publicly available.


Thanks for making new logs public Aurélien. Though this thread is about 
a different issue:


We'd like to make old bullseye logs publicly available, e.g. 
https://buildd.debian.org/status/package.php?p=wpa&suite=bullseye-security
so the LTS Team can use them as reference when analyzing future FTBFS, 
as discussed in point 2 above at the end of last year.


On #debian-lts jmm and carnil recently recap'd that the old logs are 
stored on master.debian.org in 
/home/debian/archive/debian-security-logs, in xz-compressed mboxes (one 
per month).


We'd need the Wanna-Build Team to filter out only those for bullseye (or 
if that's simpler, all dists up to July since all embargoed builds were 
published since), and then injects them to buildd.debian.org.


Would that be possible? :)

Cheers!
Sylvain Beucler
Debian LTS Team

Re: make-scratch-ntfs script

[Sylvain Beucler]

Hi,

On 14/08/2024 11:40, Sean Whitton wrote:

For testing the git updates I've been working on, I needed a
case-insensitive scratch filesystem.  The usual thing would be to make a
FAT32 loop mount, but I also needed 'ln -s' to work.  I ended up with a
script to set up this an NTFS mount.[1]

This isn't really git-specific.  I was thinking I could add a "tools"
subheading on [2].  Are others okay with me putting it there?

[1]  https://git.spwhitton.name/dotfiles/tree/scripts/media/make-scratch-ntfs
[2]  https://lts-team.pages.debian.net/wiki/TestSuites.html


Fine by me. The "autopkgtest" entry could be moved under "tools" as well :)

As for the script, I believe you can do without the partition table + 
losetup, and work directly on the image:

  fallocate -l 1G test.ntfs
  /usr/sbin/mkfs.ntfs -F ... test.ntfs
  sudo mount -o loop ... test.ntfs /mnt/t/

also 'umount -l' sounds like troubles :)

Cheers!
Sylvain Beucler
Debian LTS Team

Re: Security support for pypy and jython

[Sylvain Beucler]

Hi,

On 13/08/2024 11:54, Moritz Mühlenhoff wrote:

Am Mon, Aug 12, 2024 at 03:10:06PM -0300 schrieb Santiago Ruano Rincón:

El 08/08/24 a las 12:10, Sylvain Beucler escribió:

python2.7 was marked unsupported in bullseye.

We recently noted that pypy[v2] (included up to bullseye) and jython (all
dists) include the python2 stdlib.  Unlike pypy3, neither package currently
track the associated CVEs.


Do we want to mark pypy and jython as EOL, or limited-support, in
debian-security-support?


For pypy and jython/bullseye, I would included them in
security-support-limited.deb11, with the same rationale than for
python2.7. Any objection?

Security team, may we have your thoughts, especially about jython (since
it is included also in bookworm and trixie)?


Let's add it to security-support-limited for all suites (until
at some point it gets ported to Py3)


Thanks, MR submitted :)

https://salsa.debian.org/debian/debian-security-support/-/merge_requests/28

Cheers!
Sylvain Beucler
Debian LTS Team

Re: gpac end-of-life in stretch (and recommendation for buster/bullseye)

[Sylvain Beucler]

Hi,

On 08/08/2024 15:20, Santiago Ruano Rincón wrote:

El 08/08/24 a las 11:56, Sylvain Beucler escribió:

Since then:
- gpac was EOLd in buster
https://salsa.debian.org/debian/debian-security-support/-/commit/a0bfdf01d404aba46893d2971d776f8f7fb5337e
- gpac was removed from bookworm
https://tracker.debian.org/news/1430135/gpac-removed-from-testing/
- gpac was removed from sid
https://tracker.debian.org/news/1548977/removed-221dfsg1-31-from-unstable/

gpac in bullseye still has >100 open CVEs and I don't believe the situation
described by Roberto improved.

Do we want to mark gpac EOL for bullseye as well?


I think it makes sense, yes. Would you like to proceed and document
this in d-d-s?


Here is the MR :)
https://salsa.debian.org/debian/debian-security-support/-/merge_requests/27

For reference, a few more details about the gpac package:

- bookworm removal BTS with rationale:
  RM: gpac/2.0.0+dfsg1-4
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034798

- bullseye rdeps:
  x264 (high popcon)
  ogmrip (not in bookworm and trixie)

- x264 impact: output to .mp4 in 'x264' cli utility (not 'libx264')
  recompiled without gpac/.mp4 output support in bookworm and later, cf:
  unblock: x264/2:0.164.3095+gitbaee400-3
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034653
  gpac/bullseye will not handle arbitrary data,
but rather data produced by x264
  security impact limited

- 112 open CVEs

- 3 past bullseye updates:
  DSA-4966-1 [31 Aug 2021] (24 CVEs)
  DSA-5411-1 [26 May 2023] (113 CVEs)
  DSA-5452-1 [14 Jul 2023] (3 CVEs)

Cheers!
Sylvain Beucler
Debian LTS Team

Security support for pypy and jython

[Sylvain Beucler]

Hello Security Team,

python2.7 was marked unsupported in bullseye.

We recently noted that pypy[v2] (included up to bullseye) and jython 
(all dists) include the python2 stdlib.  Unlike pypy3, neither package 
currently track the associated CVEs.



Do we want to mark pypy and jython as EOL, or limited-support, in 
debian-security-support?


Incidentally are there other packages that mass-embed python2 stdlib 
that we should also consider (I checked data/embedded-code-copies)?


Cheers!
Sylvain Beucler
Debian LTS Team

Re: gpac end-of-life in stretch (and recommendation for buster/bullseye)

[Sylvain Beucler]

Hi,

Since then:
- gpac was EOLd in buster
https://salsa.debian.org/debian/debian-security-support/-/commit/a0bfdf01d404aba46893d2971d776f8f7fb5337e
- gpac was removed from bookworm
https://tracker.debian.org/news/1430135/gpac-removed-from-testing/
- gpac was removed from sid
https://tracker.debian.org/news/1548977/removed-221dfsg1-31-from-unstable/

gpac in bullseye still has >100 open CVEs and I don't believe the 
situation described by Roberto improved.


Do we want to mark gpac EOL for bullseye as well?

Cheers!
Sylvain Beucler
Debian LTS Team

From: Roberto C. Sánchez 
Date: Fri, 20 May 2022 15:40:06 -0400

LTS and Security Teams,

Based on previous discussion [0], I have marked gpac as end-of-life for
stretch in commit 0a6147d6b8 of debian-security-support [1].  It seems
advisable that the Security Team do the same for gpac in buster and
bullseye.

Regards,

-Roberto

[0] https://lists.debian.org/debian-lts/2022/04/msg8.html
[1] 
https://salsa.debian.org/debian/debian-security-support/-/commit/0a6147d6b88d7c19ee7c072a344bbb63a7b1f32c

--
Roberto C. Sánchez

Debian LTS and ELTS - July 2024

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- ruby2.5/2.7
  - Assemble and import package history to Salsa (bullseye/bookworm)
  - Fix testsuite for bullseye
  - Fix salsa-ci setup (continuous integration) (see also tooling below)
  - Coordinate with planned DSA with samueloph
  - Start backporting patches

- apache2
  - Help analyse and test regression impacting package 'sympa' with rouca
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076554

- Prepare setup for new bullseye-lts (VM, pbuilder chroots)


ELTS

- ruby2.1/2.3/2.5
  - Assemble and import package history to Salsa (jessie/stretch/buster)
Coordinate Salsa Git hosting with #ruby-team
  - Fix testsuites
  - Fix salsa-ci setup (continuous integration) (see also tooling below)
  - Run testsuite on build for jessie + recheck and exclude broken or
flaky tests in various environments (salsa-ci, no network, etc.)
  - Address 2 incorrect past security fixes in jessie

- buster-lts -> buster-elts migration
  - fix impacted dists (jessie/stretch/buster) for planned updates
  - add & remove a few planned updates to match supported packages

- Prepare setup for new buster-elts (VM, pbuilder/piuparts chroots)


Documentation and tooling

- LTS Documentation
  - Development: switch from buster-lts to bullseye-lts
https://lts-team.pages.debian.net/wiki/Development.html
Development: clarify/update section on building/preparing an upload;
  simplify piuparts call; refresh pbuilder instructions
https://lts-team.pages.debian.net/wiki/Development.html#prepare-the-update
Development: add bullet point for accessing past security build logs

https://lts-team.pages.debian.net/wiki/Development.html#switching-to-the-next-lts-release
  - TestSuites: ruby: new page with testsuite handling and build caveats
https://lts-team.pages.debian.net/wiki/TestSuites/ruby.html
  - TestSuites: autopkgtest: develop new tests without a lengthy rebuild
https://lts-team.pages.debian.net/wiki/TestSuites/autopkgtest.html
  - dla-needed.txt: warn against conflicting with bullseye point
update (planned 2024-08-31)

- Internal documentation
  - './find-work' doc fixes following past merge with 'bin/package-operations'

- salsa-ci (continous integration) failures investigation and fixes
  - Build: fix lax permissions in top-level directories (causes tests failures)
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/362
Review merge request (fix gitlab umask)
https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/520
  - piuparts: fix APT suites discrepancies (causes tests failures)
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/292
This also get-rid of past work-arounds
https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/524
  - autopkgtest: elts fork: don't run as root (caused tests failures)
https://salsa.debian.org/lts-team/pipeline/-/issues/10
https://salsa.debian.org/lts-team/pipeline/-/merge_requests/19
  - elts fork: start buster-elts switch
https://salsa.debian.org/lts-team/pipeline/-/merge_requests/18
  - SSH access to investigate build failures (feature request)
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/363
https://salsa.debian.org/salsa/support/-/issues/148

- ELTS tooling
  - package-operations/find-work: fixes for buster-elts migration
move buster to ELTS
support multiple dists in *la-needed.txt e.g. 'mypackage/stretch,buster'
  for listing and addition operations
(private)
  - elts-eol: support multiple dists in *la-needed.txt

https://salsa.debian.org/freexian-team/extended-lts/security-tracker/-/blob/master/bin/elts-eol
  - bin/related-cves.py: update help for for buster-elts common usage

https://salsa.debian.org/freexian-team/extended-lts/security-tracker/-/blob/master/bin/related-cves.py
  - security-tracker-elts: pre-commit-elts: reference more elts-specific files

https://salsa.debian.org/freexian-team/extended-lts/security-tracker/-/blob/master/conf/pre-commit-elts
  - ELTS security tracker WebUI: help debug missing buster-lts source
https://deb.freexian.com/extended-lts/tracker/

- security-tracker: fix 2 issues causing cron warnings every 15mn

- IRC meeting
  http://meetbot.debian.net/debian-lts/2024/debian-lts.2024-07-18-14.01.html

-- 
Sylvain Beucler
Debian LTS Team

Debian LTS and ELTS - June 2024

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- Front-Desk (week 25)
  - Mark 1 package for update 
  - Triage or precise triage for 10+ CVEs
  - Check tryton-client/server situation


ELTS

- Front Desk (week 25)
  - Associate CVEs from newer, branched Debian packages with different
names to older ELTS packages (golang*, mariadb*, openssl*, php*,
postgresql*, python*, ruby*, unbound*)
  - Mark 2 supported packages for update
  - Triage or precise triage for a few CVEs
  - Clarify libndp, libvpx and unbound1.9 situations


Documentation and tooling

- LTS Documentation
  - Development: mention changelog date and SOURCE_DATE_EPOCH impact
https://lts-team.pages.debian.net/wiki/Development.html#build-the-update
  - TestSuites: autopkgtest: precise lxc/network setup
https://lts-team.pages.debian.net/wiki/TestSuites/autopkgtest.html
  - TestSuites: php: reference some new non-official backports branches
https://lts-team.pages.debian.net/wiki/TestSuites/php.html

- Tooling
  - Improve readability of LTS triage tool (lts-cve-triage.py)

- Jitsi Meeting
  https://lists.debian.org/debian-lts/2024/06/msg00012.html


-- 
Sylvain Beucler
Debian LTS Team

Debian LTS and ELTS - May 2024

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- Front Desk (week 18, second half)
  - Mark 4 packages for update
  - Triage or precise triage for 30+ CVEs
  - Coordinate LTS/ELTS discrepancy for non-free firmware packages

- cacti
  - Incomplete fix reported 2024-03 is published as CVE-2024-29894
  - Provide follow-up fixes to Cacti upstream (and reference them in
the security tracker)
https://github.com/Cacti/cacti/pull/5751
https://github.com/Cacti/cacti/pull/5752


ELTS

- Front Desk (week 18, second half)
  - Associate CVEs from newer, branched Debian packages with different
names to older ELTS packages (freerdp*)
  - Mark 4 supported packages for update
  - Triage or precise triage for a few CVEs
  - Provide guidance with handling 'putty'


Documentation and tooling

- LTS Documentation
  - Development:
Clarifications, add links
Move ELTS-specific Front-Desk task to ELTS doc
https://lts-team.pages.debian.net/wiki/Development.html
  - TestSuites: glib2.0: reference maintainer tests suggestion
https://lts-team.pages.debian.net/wiki/TestSuites.html
https://lists.debian.org/debian-lts/2024/05/msg00010.html

- ELTS Documentation (internal)
  - Improve navigation
  - Multiple link updates, additional internal links, typos fixes

- Tooling
  - Drop unused 'find-rdeps' script
  - ELTS security tracker: optimize lengthy post-commit checks
  - Report issue with pyxian source access

- IRC meeting
  https://meetbot.debian.net/debian-lts/2024/debian-lts.2024-05-23-14.00.html

-- 
Sylvain Beucler
Debian LTS Team

Re: Fixing glib2.0 CVE-2024-34397 in buster

[Sylvain Beucler]

Hello Simon,

Markus (apo) claimed the package yesterday after your message.

For clarity I'm CC:ing him here, and I added a note in data/dla-needed.txt.
https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/dla-needed.txt

Also, thanks for the testing procedure :)

Cheers!
Sylvain Beucler
Debian LTS Team

On 10/05/2024 17:02, Simon McVittie wrote:

Please cc either me or the glib2.0 package's address on any replies that
are relevant outside the LTS team: I am not subscribed to -lts.

Normally I don't attempt to support any packages in the LTS distributions,
but for glib2.0 I was the author of the original CVE fix and it turns
out that I might need a buster-compatible version of it for my day job,
so I've done a prototype backport to buster:
https://salsa.debian.org/gnome-team/glib/-/merge_requests/39
(git fetch https://salsa.debian.org/gnome-team/glib wip/cve-2024-34397/buster)

This incorporates:

* the original CVE fixes developed under embargo and released to bookworm
   and bullseye as DSA 5682-1, to unstable as 2.80.0-10, and to Ubuntu
   (the version used here is very similar to the one in bullseye, but with
   even more conflict resolution)

* automated test coverage for the CVE fix, released in the same versions
   as above (again the version used here is very similar to the one in
   bullseye, with minor adjustments to avoid requiring newer APIs)

* a fix for a serious regression in ibus introduced by the CVE fixes,
   released to bookworm and bullseye as DSA 5682-2, to unstable in 2.80.1-1,
   and to Ubuntu

* a fix for a minor/rare memory leak introduced by a prerequisite patch
   backported as part of the CVE fixes (see #1070851), released to unstable
   in 2.80.2-1 but not yet fixed in bookworm/bullseye or Ubuntu; this seems
   low-risk, but can be dropped/reverted if it makes the LTS team unhappy

Please could whoever handles this in the LTS team take over review/testing
from this point, and let me know if there are any problems?

In the newer suites, this update was accompanied by a fix for gnome-shell,
in which screencasting/screen-recording would have regressed after fixing
the vulnerability. In buster, my understanding is that this will not be
necessary, because GNOME Shell 3.30.x is too old to have had the relevant
bug; but I have not tested a full buster system.

I would recommend testing:

* build-time tests

* autopkgtest

* general use of GNOME

* gnome-shell: whatever screen recording or screencasting functionality was
   present in buster, if any (I don't remember what was offered in 3.30.x)

* ibus: Compose key, dead keys, and ideally non-Latin input
   (e.g. Japanese with mozc)

Thanks,
 smcv

Debian LTS and ELTS - April 2024

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- Front Desk (week 18, first half)
  - Triage or precise triage for 10+ CVEs
  - Tidy work queue (dla-needed.txt)


ELTS

- Front Desk (week 18, first half)
  - Associate CVEs from newer, branched Debian packages with different
names to older ELTS packages (emacs*, firebird*, golang*,
openssl*, netty*, php*, python*, ruby*, tomcat*); reference
libcoap* for upcoming buster-elts
  - Mark 4 supported packages for update


Documentation and tooling

- LTS Documentation
  - Development: revamp CVE triaging sections, add section on related packages

https://lts-team.pages.debian.net/wiki/Development.html#triage-security-issues
Details of this extensive change can be found at

https://salsa.debian.org/lts-team/lts-team.pages.debian.net/-/merge_requests/15
  - TestSuites: curl: precise scope
https://lts-team.pages.debian.net/wiki/TestSuites/curl.html
  - Development: move generic GPG lists troubleshooting to the wiki
https://wiki.debian.org/DebianMailingLists#PGP-based_approvals

- Help with handling package / understand triage:
  https://lists.debian.org/debian-lts/2024/04/msg00014.html
  https://lists.debian.org/debian-lts/2024/04/msg00015.html

- Jitsi meeting
  Also took notes:
  https://lists.debian.org/debian-lts/2024/04/msg00113.html

-- 
Sylvain Beucler
Debian LTS Team

Re: How to handle freeimage package

[Sylvain Beucler]

Hi,

I think this requires a bit of coordination:
- the package is basically dead upstream, there hasn't been a fix in the 
official repos, neither Debian or other distros attempted to fix them
- we do have a sponsor for LTS and ELTS/stretch, so we're paid to take 
care of this package

- secteam usually sets unimportant/low/high severity, not us

So I wonder if this package is still supportable. I'd suggest you sync 
with LTS Coordinator to see if we should invest time in fixing the 
issues ourselves, or drop the package from debian-security-support.


If you also want to alter the severity of the fixes, I'd suggest you 
coordinate with the Security Team first.


Cheers!
Sylvain

On 08/04/2024 00:06, Ola Lundqvist wrote:

Hi again

Today I looked at the freeimage package that we have in dla-needed.
My conclusion is that we have 19 CVEs postponed with motivation "revisit 
when fixed upstream" and 23 CVEs that are in bullseye declared as no-dsa 
with the same motivation.


Since we have this postpone decision for the 19 CVEs we should declare 
the rest as postponed as well. This means that the package should go 
away from dla-needed after such an operation.


Or am I reasoning in the wrong way?

In fact I think all the ones with local DoS class should be declared 
"low" severity.


If I do not hear anything about this I will change this in the way I 
describe above.

Re: Remove runc from dla-needed

[Sylvain Beucler]

Hi,

Please read the dla-needed.txt entry.
It says we should sync *bullseye*.

Cheers!
Sylvain

On 07/04/2024 23:47, Ola Lundqvist wrote:

Hi fellow LTS contributors

I was about to assign runc to myself but realized that it should not be 
in dla-needed.
There is just one CVE to be fixed and that one is marked as no-dsa with 
note minor issue.


I will therefore do the following.
Change the no-dsa to postponed and remove runc from dla-needed.

If anyone have any objections, please let me know.

Debian LTS and ELTS - March 2024

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- cacti
  - Finalize triple lts/oldstable/stable upload
  - DLA-3765-1
https://lists.debian.org/debian-lts-announce/2024/03/msg00018.html
  - DSA 5646-1
https://lists.debian.org/debian-security-announce/2024/msg00054.html
  - Coordinate with Cacti upstream to address incomplete fix
(CVE-2024-29894 / GHSA-grj5-8fcj-34gh)

- Front Desk (week 11)
  - Mark 4 packages for update
  - Triage or precise triage for 15+ CVEs
  - Tidy work queue (dla-needed.txt)
  - Help refine triage logic following multiple package drops
  https://lists.debian.org/debian-lts/2024/03/msg00027.html
  https://lists.debian.org/debian-lts/2024/03/msg00035.html
  no-dsa vs. no-dla (internal list)
Re-add 1 package, drop 2 packages
  - Fix multiple missing package records in internal database and
notify past FD to update workflow
  - Feedback on tracking LTS -> oldstable/stable synchronization
https://lists.debian.org/debian-lts/2024/03/msg00038.html
https://lists.debian.org/debian-lts/2024/03/msg00044.html


ELTS

- python3.4
  - Finalize Salsa test suite fixes
  - Fix unreferenced vulnerability in heappq Module and check
python2.7 upload
  - ELA-1056-1
https://www.freexian.com/lts/extended/updates/ela-1056-1-python3.4/

- Front-Desk (weeks 10 and 11)
  - Associate CVEs from newer, branched Debian packages with different
names to older ELTS packages (golang*, postgres*, unbound*,
tomcat*)
  - Mark 5 supported packages for update
  - Triage or precise triage for 15+ CVEs


Documentation and tooling

- Tooling
  - salsa: Make timeout action explicit in the logs
https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/481
  - package-operations: don't pre-create Git repos anymore as Front-Desk
(internal)

- LTS Documentation
  - Git Workflow: warn about various/silent timeouts
https://lts-team.pages.debian.net/git-workflow-lts.html
  - Development: Git-related checks

https://lts-team.pages.debian.net/wiki/Development.html#publish-the-git-repository-and-tags
  - Development: clean-up e-mail announcement section
https://lts-team.pages.debian.net/wiki/Development.html#announce-the-update
https://wiki.debian.org/DebianMailingLists#PGP-based_approvals
  - package database: fix-up python* TestSuites pages
  - ELA procedure: suggest website commit message
(internal)
  - ELTS local autopkgtest/qemu: reference truncation issue
(internal)

- ELTS staging system (currently opt-in)
  - Debug/feedback for ci.freexian.com
  - Update upcoming ELA documentation
rdeps status updated ~every hour
Fix missing dcut suite
(internal)

- IRC meeting

-- 
Sylvain Beucler
Debian LTS Team

Re: Expanding the scope (slightly) of dla-needed.txt

[Sylvain Beucler]

Hi,

On 17/03/2024 06:54, Sean Whitton wrote:

On Thu 14 Mar 2024 at 04:47pm -04, Roberto C. Sánchez wrote:


- it is important update the notes on packages in dla-needed.txt to
   indicate what work has been done and what remains


I think that we should be also reviewing old notes and deleting those
that don't matter anymore.  I've been trying to do this with at least my
own notes.  My understanding is that the purpose of the document is more
of a to-do list than a logbook.


I believe they are both: initially pointing what needs to be done, then 
a log of what has been achieved so far (allowing coordinators and 
contributors to check on progress/issues). A bit like a Salsa issue :)


Cheers!
Sylvain

Re: Guidance for CVE triage and listing packages in dla-needed.txt

[Sylvain Beucler]

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/services/deblts/lts/git' is not a git working directory


=> fix this first in your ~/.config/freexian.ini :)

Cheers!
Sylvain Beucler
Debian LTS Team

Re: Expanding the scope (slightly) of dla-needed.txt

[Sylvain Beucler]

Hi,

On 14/03/2024 21:47, Roberto C. Sánchez wrote:

- FD should be confirming that package removals from dla-needed.txt are
   valid (i.e., that the package does not require any work towards an
   upload to (old)stable)


Phrased that way, I don't really like the idea of FD checking on his 
peers' work.


I believe this is better from a person with a hierarchical relationship 
(such as coordinator... :)), and long-term availability (by-week FD 
probably won't check Sunday's uploads, nor ping possibly busy 
contributors the next weeks to clarify if work is needed and/or underway).



Technically the tracking should already happen in data/dsa-needed.txt 
(for a confirmed DSA) or bugs.debian.org tag=pu (for point updates). So 
we only want to track a temporary state when the possibility of a 
LTS-Team-made update is initially coordinated with secteam and/or 
package maintainer. Do we really need that? :)


Cheers!
Sylvain

Re: Guidance for CVE triage and listing packages in dla-needed.txt

[Sylvain Beucler]

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 already.


So, if a package has few users (and likely few/no sponsors) it will be 
sorted as low-priority and worked on only when time is available :)


Cheers!
Sylvain

On 14/03/2024 23:53, Ola Lundqvist wrote:

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 backport 
the correction? I mean say it takes 200 hours to fix a package with a 
fairly minor issue that rarely anyone uses. Should we ignore in 
such case? Yes I'm taking things to the extreme here, but just to 
highlight that there are greyzones.


Cheers

// Ola

On Thu, 14 Mar 2024 at 23:39, Ola Lundqvist > wrote:


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 mailto:robe...@debian.org>> wrote:

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 technical grounds
to the
   contrary (e.g., minor issue, high risk of regression, too
difficult to
   feasibly backport, etc)


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 all
minor issues too. I do not agree to that, but others has expressed
that opinion.

- if a CVE is 'fixed' in LTS but still 'no-dsa' in (old)stable,
then we
   should do what we can to coordinate uploads to (old)stable so
that the
   issue is fixed in a future point release
- 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
- note that 'fixed' in the above items specifically means "fixed
by way
   of a DLA (or earlier DSA), rather than 'not-affected' (since
   'not-affected' renders as 'fixed' in the package-level view)"

Second, as to the matter of the criteria for keeping packages in
dla-needed.txt:

- if a package requires work by the LTS team, then it should
remain in
   dla-needed.txt; this includes if a DLA has already been
published and
   we are working to support an upload to (old)stable
- if a package is assigned, it must not be removed without first
   coordinating with whomever has claimed it (this is to avoid
confusion
   about what work is being done and the state of the package)
- just because all CVEs for a package are 'no-dsa' (or even
'postponed')
   in LTS does not mean that the package must be removed from
   dla-needed.txt; it may be that there are multiple no-dsa or
postponed
   CVEs and that they collectively merit an update


  I think we should add that if LTS has an issue as no-dsa/postponed
and (old-)stable has it fixed, then we should add/keep the package
to dla-needed (or decide to ignore in case it is too invasive) to
ensure LTS gets it fixed as well. At least that was the rule I
concluded from the discussion and why I re-added a few packages back
to dla-needed.

I also think we should add that in the typical case (all
no-dsa/postponed/ignored/fixed and they are few) this means that the
package should be removed from dla-needed.txt. I think it has a
merit, just to keep things tidy.

In fact I think we should typically remove the package from
dla-needed if it should not have been added, with exceptions
described above.

Best regards

// Ola



Finally, as to the matter of Go and Rust packages (since
golang-go.crypto was among the packages caught in the recent
discussion
on triaging), please note the following from the Debian release
notes
[0]:


5.2.1.2. Go- and Rust-based packages

The Debian infrastructure currently has problems with rebuilding
packages o

Re: Removal of sendmail from dla-needed?

[Sylvain Beucler]

Hi,

For reference, re-added through
https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/9a2a182dc53f0632ecd32108c91c071bdad76289

Cheers!
Sylvain Beucler
Debian LTS Team

On 10/03/2024 23:18, Ola Lundqvist wrote:

Hi all

Since I'm not 100% sure about this one I'm sending this out to the list.

We have sendmail in dla-needed. I do not see why so I have removed it.
But I see the following notes:

   NOTE: 20240213: Patch need to be extracted (rouca). Upstream does not 
publish patches

   NOTE: 20240217: Patch extracted and being reviewed (rouca)

What CVE(s) do this comment apply to? I'm asking since we have no CVE 
that is not no-dsa.


Comments or objections?

Re: Question about tinymce dsa/no-dsa decisions

[Sylvain Beucler]

Hi Ola,

On 12/03/2024 20:52, Ola Lundqvist wrote:
I have claimed the package myself now. I think the conclusion will be 
that all are minor issues and the package do not need an update. But we 
will see when I have gone through all the CVEs.


tinymce is only available up to buster, so we don't have to sync with 
stable/oldstable, and can make a decision directly.



However if you look more closely, you can see that all
those CVEs are of "cross site scripting" nature and when you look at
the rest of the issues in that list there are many more with the
same type of issue and then marked as no-dsa.


In this case, XSS is defeating the core feature of the tool, so I would 
fix them.



If I would have triaged this package as front-desk I would have
marked the rest the same with the reasoning that there are anyway so
many of the same type so it does not help to fix a few others.


The newer CVEs weren't shown in FD's tools since it was already added to 
dla-needed.txt, hence why they weren't triaged.



So my question is:
- Should those CVEs that are not no-dsa today be marked as no-dsa
and in that case the package to be removed from dla-needed?
or
- Should the XSS type issues already be marked as no-dsa in fact
have the no-dsa tag removed and we should fix them as well?


See also my other mail on interpreting "no-dsa" in the context of LTS.

Here we've got a bunch of postponed XSS to fix, and a sponsor, so I'd 
say go ahead a publish a DLA to fix them all :)


Cheers!
Sylvain
FD this week

Debian LTS and ELTS - February 2024

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- cacti
  - Finish triaging and backporting CVEs growing backlog
  - Update the security tracker with numerous incorrect or missing
patches, and CVE limitations
  - Report duplicate CVEs to MITRE
  - Test CVE fixes
  - Find and report incomplete fix to Cacti upstream, and contribute
patch; waiting for their answer (GHSA-grj5-8fcj-34gh)
  - Contribute package update for (non-LTS) bullseye/oldstable and
bookworm/stable, waiting for review from Debian maintainer and
security team


ELTS

- python3.4
  - Review and clean-up preliminary work by other contributor
  - Debug and rework Salsa CI setup
  - Multiple fixes to test suite


Documentation and tooling

- Identify contributor-level issue with freexian administrative
  tooling and help test

- Documentation
  - (internal) improves notes on reproducing ELTS autopkgtest setup
locally
  - TestSuites: improves python3 notes
https://lts-team.pages.debian.net/wiki/TestSuites/python3.html

- Jitsi meeting

-- 
Sylvain Beucler
Debian LTS Team

Debian LTS and ELTS - January 2024

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- Front Desk (week 4)
  - Mark 1 package for update
  - Triage or precise triage for ~20 CVEs
  - Tidy golang-1.11 buster triage

- cacti
  - Continue triaging and backporting CVEs backlog, for buster
  - Tidy Git repository for buster


ELTS

- Front-Desk (week 4)
  - Associate CVEs from newer, branched Debian packages with different
names to older ELTS packages (freerdp*, golang*, libidn2*,
openssl*, python3*, tomcat*)
  - Mark 4 supported packages for update
  - Triage or precise triage for ~15 CVEs
  - Drop 2 unsupported packages

- freerdp [v1]
  - Continue work from last month
  - Fix another regression, in past CVE-2020-11089 fix
  - Clarify incorrect CVE-2023-40188 description with upstream
  - Coordinate Git hosting with Debian Remote team
  - Stress-test new Freexian CI staging
  - ELA-1030-1
https://www.freexian.com/lts/extended/updates/ela-1030-1-freerdp/


Documentation and tooling

- Report incorrectly supported modsecurity-crs/jessie

- Documentation
  - TestSuites: more freerdp tests
https://lts-team.pages.debian.net/wiki/TestSuites/freerdp.html
  - Ping lts-coordinator about issues with Front-Desk reminder template

-- 
Sylvain Beucler
Debian LTS Team

Debian LTS and ELTS - December 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- Front Desk (week 48, December half)
  - Mark 5 packages for update
  - Triage or precise triage for <10 CVEs
  - Tidy golang-1.11 buster triage

- cacti
  - Continue triaging CVEs growing backlog, for buster
  - Identify 2 incorrect bullseye patches, coordinate with package maintainer
  - Precise stable triage for <10 CVEs


ELTS

- Front-Desk
  - Associate CVEs from newer, branched Debian packages with different
names to older ELTS packages (cfengine*, golang*)
  - Mark 2 supported packages for update
  - Identify incorrect CVE in ELA-997-1/python3.5

- freerdp [v1]
  - Continue triaging CVEs backlog (synchronized with freerdp2 2 months ago)
  - Fix regression in past CVE-2020-11096 fix
  - Update and testing setup in progress


Documentation and tooling

- Provide feedback on various internal tasks
  (lts-do-call-me/lts-do-not-call files handling, ELTS support for
  gnupg1 and binutils, documentation tooling configuration)

- Open task to check the CVE list consistency in data/DLA/list and
  data/ELA/list
  https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/61

- Propose action to handle stable-security private build logs
  https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51
  https://lists.debian.org/debian-lts/2023/12/msg00024.html

- Help on (non-LTS) debian-security list
  https://lists.debian.org/debian-security/2023/12/msg8.html

- Documentation
  - Development: dereference website updates instructions which got automated
https://lts-team.pages.debian.net/wiki/Development.html
  - TestSuites: new xfreerdp entry
https://lts-team.pages.debian.net/wiki/TestSuites/xfreerdp.html

- Jitsi team meeting


-- 
Sylvain Beucler
Debian LTS Team

Re: upcoming changes of the web pages /security and /lts/security

[Sylvain Beucler]

Hi,

On 26/12/2023 11:12, Holger Levsen wrote:

On Mon, Dec 25, 2023 at 10:56:56PM +0100, Thomas Lange wrote:

 > what do we need to do instead? :)
Nothing in the webwml repository.
The list of recent advisories on the web pages is now automatically
generated from the data from the security tracker.
It's important that the announcement mail is sent and that those lists
are updated:
https://salsa.debian.org/security-tracker-team/security-tracker/-/raw/master/data/DSA/list
https://salsa.debian.org/security-tracker-team/security-tracker/-/raw/master/data/DLA/list
That's all.


ah, very nice! & thanks for clarifying too!


https://lts-team.pages.debian.net/wiki/Development.html updated :)

Cheers!
Sylvain Beucler
Debian LTS Team

Re: Make stable-security build logs public after embargo

[Sylvain Beucler]

Hi all,

Actually we have a summary of the situation here:
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51

We have mostly 2 options:

1/ General fix, involving a dak hook and some corner cases, and more 
importantly having access to the infrastructure,


2/ One-off mass injection of [oldstable]-security build logs when 
starting a new LTS dist.



Given that 1/ was attempted a couple times in the past and never reached 
completion, and given that we might solve this if the debusine [1] 
project is adopted, I think we can drop it for now.


Doing 2/ next August for bullseye sounds doable, solves the most 
immediate use case (i.e. LTS devs comparing previous logs on new FTBFS), 
so I think we can privilege this option.


What do you think?

[1] https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Zini

Cheers!
Sylvain Beucler
Debian LTS Team

On 12/12/2023 00:02, Roberto C. Sánchez wrote:

Hello again Wanna-build team,

On Thu, Jun 01, 2023 at 04:51:56PM +0200, Sylvain Beucler wrote:

Hello Wanna-build team,

I'm part of the Debian LTS Team, and along with the Security Team, we're
looking into making embargo'd build logs eventually public.
See https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51

Typical use case: when the LTS Team is working on the first LTS security
upload for buster-security, the previous build logs are not available, while
they are critical to interpret any new build failure.
This also improves the overall transparency of the Debian project.

So we'd like to make the stable-security build logs eventually public,
preferably early. One approach is to make the build logs available through
https://buildd.debian.org/status/package.php on package release (when the
embargoes for the package and possibly its dependencies are lifted, and the
new packages are publicly distributed by Debian).
Another more straightforward approach, but way more delayed, is to make
these build logs available in batch, when handing over oldstable to the LTS
team.

Note: the new lts (buster-security) build logs are already made public, here
we're targeting future-lts (bullseye-security) build logs.

Currently we're not entirely sure on how build logs are injected to the
buildd.debian.org/status/package.php service, so we're contacting you to
determine how feasible this is. Typically:
- Locate and identify publishable logs (in e-mail archives on master?)
- Trigger the publication at the right time (dak hook?)

I also volunteer to spend some time on the implementation, as part of my
work on LTS.

Do you think this can be achieved, and how?


Has there been any progress or discussion regarding this? The LTS team
will be responsible for bullseye starting in August and it would be
beneficial if there could be a resolution to this.

Is there anything that we could do from our side to help move things
along?

Regards,

-Roberto

Debian LTS and ELTS - November 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- Front Desk (week 48, November half)
  - Mark 5 packages for update
  - Triage or precise triage for 10+ CVEs
  - Help analyze curl and flatpak synchronization with bullseye/oldstable
(whether to backport some minor security fixes from the dot release)
  - Help analyze golang-yaml.v2 update (DLA-3479-1) in the context of
a potential a mass reverse-dependencies rebuild

- cacti
  - Start triaging recent CVE mass-submissions
  - Coordinate Git reference repository for LTS with maintainer


ELTS

- Front Desk (week 48, November half)
  - Associate CVEs from newer, branched Debian packages with different
names to older ELTS packages (mariadb*, netty*, postgresql*,
tomcat*)
  - Mark 5 supported packages for update
  - Triage or precise triage for 10+ CVEs
  - Clean-ups/precisions in work queue
  - Help analyze Go-based (statically-compiled) packages support
  - Help analyze kde4libs again in the context of checking packages
with limited support

- freerdp [v1]
  - Start triaging CVEs backlog (synchronized with freerdp2 last month)


Documentation and tooling

- Work queue report (internal "find-work" tool)
  - Minor clean-ups and clarifications following last month's work

- ELTS documentation: clarification on jessie signatures
  https://www.freexian.com/lts/extended/docs/how-to-use-extended-lts/

- IRC team meeting
  http://meetbot.debian.net/debian-lts/2023/debian-lts.2023-11-30-13.57.html

-- 
Sylvain Beucler
Debian LTS Team

Re: tinymce git repository

[Sylvain Beucler]

Hi Sean,

At a point LTS pre-created *empty* Git repositories under 
/lts-team/packages for packages added to dla-needed.txt, but since then 
we've been trying to leave that to the contributor, so he can e.g. 
appropriately fork the repository and better keep the history.


Consequently empty Git repositories were archived.

You should be able to re-create a new tinymce repositories yourself, 
possibly forking /debian/tinymce or even coordinating with the 
maintainer to track the LTS releases there.


Cheers!
Sylvain/Front-Desk

On 30/11/2023 10:29, Sean Whitton wrote:

Hello Anton,

Ola added tinymce to dla-needed.txt.

I found .

Could you let me know why the repository was archived?

Thanks.

Debian LTS and ELTS - October 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- Front Desk (week 40)
  - Mark 13 packages for update
  - Triage or precise triage for 15+ CVEs
  - Clean-ups/precisions in work queue

- request-tracker4
  - administrative help with non-team upload


ELTS

- Front Desk (week 40)
  - Associate CVEs from newer, branched Debian packages with different
names to older ELTS packages (openssl*, golang*, python*,
freerdp2*, php*)
  - Mark 10 supported packages for update
  - Triage or precise triage for 10+ CVEs
  - Clean-ups/precisions in work queue

- Supportability for packages with limited support (internal issue)
  - Feedback for golang* and gnupg1 packages


Documentation and tooling

- Work queue report (internal "find-work" tool)
  - Update and clarify long-term rewrite goals
  - Refactor and simplify code
  - Following last meeting, propose improved ordering/priority, taking
into account package age in the queue (to be reviewed)
http://meetbot.debian.net/debian-lts/2023/debian-lts.2023-09-28-13.58.html

- Help other contributors on IRC

- Jitsi team meeting

-- 
Sylvain Beucler
Debian LTS Team

Debian LTS and ELTS - September 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- ruby-loofah & ruby-rails-html-sanitizer
  - Dual upload, as ruby-loofah needed to be adapted so its new
security functions could used by ruby-rails-html-sanitizer
  - Clean-up ruby-rails-html-sanitizer Git history
  - DLA 3565-1 for ruby-loofah (3 CVEs)
https://lists.debian.org/debian-lts-announce/2023/09/msg00011.html
  - DLA 3566-1 for ruby-rails-html-sanitizer (4 CVEs)
https://lists.debian.org/debian-lts-announce/2023/09/msg00012.html

- glib2.0
  - Peer review and testing for Santiago's DLA 3583-1
https://lists.debian.org/debian-lts-announce/2023/09/msg00030.html

- tiff
  - Additional triage, update fixed CVEs in past uploads
  - Drop from work queue


ELTS

- glib2.0
  - Peer review and testing for Santiago's ELA 964-1
https://www.freexian.com/lts/extended/updates/ela-964-1-glib2.0/

- tiff
  - Additional triage, vulnerability assessment, update fixed CVEs in
past uploads
  - Drop from work queue

- libvpx
  - Rebuild Git history
  - ELA-973-1 (1 CVE, stretch & jessie)
https://www.freexian.com/lts/extended/updates/ela-973-1-libvpx/


Documentation and tooling

- LTS Documentation
  - TestSuites: rails buster update
https://lts-team.pages.debian.net/wiki/TestSuites/rails.html

- Tooling:
  - find-work: display old package in the queue in red
(following weekly report)

- Team discussions (private GitLab issues)
  - Experimental GitLab issue-based workflow:
Clean-up and unify my LTS/ELTS check-list
  - Help clarify linux-5.10 status in current tooling
  - Monthly report guidelines comment

- IRC team meeting


-- 
Sylvain Beucler
Debian LTS Team

Re: Call for tests/review: glib2.0/buster

[Sylvain Beucler]

Hi,

On 30/08/2023 02:13, Roberto C. Sánchez wrote:

On Sun, Aug 20, 2023 at 06:53:54PM -0300, Santiago Ruano Rincón wrote:

Dear all

I've prepared a glib2.0 update for buster (and I am working for older
releases). I think it should be ready, all the test pass. But since
there were some regressions with a first set of patches, it would be
great if someone could give it a try.

The packages are available following these instructions:
https://lts-team.pages.debian.net/-/packages/glib/-/jobs/4581183/artifacts/aptly/index.html


Has anyone been able to help with testing Santiago's glib2.0 update?


I considered it but I was mostly out of time, I can do some testing next 
week.  IIUC there was also progress on the older releases since.


Cheers!
Sylvain Beucler
Debian LTS Team

Debian LTS and ELTS - August 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- Front Desk (week 32)
  - Mark 15 packages for update
  - Triage or precise triage for 20+ CVEs
  - Investigate current status for long-standing packages
  - Clean-ups/precisions in work queue and package database
  - Help other contributors with triage questions
  - Peer-review Go guidelines RFC from Roberto
https://lists.debian.org/debian-go/2023/08/msg00023.html

- python-git
  - Minor follow-up for last month update
  - CVE issued for incomplete fix discovered during backport;
reference it

- gawk
  - Drop from queue, aligning with other dists (postponed minor issue)

- w3m
  - DLA 3541-1 (1 CVE)
https://lists.debian.org/debian-lts-announce/2023/08/msg00030.html
  - Propose missing follow-up fix for bullseye
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019599#37


ELTS

- Front Desk (week 31 2/2, week 32)
  - Associate CVEs from newer, branched Debian packages with different
names to older ELTS packages (openssl*, python*, ruby*, golang*,
postgresql*, php*)
  - Mark 9 supported packages for update
  - Triage or precise triage for 30+ CVEs
  - Investigate current status for long-standing packages
  - Help other contributors with triage questions (e.g. runc package)
  - Review history of newly supported packages (new customer)
  - Exceptional 2 weeks in a row, some of the early triage involved
LTS triaging as a side effect

- twisted
  - Minor follow-up for last month update
  - Get Git branches merged in upstream repository

- puppet-module-puppetlabs-mysql
  - Drop package from queue (minor issue with breaking changes)

- w3m
  - ELA-931-1 (1 CVE, stretch & jessie)
https://www.freexian.com/lts/extended/updates/ela-931-1-w3m/

- flask
  - Drop for jessie (already fixed but confusing CVE attribution)
  - ELA-940-1 (2 CVEs, stretch)
https://www.freexian.com/lts/extended/updates/ela-940-1-flask/


Documentation and tooling

- Experiment with a GitLab issue-based workflow for package updates,
  potential replacement for the current git- and file-based workflow
  - Help clarify goals
  - Draft issue template
  - Open 18 issues (as part of Front Desk duty)

https://salsa.debian.org/lts-team/lts-updates-tasks/-/issues/?state=all&label_name%5B%5D=DLA

https://salsa.debian.org/lts-team/lts-updates-tasks/-/issues/?state=all&label_name%5B%5D=ELA
  - Write-up personal DLA and ELA workflow for use a check-list
(while preparing updates for w3m and flask)
https://salsa.debian.org/lts-team/lts-updates-tasks/-/issues/42#note_421977
https://salsa.debian.org/lts-team/lts-updates-tasks/-/issues/36#note_423686

- LTS Documentation
  - information-for-lts-contributors (internal): clarifications

- Tooling
  - queue report ('find-work'): link tracker package status page

- Help newcomers on IRC

- Jitsi team meeting

-- 
Sylvain Beucler
Debian LTS Team

Re: bullseye / libgdbm6:amd64 is a catastrophgy

[Sylvain Beucler]

Hello Marc,

On 25/08/2023 11:24, Marc SCHAEFER wrote:

AFAIK is bullseye not yet LTS-handled.

Will LTS fixes important bugs, or only security fixes?

I reported this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043023

I have a local work-around (keep the buster version), and the maintainer also
proposed another local work-around. Mine is running productively for a few
weeks now.

Will LTS, when it takes hold of bullseye, fix this important bug?


First, from your bug report I read the maintainer's answer:
"[...] you upgraded to oldstable, which will only receive security fixes."

Actually, bullseye (even as oldstable) may receive updates for important 
bugs, through the point releases (proposed-updates):

https://wiki.debian.org/DebianReleases/PointReleases

LTS may also fix non-security bugs, but since it currently doesn't have 
point releases, this is rarer.



Now the maintainer worries that the bug fix "could break other 
installations that used to work well".


We tend to trust the maintainer's informed opinion, so we'd probably 
follow his advice and refrain from fixing the bug.  Of course it's 
possible to continue the discussion with the maintainer (e.g. with 
comprehensive testing).



In conclusion, I believe there's a higher chance of fixing the bug right 
now in bullseye/oldstable, rather later in bullseye/LTS.


Cheers!
Sylvain Beucler
Debian LTS Team

Re: Accepted thunderbird 1:102.14.0-1~deb10u1 (source) into oldoldstable

[Sylvain Beucler]

Hello Carsten,

Thanks for updating Thunderbird for buster :)

Do you want the LTS Team to take care of the DLA registration and 
announcement, or do you plan to do that yourself?

(I assume this matches https://www.debian.org/security/2023/dsa-5469)

Cheers!
Sylvain Beucler
Debian LTS Team

On 06/08/2023 09:00, Debian FTP Masters wrote:

Format: 1.8
Date: Sat, 05 Aug 2023 09:42:03 +0200
Source: thunderbird
Architecture: source
Version: 1:102.14.0-1~deb10u1
Distribution: buster-security
Urgency: medium
Maintainer: Carsten Schoenert 
Changed-By: Carsten Schoenert 
Changes:
  thunderbird (1:102.14.0-1~deb10u1) buster-security; urgency=medium
  .
* Rebuild for buster-security
Checksums-Sha1:
  4172ee99537d6f458a556f16fa2bdb204a9240f7 8436 
thunderbird_102.14.0-1~deb10u1.dsc
  f6256019a6362465a72c441e31c7b7d07831a242 552292 
thunderbird_102.14.0-1~deb10u1.debian.tar.xz
  b3bbb709f76b740ebcf5e48d1bab7ca28110fc04 39454 
thunderbird_102.14.0-1~deb10u1_amd64.buildinfo
Checksums-Sha256:
  4de4ec3460ef26cc30cd0c0dabbf6968c7a7a7e25469b6eb1c55d0bad739 8436 
thunderbird_102.14.0-1~deb10u1.dsc
  013a200c91b7b2f2669ea4893449ebadbeacd5aca3a543ad274424798ce8c171 552292 
thunderbird_102.14.0-1~deb10u1.debian.tar.xz
  5da213b4f3ca8ee8c2fd625c362948ef04f1447d3d88420148e6340f77e600f2 39454 
thunderbird_102.14.0-1~deb10u1_amd64.buildinfo
Files:
  e55f95efa78ee67676a224fee4ffc750 8436 mail optional 
thunderbird_102.14.0-1~deb10u1.dsc
  b9b12bcf2461d99d3b5e2a17710580b1 552292 mail optional 
thunderbird_102.14.0-1~deb10u1.debian.tar.xz
  1b61621cb000b0209403f7832ef94a75 39454 mail optional 
thunderbird_102.14.0-1~deb10u1_amd64.buildinfo

Debian LTS and ELTS - July 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- nsis
  - Test and review DLA 3483-1 from Sean Whitton
https://lists.debian.org/debian-lts/2023/07/msg00019.html
https://lists.debian.org/debian-lts-announce/2023/07/msg5.html

- python-git
  - DLA 3502-1 (1 CVE + 1 pending)
https://lists.debian.org/debian-lts-announce/2023/07/msg00024.html

- grpc
  - Investigate status including confusions in CVE descriptions
  - Drop (no more open issues)


ELTS

- mailman
  - Preliminary ELA work
  - Cancel due to end of ELTS support

- python-git
  - Discover incomplete fix for CVE-2022-24439 and coordinate new fix
https://github.com/gitpython-developers/GitPython/pull/1609
  - ELA-894-1 (stretch, 1 CVE + 1 pending)
https://www.freexian.com/lts/extended/updates/ela-894-1-python-git/

- twisted
  - Clean-up/refresh Git branches
  - ELA-896-1 (stretch & jessie, 3 CVEs)
https://www.freexian.com/lts/extended/updates/ela-896-1-twisted/

- Front Desk (week 31 1/2)
  - Start triaging open issues
  - Re-check qemu open CVEs waiting for official patches
  - Fix 2 incomplete ELA entries in security trackers
  - Document sox upstream status
  - Clean-ups/precisions in work queue and package database


Documentation and tooling

- Improve work queue report ('find-work')
  (private tooling planned to be made public)
  - Query maintainer coordination info from existing 'lts-do-call-me' file
  - Clean-up package database accordingly and coordinate with 1 maintainer
  - Fix crash

- LTS Documentation
  - TestSuites: further twisted testing
https://lts-team.pages.debian.net/wiki/TestSuites/twisted.html

- Fix DLA-3309-1/graphite-web announcement on webmasters notice
  https://bugs.debian.org/1041539

- Continue discussion on making stable-security build logs public
  after package release
  https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51#note_412097

- Internal discussion on GitLab issue-based workflow for package
  updates

- Help newcomers on IRC

-- 
Sylvain Beucler
Debian LTS Team

Re: nsis CVE-2023-37378

[Sylvain Beucler]

Hi,

On 08/07/2023 10:04, Sean Whitton wrote:

On Sat 08 Jul 2023 at 09:14am +02, Salvatore Bonaccorso wrote:


Just noticed the suffix for the version for the buster-security / LTS
upload was +deb9u1, was this intentional? This should have been
+deb10u1.


It wasn't.  Thank you for pointing out the mistake.


I should have seen/noted this while doing my quick review, sorry about 
that.  I guess I got confused as I'm working on a stretch update for 
another package.


Cheers!
Sylvain

Re: nsis CVE-2023-37378

[Sylvain Beucler]

Hello Sean,

I had a quick test with my:
http://git.savannah.gnu.org/cgit/freedink.git/tree/nsis
which is kinda old but does call WriteUninstaller.
The installer and uninstaller appear to work correctly in a W10 VM.

About the source changes, I'd recommend to use the CVE ID as part of the 
patch file name (otherwise it can be tedious to determine which fixed 
what, especially later on if there's (upstream) confusion over CVEs or 
regression fixes to consider).
In addition I like to add a couple fields to note the source of the 
patch and some who/when info, e.g.:

https://salsa.debian.org/lts-team/packages/runc/-/blob/debian/buster/debian/patches/CVE-2022-29162.patch

Cheers!
Sylvain Beucler
Debian LTS Team

On 06/07/2023 20:42, Sean Whitton wrote:

Hello,

I've prepared an upload to buster-security [1] to fix CVE-2023-37378.
I've tested it using an example script from [2], but if anyone reading
has a real, production NSIS script, that includes an uninstaller, in
particular, then testing my upload by using it to build your script
would be appreciated.

I can provide .debs if it's not straightforward for you to build it.

[1]  https://salsa.debian.org/lts-team/packages/nsis
[2]  https://nsis.sourceforge.io/Simple_tutorials

Debian LTS and ELTS - June 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- openssl
  - Reference/refresh recent patches in the security tracker
  - DLA 3449-1 (4 CVEs)
https://lists.debian.org/debian-lts-announce/2023/06/msg00011.html

- ffmpeg
  - Track fixed CVEs in past upload
  - DLA 3454-1 (4.1.10->4.1.11 upgrade, with unregistered vulnerabilities)
https://lists.debian.org/debian-lts-announce/2023/06/msg00016.html

- python-werkzeug/bullseye upcoming DSA
  - Review (based on my DLA 3346-1 for the same package)

- Front-Desk
  - Mark 16 packages for update
  - Triage or precise triage for 15+ CVEs
  - Request new CVE for package 'osslsigncode'
  - Clean-ups/precisions in work queue and package database
  - Follow-up on upload-related issues


ELTS

- sysstat
  - ELA-866-1 (1 CVE)
https://www.freexian.com/lts/extended/updates/ela-866-1-sysstat/

- Front Desk
  - Associate CVEs from newer, branched Debian packages with different
names to older ELTS packages (emacs*, golang*, netty*, openssl*,
php*, python*, tomcat*)
  - Mark 11 supported packages for update
  - Triage or precise triage for 10+ CVEs
  - Clean-ups/precisions in work queue


Documentation and tooling

- Continue discussion on making stable-security build logs public
  after package release, now involving other teams
  https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51
  https://lists.debian.org/debian-lts/2023/06/msg1.html

- Tooling: continue to revamp work queue report ('find-work')
  (private tooling planned to be made public)
  - Continue clean-up and finish review processes
  - Convert work queues (dla_needed.txt, ela_needed.txt) to drop
duplicate information
  - Display warning if the Debian package maintainer requests
involvement in LTS uploads (from 'data/packages/lts-do-call-me')
  - Display age in the work queue for each planned upload

- LTS Documentation
  - TestSuites: ffmpeg: refresh for buster
https://lts-team.pages.debian.net/wiki/TestSuites/ffmpeg.html
  - TestSuites: golang: refresh uploads involving reverse-dependencies

https://lts-team.pages.debian.net/wiki/TestSuites/golang.html#finding-reverse-build-dependencies
  - TestSuites: refresh index, fix mark-up
https://lts-team.pages.debian.net/wiki/TestSuites.html
https://lts-team.pages.debian.net/wiki/TestSuites/php.html
  - Development: drop coordinator work from front-desk section,
update/simplify 'package-operations' documentation,
clarify debian-archive-keyring rationale
https://lts-team.pages.debian.net/wiki/Development.html

- Guide non-security LTS upload from non-team contributor
  https://bugs.debian.org/1039489

- Continue internal discussions on packages claimfiles format/workflow

- Jitsi team meeting

-- 
Sylvain Beucler
Debian LTS Team

Re: #1036797 bullseye-pu: package mariadb-10.5 10.5.20-0+deb11u1

[Sylvain Beucler]

Hello Otto,

On 22/06/2023 19:41, Otto Kekäläinen wrote:

I filed on May 26th this but never got any reply from stable managers:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=103679

It is affected by only one minor CVE-2022-47015. The same CVE was
already fixed in DLA-3444-1 with MariaDB 10.3.39 which was the LTS
until two weeks ago.

Since bullseye is LTS now, I just wanted to quickly get ack'ed by the
LTS team that I should prepare this as for Bullseye?


bullseye is "oldstable" but security updates are still managed by the 
Security Team for 1 year, before LTS takes over in 2024.


https://wiki.debian.org/LTS was recently updated and should carry the 
right information :)


Cheers!
Sylvain

Re: Request for suggestions/opinion about triaging decision for renderdoc

[Sylvain Beucler]

Hi,

On 17/06/2023 22:14, Roberto C. Sánchez wrote:

My opinion is that the package should be added to dla-needed.txt with
a note linking to this thread on the mailing list.

[snip]

There should also be a note there to consider backporting a new upstream
release once the security team decides what to do for bookworm and
bullseye.


Done:

+renderdoc
+  NOTE: 20230620: Added by Front-Desk (Beuc)
+  NOTE: 20230620: See discussion at 
https://lists.debian.org/debian-lts/2023/06/msg00049.html
+  NOTE: 20230620: Summary: try to backport fixes; otherwise, since this 
is a end-user app with no rdeps,
+  NOTE: 20230620: coordinate with maintainer§eam to try and bump to 
1.27 across all dists (Beuc/front-desk)


Cheers!
Sylvain/Front-Desk

Make stable-security build logs public after embargo

[Sylvain Beucler]

Hello Wanna-build team,

I'm part of the Debian LTS Team, and along with the Security Team, we're 
looking into making embargo'd build logs eventually public.

See https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51

Typical use case: when the LTS Team is working on the first LTS security 
upload for buster-security, the previous build logs are not available, 
while they are critical to interpret any new build failure.

This also improves the overall transparency of the Debian project.

So we'd like to make the stable-security build logs eventually public, 
preferably early. One approach is to make the build logs available 
through https://buildd.debian.org/status/package.php on package release 
(when the embargoes for the package and possibly its dependencies are 
lifted, and the new packages are publicly distributed by Debian).
Another more straightforward approach, but way more delayed, is to make 
these build logs available in batch, when handing over oldstable to the 
LTS team.


Note: the new lts (buster-security) build logs are already made public, 
here we're targeting future-lts (bullseye-security) build logs.


Currently we're not entirely sure on how build logs are injected to the 
buildd.debian.org/status/package.php service, so we're contacting you to 
determine how feasible this is. Typically:

- Locate and identify publishable logs (in e-mail archives on master?)
- Trigger the publication at the right time (dak hook?)

I also volunteer to spend some time on the implementation, as part of my 
work on LTS.


Do you think this can be achieved, and how?

Cheers!
Sylvain Beucler
Debian LTS Team

Debian LTS and ELTS - May 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/lts/debian/#sponsors


LTS

- python2.7
  - First LTS upload
  - Fixes in past triage
  - Fix test suites for impacted Python packages
  - DLA 3432-1 (9 CVEs)
https://lists.debian.org/debian-lts-announce/2023/05/msg00024.html

- sysstat
  - DLA 3434-1 (1 CVE)
https://lists.debian.org/debian-lts-announce/2023/05/msg00026.html


ELTS

- python2.7
  - Fix mutiple test suite issues: backport official fixes;
investigate freezes; refresh all SSL certificates; update external
test servers; add, fix or re-enable tests for past CVEs
  - Improve one past fix, drop one for a future vulnerability
  - Tidy Git branches on Salsa
  - ELA-853-1 (6 CVEs, jessie & stretch)
https://www.freexian.com/lts/extended/updates/ela-853-1-python2.7/


Documentation and tooling

- Follow-up again on obsolete but supported packages that may lack
  active CVE triage (such as python2)
  - Associate past sqlite3 CVEs to sqlite + buster triage (2013-2019)
  - Help document further ELTS triage (from Tobias' ELA), add to LTS
queue, fix-up test suite in packages database
  - This concludes the work initiated in March
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/50

- LTS Documentation
  - TestSuites: refresh index
https://lts-team.pages.debian.net/wiki/TestSuites.html
  - TestSuites: python2: new page
https://lts-team.pages.debian.net/wiki/TestSuites/python2.html
  - Development: some re-ordering, some rephrasing, tidy styling
https://lts-team.pages.debian.net/wiki/Development.html
  - freexian.gitlab.io: refresh URLs

- Tooling: rework work queue report ('find-work'): ensure single copy
  of information, merge common code
  (private tooling planned to be made public)

- Start/coordinate discussion on making stable-security build logs
  public after package release
  https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51

- Help on LTS/ELTS IRC channels, and on debian-lts mailing list
  https://lists.debian.org/debian-lts/2023/05/msg00021.html
  https://lists.debian.org/debian-lts/2023/05/msg00027.html
  https://lists.debian.org/debian-lts/2023/05/msg00028.html

- Plan further notices about coordinating with specific package
  maintainers (lts-do-call-me), after a reminder from said maintainer

- Internal discussions on Git workflow, and packages claimfiles
  format/workflow

- IRC Meeting
  http://meetbot.debian.net/debian-lts/2023/debian-lts.2023-05-25-13.58.html

-- 
Sylvain Beucler
Debian LTS Team

Re: Bug 1035537 - split -n k/N gives incorrect data on blocks after the first

[Sylvain Beucler]

Hi,

On 19/05/2023 21:14, Chris Frey wrote:

On Fri, May 19, 2023 at 08:45:23PM +0200, Sylvain Beucler wrote:

On 05/05/2023 05:14, Chris Frey wrote:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035537


At first glance, it looks like this could lead to data corruption, and hence
warrant a 'grave' severity in the BTS.


Thanks for the response!  Yes indeed, the split file results will be
corrupt without the fix.

Is the severity level something I control, or the maintainer?


Everybody can alter the severity in the BTS, check:
https://www.debian.org/Bugs/server-control#severity
https://www.debian.org/Bugs/Developer#severities
(of course the maintainer may set it to another level if he sees fit.)


However I believe both the Security Team (for a bullseye DSA or
point-update, probably initiated by the maintainer) and the LTS Team (for a
buster DLA, probably based on bullseye's) would rather get the coreutil's
package maintainers input on the subject first (right now the BTS entry has
no replies) :)


I'm assuming the package maintainers have a closer relationship to the
upstream maintainers than I do, but I can help if needed.


As you mentioned, upstream already fixed this issue, I would suggest 
linking the upstream commit (which comes with documentation and updated 
tests) for clarity:

https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=bb21daa125aeb4e32546309d370918ca47e612db

AFAICS the bug is here since stretch, what I'd recommend is to get 
Michael Stone's (package maintainer) opinion on the matter (does he 
thinks this warrants a fix in stable or not) :)


Cheers!
Sylvain Beucler
Debian LTS Team

Re: Bug 1035537 - split -n k/N gives incorrect data on blocks after the first

[Sylvain Beucler]

Hello Chris,

On 05/05/2023 05:14, Chris Frey wrote:

I'd like to give a gentle nudge to the following bug, which affects
both Bullseye and Buster:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035537

If it can be fixed in LTS, that would be great.


At first glance, it looks like this could lead to data corruption, and 
hence warrant a 'grave' severity in the PTS.


However I believe both the Security Team (for a bullseye DSA or 
point-update, probably initiated by the maintainer) and the LTS Team 
(for a buster DLA, probably based on bullseye's) would rather get the 
coreutil's package maintainers input on the subject first (right now the 
BTS entry has no replies) :)


Cheers!
Sylvain Beucler
Debian LTS Team

Re: LTS: add libpcap to dla-needed.txt

[Sylvain Beucler]

For the record, typo was fixed: libpcap -> libcap2.

Cheers!
Sylvain

On 17/05/2023 12:01, Abhijith PA wrote:

Hello Anton,



From 5b2bcfaa20e12d0c90eb3999fba8b6e942e201ab Mon Sep 17 00:00:00 2001

From: Anton Gladky 
Date: Tue, 16 May 2023 22:39:34 +0200
Subject: [PATCH] LTS: add libpcap to dla-needed.txt

---
  data/dla-needed.txt | 4 
  1 file changed, 4 insertions(+)

diff --git a/data/dla-needed.txt b/data/dla-needed.txt
index af27234348..4dc0051201 100644
--- a/data/dla-needed.txt
+++ b/data/dla-needed.txt
@@ -63,6 +63,10 @@ libfastjson (Thorsten Alteholz)
NOTE: 20230507: Programming language: C.
NOTE: 20230507: the CVE was fixed in json-c already
  --
+libpcap
+  NOTE: 20230516: Programming language: C.
+  NOTE: 20230516: VCS: https://salsa.debian.org/lts-team/packages/libpcap.git
+--
  linux (Ben Hutchings)
NOTE: 20230111: Programming language: C
  --


I couldn't able to find any open CVE for libpcap. Any other issues ?


--abhijith

Re: nvidia-graphics-drivers in DLA needed?

[Sylvain Beucler]

Hi,

On 11/05/2023 17:22, Tobias Frost wrote:

nvidia-graphics-drivers-legacy-390xx is now uploaded, (tested with some old 
GTX770…)

A procedural question:
For the remaining CVE's (and those of nvidia-graphics-drivers), do I mark them
"end-of-life" (e.g by saying in CVE/list:
[buster] - nvidia-graphics-drivers  (EOL in buster LTS)
or just ignore them?


I think  would work if it's documented in 
debian-security-support.  Otherwise we can just continue to mark them 
, which is also what the security team does, e.g.:


CVE-2022-42259 ...
- nvidia-graphics-drivers-legacy-340xx 
	[buster] - nvidia-graphics-drivers-legacy-340xx  (Non-free not 
supported, no updates provided by Nvidia anymore)


Cheers!
Sylvain

Debian LTS and ELTS - April 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- Front Desk
  - Mark 6 packages for update
  - Triage or precise triage for 10+ CVEs
  - Update a few pending packages status
  - Report issues about 2 recent DLAs to contributors

- golang-1.11
  - Sync past bullseye CVE fixes to buster (first DLA)
  - Fix build issue when using 'debuild' tool
  - Investigate and fix test suite issues on arm64 buildds
  - DLA-3395-1
https://lists.debian.org/debian-lts-announce/2023/04/msg00021.html
  - Investigate and fix new test suite issues on 32-bit armhf system
on 64-bit host (thanks to carnil and pochu for their assistance)
  - DLA-3395-2
https://lists.debian.org/debian-lts-announce/2023/04/msg00022.html


ELTS

- Front Desk
  - Associate CVEs from newer, branched 'emacs*', 'golang-*',
'ruby2.*' and 'tomcat*' Debian packages to older ELTS packages
  - Mark 5 supported packages for update
  - Triage or precise triage for 15+ CVEs

- golang-1.7
  - Re-check following work on golang-1.11 in LTS
  - Impacted CVEs already fixed, nothing to do


Documentation and tooling

- Follow-up again on obsolete but supported packages that may lack
  active CVE triage (such as python2)
  - Continue discussion with the Debian Security Team
https://lists.debian.org/debian-lts/2023/04/msg1.html
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/50
  - Add 'gnupg1' to security-support-limited
https://salsa.debian.org/debian/debian-security-support/-/merge_requests/15
  - Match python2.7 open CVEs with python3.*, mark python2.7 for update
https://deb.freexian.com/extended-lts/tracker/source-package/python2.7
  - Start matching sqlite open CVEs with sqlite3
https://deb.freexian.com/extended-lts/tracker/source-package/sqlite
  - Prepare LTS-specific transitions file for bin/related-packages.py,
to do this work again on a regular basis

- LTS Documentation
  - TestSuites: golang: documentation following buster first DLA
https://lts-team.pages.debian.net/wiki/TestSuites/golang.html

- Clarify internal warning about planned unsupported ELA

- Help on LTS/ELTS IRC channels

- Team meeting cancelled due to low planned attendance and agenda items
  https://lts-team.pages.debian.net/wiki/Meetings.html


-- 
Sylvain Beucler
Debian LTS Team

Re: (E)LTS improved salsa pipeline support

[Sylvain Beucler]

Hi,

On 17/04/2023 21:36, Sylvain Beucler wrote:

On 20/03/2023 09:40, Emilio Pozuelo Monfort wrote:

On 17/03/2023 19:39, Raphael Hertzog wrote:

On Thu, 16 Mar 2023, Emilio Pozuelo Monfort wrote:

The result is an improved pipeline with better support for both LTS and
ELTS. [1]


Great work Emilio!

It would be nice to have all this properly documented in
https://lts-team.pages.debian.net


Ack, I can add something to the testing section of the development page.


I'm wondering if this new CI environment is meant for all new repositories?

Currently LTS contributors are supposed to follow the following 
documentation:

https://lts-team.pages.debian.net/git-workflow-lts.html

which IIUC is also what was automated in:
https://gitlab.com/freexian/services/deblts-team/debian-lts/-/blob/master/bin/package-operations#L985

i.e. with a local debian/.gitlab-ci.yml relying on:
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
plus optionally disabling some tests.


Should we use that existing setup, or the new CI setup you presented, 
for new LTS packages?


Additional elements:

- In the meantime, Emilio changed package-operations to reference the 
new recipe for automated repository creation, thanks! :)

(The workflow doc still points to the old recipe).

- Emilio also answered this on IRC:
> yes, the new CI is meant for all lts repos.
> using the URL directly instead of a file works if the repo only 
contains *LTS branches. for other use cases, pointing to the appropriate 
yml file would be best


I confirm that using the URL directly is currently annoying since even 
in LTS-only repos, it triggers for 'upstream' and 'pristine-tar' 
branches (which are not testable) :/


- Incidentally when attempting the new recipe with 'golang-1.11' it 
complains about having 0 jobs to perform

https://salsa.debian.org/lts-team/packages/golang-1.11/-/pipelines/521038

Cheers!
Sylvain

Re: (E)LTS improved salsa pipeline support

[Sylvain Beucler]

Hi,

On 20/03/2023 09:40, Emilio Pozuelo Monfort wrote:

On 17/03/2023 19:39, Raphael Hertzog wrote:

On Thu, 16 Mar 2023, Emilio Pozuelo Monfort wrote:

The result is an improved pipeline with better support for both LTS and
ELTS. [1]


Great work Emilio!

It would be nice to have all this properly documented in
https://lts-team.pages.debian.net


Ack, I can add something to the testing section of the development page.


I'm wondering if this new CI environment is meant for all new repositories?

Currently LTS contributors are supposed to follow the following 
documentation:

https://lts-team.pages.debian.net/git-workflow-lts.html

which IIUC is also what was automated in:
https://gitlab.com/freexian/services/deblts-team/debian-lts/-/blob/master/bin/package-operations#L985

i.e. with a local debian/.gitlab-ci.yml relying on:
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
plus optionally disabling some tests.


Should we use that existing setup, or the new CI setup you presented, 
for new LTS packages?


Cheers!
Sylvain

Re: Triage status for a few old packages

[Sylvain Beucler]

Hello Security Team,

On Thu, Apr 13, 2023 at 05:33:15PM +0200, Moritz Muehlenhoff wrote:
> On Wed, Apr 12, 2023 at 10:58:15PM +0200, Salvatore Bonaccorso wrote:
> > > - For python2.7, AFAIU you would be inclined to associate CVEs to that
> > > package more often, for the duration of buster-lts, which would help a 
> > > lot.
> > > On the LTS side we'd like to associate all the past python3.x CVEs to
> > > python2.7 (13 CVEs) and triage them accordingly (so we can easily compare
> > > python2 and python3 status).
> > > Would that be OK?
> > 
> > >From my side no objection on that. If you do not hear a NACK, go ahead
> > with it.
> 
> Yeah, that sounds fine.

Initial CVE association and triage done for python2.7, comparing with
python3.9 and python3.7, thanks.
https://security-tracker.debian.org/tracker/source-package/python2.7


> > > - For gnupg1, we'd like to reference it in
> > > debian-security-support/security-support-limited (or
> > > security-support-endedXX).
> > > Would that be OK?
> > 
> > Inclided to say to add it to security-support-limited. The reference
> > to the release notes might suffice as explanation, or you can be more
> > verbose and reference #982258. It lists reasons for still keeping
> > src:gnupg1 to handle specific usecases.

Merged in security-support-limited, thanks.
https://salsa.debian.org/debian/debian-security-support/-/merge_requests/15


> > - For sqlite, I believe LTS supports it as a dependency of
> > yum > There are also direct use cases of the 'sqlite' CLI: for accessing v2
> > databases, and migrate v2 databases to v3 (AFAICS).
> 
> Ok understand.
> 
> > So I'm more inclined to keep it supported for the duration of buster-lts
> > (package was removed in later dists).
> > What do you think?
> 
> The question is then probably: If kept supported, you would need to
> check each of the sqlite affecting CVEs if they apply really to the
> old code-base. In such a case, add
> 
>   - sqlite 
> 
> and triage it further for buster.

So we can do the same as with python2.7, expect this time the LTS Team
members are the only ones adding the '- sqlite ' entries for
new sqlite3 CVEs.

I can proceed to add such entries for the past CVEs and prepare LTS
procedures to ensure this is done, until the end of buster-lts next
year.

Are you OK with this?

Cheers!
Sylvain Beucler
Debian LTS Team

Re: Triage status for a few old packages

[Sylvain Beucler]

Hello Security Team,

On 01/04/2023 21:31, Salvatore Bonaccorso wrote:

First a disclaimer, this probably needs further discussion, reflects
my current personal knowledge and view on the question, and further
feedback is appreciated by at least one other persion in the Debian
security team doing frequent CVE triage, I have in mind Moritz.


Waiting for other security team members' input, I can clarify a couple 
points and propose a plan for action.



First I confirm that this is intended for LTS only; for ELTS we can just 
triage in the ELTS security tracker almost without interference.



- For python2.7, AFAIU you would be inclined to associate CVEs to that 
package more often, for the duration of buster-lts, which would help a lot.
On the LTS side we'd like to associate all the past python3.x CVEs to 
python2.7 (13 CVEs) and triage them accordingly (so we can easily 
compare python2 and python3 status).

Would that be OK?

- For gnupg1, we'd like to reference it in 
debian-security-support/security-support-limited (or 
security-support-endedXX).

Would that be OK?

- For sqlite, I believe LTS supports it as a dependency of 
yumThere are also direct use cases of the 'sqlite' CLI: for accessing v2 
databases, and migrate v2 databases to v3 (AFAICS).
So I'm more inclined to keep it supported for the duration of buster-lts 
(package was removed in later dists).

What do you think?

Cheers!
Sylvain Beucler
Debian LTS Team

On 01/04/2023 21:31, Salvatore Bonaccorso wrote:

As a general rule I think we can say when incoming CVEs are triaged,
they are done only in context to at most the suites supported by the
main Debian security-tracker, that is, whatever falls out of currently
buster is not looked at. Usually it is worked on, looking at incoming
CVEs, assess them in context of source packages, which are
(potentially) affected in the supported suites (from top down looking,
and might be time-depentend on volunteer time), and then doing
assessments on if something needs a DSA or not.

Consider as well this email an initial reply, as I didn't want to have
your question be unaswered.

On Mon, Mar 20, 2023 at 10:23:57PM +0100, Sylvain Beucler wrote:

Hello Security Team,

There are a few packages that we intend to support in LTS, but whose triage
might be incomplete (missing CVEs).

We'd like to clarify the status of these packages in Debian and, if
additional triage is necessary, check how to best coordinate with you.

We're interested in particular in the following packages:

- python2.7: there are missing CVEs compared to python3.*;
python2.7 was referenced in security-support-limited (2020-11), and marked
obsolete in the bullseye release notes (2020-08), but there has been some
(partial) triage since then.
Example missing CVE: CVE-2022-45061
https://security-tracker.debian.org/tracker/source-package/python2.7
https://security-tracker.debian.org/tracker/source-package/python3.9



From Debian security team view on the supported suites as you noted in

bullseye python2.7 is only supported for building packages, basically
not for running them anymore, #975058. Noteworthy the buster release
notes already did contain:
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#deprecated-components
When python CVEs drop in we usually check the source, and if confident
enough a

- python2.7 

might be added. But I can say we will not consistently do that, given
the amied deprecation of python2.7 in buster, and status from bullseye
on.

This means, as long LTS team has a suite maintained in the Debian
security-tracker itself shipping python2.7 in a semi-supported way,
buster, and there are python2.7 CVEs with non-negligible impact, they
might need to be looked at separately.

I from my side, will try to at least add - python2.7  entries
to facilitate your work specifically on that front.


- gnupg1: there is no new CVE since 2019, but there are very few CVEs
assigned to gnupg2 so maybe it's an oversight.
Example missing CVE: CVE-2022-34903
https://security-tracker.debian.org/tracker/source-package/gnupg1
https://security-tracker.debian.org/tracker/source-package/gnupg2


gnupg1 is by now even in buster mostly irrelevant for any security
sensitive workflows. gnupg1 is basically ignored. It might be the case
they are still relevant for stretch or jessie in ELTS, but if so this
might need to specifically be handled in the ELTS tracker with the
extensions mechanism.

See 
https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#modern-gnupg
in stretch already. I believe you should not really still support it,
in the ELTS suites, but it is defintively out of scope for the
security-tracker supported suites.


- sqlite (v2.8): there's only a single CVE from 2007. Lots of CVEs only
apply to a subset of sqlite3 though, explaining part of the huge difference
between sqlite and sqlite3.
Example missing CVE: CVE-2020-35525
No

Debian LTS and ELTS - February 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- Front Desk (week 9, March half)
  - Mark 6 packages for update
  - Triage or precise triage for 15+ CVEs
  - golang* buster triage/harmonization

- runc (docker.io dependency)
  - New CVE-2023-27561 for the issue I reported last month
  - DLA 3369-1
https://lists.debian.org/debian-lts-announce/2023/03/msg00023.html
  - Fix a couple build issues
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033604

- qemu
  - Re-check for applicable patches in long-standing issues
  - DLA 3362-1
https://lists.debian.org/debian-lts-announce/2023/03/msg00013.html

- xapian-core
  - upload from Debian maintainer, I helped with administrative parts
  - DLA 3355-1
https://lists.debian.org/debian-lts-announce/2023/03/msg00016.html


ELTS

- Front Desk (week 9, March half)
  - Refresh/re-check package transitions, to continue tracking CVEs in
older dists semi-automatically
- Commit related-packages.py pending better inclusion in Debian
  (non-ELTS) security-tracker
  https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/12
  - Associate CVEs from newer, branched 'freerdp*', 'mariadb-*', 'openssl*',
'tcl*' and 'unbound-*' Debian packages to older ELTS packages
  - Mark 5 supported packages for update
  - Triage or precise triage for <10 CVEs

- qemu
  - Drop from task list (too little to do or fix at the moment)


Documentation and tooling

- Follow-up on obsolete but supported packages that may lack active
  CVE triage (such as python2)
  - Check for other occurrences, discard false positives
  - Private discussion for status/goal
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/50
  - Initiate discussion with the Debian Security Team
https://lists.debian.org/debian-lts/2023/03/msg00036.html

- Private discussion on package priority
  - Update internal documentation (freexian.gitlab.io, private)

- Feedback on scripts reorganization (private mailing-list)

- LTS Documentation
  - Development: add note on DLA delay, more info Built-Using
https://lts-team.pages.debian.net/wiki/Development.html
  - TestSuites: qemu: minor clarifications
https://lts-team.pages.debian.net/wiki/TestSuites/qemu.html

- Newcomers help on IRC

- User help: seabios buggy in Buster
  https://lists.debian.org/debian-lts/2023/03/msg00046.html
  
- Monthly meeting (via IRC)
  http://meetbot.debian.net/debian-lts/2023/debian-lts.2023-03-23-13.58.html

-- 
Sylvain Beucler
Debian LTS Team

Re: seabios buggy in Buster

[Sylvain Beucler]

Hi,

On 30/03/2023 11:36, Chris Frey wrote:

I recently tried getting the latest FreeDOS running in qemu.  I had a rough
time getting it going, with the drives being rather unreliable,
both C: and the cdrom.  Even general reboot behaviour was not consistent.

I tracked it down to seabios, from this post:

https://retrocomputing.stackexchange.com/questions/9367/qemu-emulating-ms-dos-cannot-access-cd-rom

I built the Bullseye seabios package (1.14.0) on Buster, and the problems
went away.

Is this something worthwhile to upgrade on LTS?


Probably not. This seems to address an uncommon use case (FreeDOS), but 
this affects a critical component (qemu).


The point of a frozen release is that we don't upgrade a package unless 
there's a serious reason to do so, and extensive non-regression testing 
before doing so :)


If you need the latest FreeDOS with a recent seabios, maybe consider 
upgrading to bullseye?


Cheers!
Sylvain Beucler
Debian LTS Team

Triage status for a few old packages

[Sylvain Beucler]

Hello Security Team,

There are a few packages that we intend to support in LTS, but whose 
triage might be incomplete (missing CVEs).


We'd like to clarify the status of these packages in Debian and, if 
additional triage is necessary, check how to best coordinate with you.


We're interested in particular in the following packages:

- python2.7: there are missing CVEs compared to python3.*;
python2.7 was referenced in security-support-limited (2020-11), and 
marked obsolete in the bullseye release notes (2020-08), but there has 
been some (partial) triage since then.

Example missing CVE: CVE-2022-45061
https://security-tracker.debian.org/tracker/source-package/python2.7
https://security-tracker.debian.org/tracker/source-package/python3.9

- gnupg1: there is no new CVE since 2019, but there are very few CVEs 
assigned to gnupg2 so maybe it's an oversight.

Example missing CVE: CVE-2022-34903
https://security-tracker.debian.org/tracker/source-package/gnupg1
https://security-tracker.debian.org/tracker/source-package/gnupg2

- sqlite (v2.8): there's only a single CVE from 2007. Lots of CVEs only 
apply to a subset of sqlite3 though, explaining part of the huge 
difference between sqlite and sqlite3.

Example missing CVE: CVE-2020-35525
Note: we also seem to miss a few "SQLite in Google Chrome" CVEs in both 
sqlite and sqlite3, which were only linked to chromium, e.g. CVE-2019-13752.

https://security-tracker.debian.org/tracker/source-package/sqlite
https://security-tracker.debian.org/tracker/source-package/sqlite3

(- I had also noted discrepancies in lua5*, but it appears all missing 
CVEs are not-affected and implicitly triaged through non-association.)



Is Debian currently triaging (associating CVEs) for these packages?
(Or are they obsolete somehow?)

If they are not triaged and you do not wish to perform such triage, 
would you mind if we do, and do you have recommendations so as to 
respect each other's workflows?


Cheers!
Sylvain Beucler
Debian LTS Team

Debian LTS and ELTS - February 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- golang-github-opencontainers-selinux
  - Pre-requisite for runc update below
  - DLA 3322-1 
https://lists.debian.org/debian-lts-announce/2023/02/msg00016.html

- runc
  - prepare security update for 4 CVEs
  - identify and coordonate CVE re-introduction with upstream project
https://github.com/opencontainers/runc/issues/3751
  - give time for upstream to react, otherwise will publish a partial update

- apache2
  - review and test other contributor's (Lee) planned update
  - help debug issues with storing package history in Git

- python-werkzeug
  - DLA 3346-1
https://lists.debian.org/debian-lts-announce/2023/02/msg00041.html

- Front Desk (week 49, February half)
  - Triage or precise triage for 5 CVEs
  - Coordinate administrative issue with DLA 3316-1
(not-affected for postgresql < v12)


ELTS

- Help investigate pillow regression causing issue in python-django

- Review missing CVEs in renamed packages with other contributor (Adrian)

- Front Desk (week 49, February half)
  - Mark 7 supported packages for update
  - Associate CVEs from newer, branched emacs*, golang*, php7*,
postgresql*, python3* and ruby* Debian packages to older ELTS
packages (+ send internal note on caveat related to those entries)
  - Triage or precise triage for <10 CVEs


Documentation and tooling

- LTS Documentation 
  - TestSuites: golang: document rdep availability for rebuilds + clarifications
https://lts-team.pages.debian.net/wiki/TestSuites/golang.html
  - TestSuites: autopkgtest: update for buster + clarifications
https://lts-team.pages.debian.net/wiki/TestSuites/autopkgtest.html
  - TestSuites: php: fix syntax
https://lts-team.pages.debian.net/wiki/TestSuites/php.html
  - Force-refresh publication after Salsa runner downtime

- ELTS Documentation (private)
  - information-for-extended-lts-contributors: emphasize common setup
issue with security-tracker ELTS fork

- Newcomers help
  - Report misplaced commit
  - Answer questions on IRC (processes, packages priority)
  - Help identify/source LTS start date for debian-timeline

- Monthly meeting (using Jitsi)


-- 
Sylvain Beucler
Debian LTS Team

Re: Three Apache2 vulnerabilities

[Sylvain Beucler]

Hello Marc,

One LTS contributor (Lee) claimed the package a few days ago, so an 
update is underway.


Apache2 for LTS has multiple sponsors, so it has good priority within 
the work queue.


As for bullseye, an update is planned for the next point release:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029123
("no-dsa" can be misleading)

Cheers!
Sylvain Beucler
Debian LTS Team

On 02/02/2023 08:39, Marc SCHAEFER wrote:

Hello,

CERT-FR considers three new Apache2 vulnerabilities to be of concern [1].

These are:

CVE-2022-37436 [2]
CVE-2022-36760 [3]
CVE-2006-20001 [4]

The first one will modify how clients may apply some security headers if a
malicious backend triggers this bug (some headers will be in the response
body). Ranke as 5.3 MEDIUM.

The second one is specific to mod_proxy_ajp, aka Java/tomcat backend.
Ranked as 9.0 CRITICAL.

The third one is a very old vulnerability in webdav, which is a read of one
byte or buffer head overflow of 1 byte. This is ranked as 7.5 / HIGH.

My personal ranks are: don't care (my backends are not malicious :->), don't
care (I don't run any Java software per policy). The last one bothers me more.

Do you know when this will be fixed in LTS?

The Security tracker [5] tells me that bullseye is not fixed yet either, and
the no-DSA bothers me.

Thank you for looking into this.

[1] https://www.cert.ssi.gouv.fr/avis/CERTFR-2023-AVI-0035/?s=09
[2] https://www.cve.org/CVERecord?id=CVE-2022-37436
[3] https://www.cve.org/CVERecord?id=CVE-2022-36760
[4] https://www.cve.org/CVERecord?id=CVE-2006-20001
[5] https://security-tracker.debian.org/tracker/source-package/apache2

Debian LTS and ELTS - January 2023

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- Front Desk
  - Mark 10 packages for update
- 8 following bullseye 11.6 point release updates
  - Triage or precise triage for 10+ CVEs
  - Standardize/clarify buster-lts triage for golang* packages
(following September and December work)

- tiff
   - Finish backporting patches to buster (started in December)
   - DLA 3278-1
 https://lists.debian.org/debian-lts-announce/2023/01/msg00018.html

- git
  - DLA 3282-1
https://lists.debian.org/debian-lts-announce/2023/01/msg00022.html

- runc
  - Starting checking security issues, packaging strategy and testing
(to be continued in February)


ELTS

- Front Desk
  - Mark 7 supported packages for update
- 4 while reviewing history of newly supported packages in 2023-H1
  - Associate CVEs from newer, branched 'golang*', 'php7*' and 'ruby*'
Debian packages to older ELTS packages
  - Triage or precise triage for ~10 CVEs


Documentation and tooling

- LTS Documentation
  - freexian-lts.gitlab.io (internal/elts): newly-supported-packages:
make commands a little easier to use / copy-paste

- Team exchanges
  - NVidia drivers status
https://lists.debian.org/debian-lts/2023/01/msg5.html
  - Internal discussion on filtering methodology for low-priority
updates
  - Internal discussion on helping security team

- Monthly meeting (via IRC)
  http://meetbot.debian.net/debian-lts/2023/debian-lts.2023-01-26-14.00.html

-- 
Sylvain Beucler
Debian LTS Team

Re: nvidia-graphics-drivers in DLA needed?

[Sylvain Beucler]

Hi,

LTS does support a few non-free packages following sponsors requests, 
such as 'firmware-nonfree' or 'unrar-nonfree'.


Also, the list of supported packages is currently built from curated 
lists of installed packages provided from the sponsors.
One limitation is that the list needs to be refreshed and I believe 
Freexian is currently asking sponsors to provide up-to-date lists of 
packages.
Another limitation is that some related packages are implicitly 
supported, see for instance Markus' ELTS work 
'extra-packages-to-support' about embedded package (private repo).


Consequently it looks like nvidia-graphics-drivers and 
nvidia-graphics-drivers-legacy-390xx can be fixed through LTS as related 
packages (as explained by Markus below), though maybe not with high 
priority. They probably shouldn't be explicitly referenced in 
packages-to-support since there's no direct/paid sponsorship on them.
nvidia-graphics-drivers-legacy-340xx (not 390xx) can't be fixed because 
it isn't supported upstream anymore, we can keep -ing its CVEs.


@Ola I'm not sure what documentation you're referring to that point you 
to a different conclusion. Typically I don't think we forbid non-free 
uploads, but users shouldn't expect us to support them either (as in 
stable).


I realize that this makes nvidia triaging dependent on the LTS 
contributors' collective memory and personal initiative, so maybe this 
should be more formally decided and documented.  I personally don't 
particularly wish to involve myself with non-free packages.  Maybe you 
can coordinate with Markus and/or open a ticket to make sure this 
clarification happen?


Cheers!
Sylvain Beucler
Debian LTS Team

On 28/12/2022 23:45, Ola Lundqvist wrote:

Hi fellow LTS developers

As you can see below I had a question to Markus and he answered with 
very good information.


My question to you all is whether we should add the 
nvidia-graphics-drivers packages to the "packages-to-support" list or if 
we should document this in some other way?
Based on the documentation I had at hand I did not draw the same 
conclusion as Markus did and I think maybe we should change the 
documentation so I could draw that conclusion.


Or have I missed something regarding the documentation we have?

Or is it so that we should in fact not support the 
nvidia-graphics-dirvers packages?


Cheers

// Ola

On Wed, 28 Dec 2022 at 00:22, Markus Koschany <mailto:a...@debian.org>> wrote:


Hi Ola,

Am Dienstag, dem 27.12.2022 um 23:48 +0100 schrieb Ola Lundqvist:
 > Hi Markus
 >
 > When triaging nvidia-graphics-drivers CVEs I realized that you
had added
 > nvidia-graphics-drivers to dla-needed.txt. My understanding is
that packages
 > in non-free are not supported unless explicitly mentioned in
packages-to-
 > support file.
 >
 > The nvidia-graphics-drivers package(s) is not in packages-to-support.
 >
 > So therefore I'm asking whether adding the package was a mistake
or if I have
 > missed something?


I believe nvidia drivers are still supported in LTS because at least
some
nvidia packages are listed in packages-to-support like
nvidia-modprobe or
nvidia-settings. In addition I had uploaded a new
nvidia-graphics-drivers
package back in January 2022 [1] and I think nothing has changed
back then. In
general we even support non-free packages in LTS if the package is quite
important like a driver. Nvidia drivers fits perfectly here. I'm
more reluctant
with leaf packages like otrs2 (because of the non-free Javascript)
but Nvidia
drivers are still important for many users these days. In short you
don't have
to worry about Nvidia drivers in LTS because this is something we try to
support.

[1]
https://lists.debian.org/debian-lts-announce/2022/01/msg00013.html
<https://lists.debian.org/debian-lts-announce/2022/01/msg00013.html>

Debian LTS - December 2022

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- git
  - DLA 3239-1
https://lists.debian.org/debian-lts-announce/2022/12/msg00025.html
  - DLA 3239-2 regression fixing rare crash on armhf architecture
https://lists.debian.org/debian-lts-announce/2022/12/msg00026.html

- tiff
  - start backporting patches to buster

- Miscellaneous triage
  - Drop 2 non-actionable packages
  - Clarify status for 2 pending packages


Documentation and tooling

- LTS documentation
  - Fix multiple links and markup issues

- Monthly meeting (using Jitsi)


-- 
Sylvain Beucler
Debian LTS Team

Re: https://bugs.debian.org/1024932 ceph-base: ceph to root privilege escalation via ceph-crash.service CVE-2022-3650

[Sylvain Beucler]

Hi Thomas,

ceph was added about 1 month ago in the tasks list; I referenced your 
note there:

https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/a9487a265227c3d4181511570bdf61889ce4c8e2

Cheers!
Sylvain Beucler
Debian LTS Team

On 30/11/2022 14:46, Thomas Goirand wrote:
The patch is kind of trivial Python stuff backporting work. Can someone 
take care of it in Buster? I'm currently building the Bullseye backport 
of the fix...

Debian LTS and ELTS - November 2022

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- ffmpeg
  - Update to latest stable 4.1.x
  - Resolve test suite irregular failure upstream
https://trac.ffmpeg.org/ticket/10010
  - DLA 3178-1
https://lists.debian.org/debian-lts-announce/2022/11/msg4.html

- Front Desk
  - Mark 12 packages for update
  - Mark 14 NodeJS packages with bullseye-targeted updates to backport
  - Triage or precise triage for 10+ CVEs
  - Standardize/clarify buster-lts triage for golang* packages:
follow-up fixes for September work
  - qemu: full recheck/update for 2019-2022 postponed CVEs

- phpseclib/php-phpseclib
  - Clarify CVE-2021-30130 status
  - Sync with stable/bullseye maintainer
  - Backport bullseye to import test suite infrastructure + CVE fix
with minimum regression risk; test reverse dependencies
  - DLA 3197-1 phpseclib (1.x)
https://lists.debian.org/debian-lts-announce/2022/11/msg00024.html
  - DLA 3198-1 php-phpseclib (2.x)
https://lists.debian.org/debian-lts-announce/2022/11/msg00025.html

- libarchive
  - Fix 1 CVE triage (CVE-2021-36976)
  - Notify past uploader about possible leak in CVE-2021-31566 fix
(now in ELTS suites)
  - DLA 3202-1
https://lists.debian.org/debian-lts-announce/2022/11/msg00030.html


ELTS

- Front Desk (October/November weeks 2/2)
  - Mark 15 supported packages for update
  - Associate CVEs from newer, branched 'golang*' and 'python3.*'
Debian packages to older ELTS packages
  - Triage or precise triage for 6 CVEs
  - Feedback with LTS Front Desk on common triage
  - qemu: full recheck/update for 2019-2022 postponed CVEs
  - ffmpeg: clean-up/fix past triage


Documentation and tooling

- LTS Documentation
  - Fix broken internal links following page renames
  - asan: reference -static-libasan issue with C++ programs
https://lts-team.pages.debian.net/howtos/lts-Development-Asan.html
  - Test Suites: add instructions for libarchive
https://lts-team.pages.debian.net/wiki/TestSuites/libarchive.html

- Feedback on Salsa CI for buster
  https://lists.debian.org/debian-lts/2022/11/msg00016.html
  https://lists.debian.org/debian-lts/2022/11/msg00022.html

- Answer external clarification request about Debian Security tracker triage
  https://lists.debian.org/debian-security/2022/11/msg2.html

- New contributor help (via IRC)

- Monthly meeting (via IRC)
  http://meetbot.debian.net/debian-lts/2022/debian-lts.2022-11-24-13.59.html

-- 
Sylvain Beucler
Debian LTS Team

Re: Using Salsa-CI as pre-upload QA for Bullseye and Buster uploads: Lintian and Piuparts

[Sylvain Beucler]

Hi,

Re-trying the Salsa CI again with the simple libarchive/buster package 
(after getting frustrated with mailman/stretch errors a few months ago), 
I note that:


- the piuparts job was flacky and needed a restart

- the test-crossbuild-arm64 doesn't seem compatible with buster (using 
the new 'apt-get satisfy' command, for reasons I can't debug because of 
a redacted "collapsed multi-line command" even in the raw log;
maybe it could written in a buster-compatible way, or otherwise just 
dropped for buster because it's confusing.


My $0.02 :)

Cheers!
Sylvain Beucler
Debian LTS Team

On 14/11/2022 19:08, Abhijith PA wrote:

On 14/11/22 01:56 PM, Sylvain Beucler wrote:

On 12/11/2022 22:31, Otto Kekäläinen wrote:

I was wondering how common is it for DDs to use Salsa-CI while doing
quality assurance prior to Bullseye and Buster uploads?


I personally tend to run initial builds and dep-8 tests locally, because
when they fail, I have to re-run them manually to properly debug and fix the
failures anyway.
(not to mention additional manual tests)


Same for me.


Also I do my LTS (security) work in a VM without access to my Debian
credentials (gpg, ssh) so I can e.g. run various vulnerability PoCs and
exploits with a reasonable peace of mind; which makes it inconvenient to
push to Salsa.


I have custom(tools to share clipboard from host etc) live image
that I run on QEMU (via libvirt commands) for testing PoCs, exploits
and final build.

--abhijith

Re: Using Salsa-CI as pre-upload QA for Bullseye and Buster uploads: Lintian and Piuparts

[Sylvain Beucler]

Hi!

On 12/11/2022 22:31, Otto Kekäläinen wrote:

I was wondering how common is it for DDs to use Salsa-CI while doing
quality assurance prior to Bullseye and Buster uploads?


I personally tend to run initial builds and dep-8 tests locally, because 
when they fail, I have to re-run them manually to properly debug and fix 
the failures anyway.

(not to mention additional manual tests)

Also I do my LTS (security) work in a VM without access to my Debian 
credentials (gpg, ssh) so I can e.g. run various vulnerability PoCs and 
exploits with a reasonable peace of mind; which makes it inconvenient to 
push to Salsa.


I'd be interested in knowing how other LTS contributors handle those 
issues :)


Cheers!
Sylvain Beucler
Debian LTS Team

Re: Pre-creating Git repos in salsa.d.o/lts-team/packages/ - or not?

[Sylvain Beucler]

Hi,

On 07/11/2022 19:08, Anton Gladky wrote:

as you know one of our goals is to keep the git-history of all {E,L}TS
uploads. Some semi-automatic repo creation scripts are in a test phase
to ease this process. I have created some repos and
imported the last available security versions of packages into that.

Sure, if the maintainer of the particular package allows to push security
updates of {E,L}TS process, feel free to do it! Just drop the repo and
change the link in the VCS.


Point is: if the LTS repo already exists, I assume there was a conscious 
decision /not/ to host it in the maintainer's repo. (Otherwise every 
contributor would ask the maintainer every time they prepare an upload.)


I think creating the repo is the uploader's responsibility, not the 
front-desk's or coordinator's.


Cheers!
Sylvain

Pre-creating Git repos in salsa.d.o/lts-team/packages/ - or not?

[Sylvain Beucler]

Hi,

I see that a few repositories in salsa.d.o/lts-team/packages/ were 
created for packages that haven't been claimed yet.

https://salsa.debian.org/lts-team/packages?sort=created_desc

(I'm not sure who/what did it exactly, there's activity from 
"Bot-LTS-package", which may be the 'package-operations' script, then 
manual activity from Anton.)


That means the repo was created and imported before there was a chance 
to discuss with the package maintainers whether they want to host the 
(E)LTS branch there or at another location (such as, their own salsa repo).


I think this adds confusion. When I check the "VCS" field in 
dla-needed.txt, I assume this is the preferred repository for 
development, following an explicit decision from a previous contributor 
who worked on the package - not the result of semi-automation.

Thoughts?

Cheers!
Sylvain

Debian LTS and ELTS - October 2022

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- nodejs
  - Finish work started in September (cf. previous report)
  - DLA-3137-1
https://lists.debian.org/debian-lts-announce/2022/10/msg6.html

- ruby-nekorigi & rexical (1 common CVE)
  - DLA 3149-1
https://lists.debian.org/debian-lts-announce/2022/10/msg00018.html
  - DLA 3150-1
https://lists.debian.org/debian-lts-announce/2022/10/msg00019.html

- bluez
  - Clarify/precise CVE triage
  - Sync past fixes from stretch DLAs to buster, fix new issues
  - Testing on physical Bluetooth chip
  - DLA-3157-1
https://lists.debian.org/debian-lts-announce/2022/10/msg00026.html


ELTS

- Front Desk (October/November week 1/2)
  - Mark 6 supported packages for update
  - Associate CVEs from newer, branched 'python3.*' and 'php*' Debian
packages to older ELTS packages
  - Contribute to main Debian security-tracker triage for several CVEs


Documentation and tooling

- LTS Documentation
  - Enable e-mail notifications for lts-team.pages.debian.net changes
  - Development procedures: update stretch->buster
https://lts-team.pages.debian.net/wiki/LTS-Development.html
(now https://lts-team.pages.debian.net/wiki/Development.html)
  - Test suite: minor fixes
https://lts-team.pages.debian.net/wiki/TestSuites/autopkgtest.html
https://lts-team.pages.debian.net/wiki/TestSuites/ffmpeg.html
https://lts-team.pages.debian.net/wiki/TestSuites/nodejs.html

- LTS/ELTS git repositories list (internal/private)
  - Fix a few locations (mariadb) and branch name (exim4)

- Answer call for review/testing about glibc
  https://lists.debian.org/debian-lts/2022/10/msg00022.html
  https://lists.debian.org/debian-lts/2022/10/msg00031.html

- Answer LTS Thunderbird user question
  https://lists.debian.org/debian-lts/2022/10/msg00021.html

- Monthly meeting (video/Jitsi)


-- 
Sylvain Beucler
Debian LTS Team

Re: Call for testing: glibc update for buster

[Sylvain Beucler]

Hi,

On 17/10/2022 10:00, Helmut Grohne wrote:

On Wed, Oct 12, 2022 at 03:45:11PM +0200, Sylvain Beucler wrote:

I'll give it some testing on my buster system.


Thank you. I take the absense of a further reponse as "nothing broke".


Right, although I was kinda waiting for your input on other points 
rather than answer to myself on this one :)



- a methodology point: if there's some uncertainty on CVE-2016-10228 (note:
which is a 2020 fix really), that neither secteam nor the maintainers
decided to fix in other Debian dists, maybe it's not worth the risk to fix
it in LTS.
I read your note that other distros (ubuntu, redhat) did so though,
contacting the maintainers could help evaluate the risk better.


Yeah. I'm fixing quite a number of issues that were not previously
considered. Even though these were non-trivial to fix, I believe that we
should fix them. Leaving them as is would mean that character conversion
involving untrusted inputs is not supported at all. Seems like a hard
sell, right?


Depends on the levels of risks involved (local CPU DoS vs. possible 
regression), but again the maintainers would better know what to answer.


Cheers!
Sylvain Beucler
Debian LTS Team

Re: Call for testing: glibc update for buster

[Sylvain Beucler]

Hi,

I'll give it some testing on my buster system.

A couple things I noticed right now:

- dist in debian/changelog should be 'buster-security' (not 'buster')

- debdiff|diffstat shows spurious '.pc' work files from quilt
(plus a change in a patches/README which maybe adds more noise than it 
helps in a security upload, but that's a matter of taste)


- a methodology point: if there's some uncertainty on CVE-2016-10228 
(note: which is a 2020 fix really), that neither secteam nor the 
maintainers decided to fix in other Debian dists, maybe it's not worth 
the risk to fix it in LTS.
I read your note that other distros (ubuntu, redhat) did so though, 
contacting the maintainers could help evaluate the risk better.


Cheers!
Sylvain

On 11/10/2022 15:25, Helmut Grohne wrote:

I've prepared a LTS update for glibc and seek people testing it. Builds
for amd64 and armfh as well as a .debdiff are available from
http://subdivi.de/~helmut/glibc_lts.

I plan to fix no less than 14 CVEs. Those mostly fall into one of the
following categories:
  * 4 * iconv
  * 2 * unix sockets
  * setuid environment filtering
  * getcwd
  * glob
  * memcpy on armhf
  * mq_notify
  * sinl
  * wordexp
  * nscd
Please refer to debian/changelog and the respective patches for details.

If you happen to have applications covering any of these, feedback is
welcome.

Beware that this update changes two private glibc symbols for fixing
CVE-2016-10228. These symbols are used for testing the change via
iconv_prog, which happens to not be installed into a binary package.
I've not located any uses in any other glibc library. As a result, I
believe that these symbol changes to be harmless even though Aurelien
Jarno cautioned about it. My judgement is partially confirmed by RedHat
and Canonical shipping these symbol changes in their security updates.
On the flip side, I'm observing a number of unexpected references to one
symbol that did change prototype, see
https://codesearch.debian.net/search?q=__gconv_open&literal=1. Most of
these uses are broken since bullseye, so I hope that they're all dead
code. More eyeballs appreciated.

You see this is glibc, so I'd rather give it more testing than brick
user systems.

Please Cc me in replies.

Re: Cannot read newsgroups with new Thunderbird

[Sylvain Beucler]

Hi,

I don't use the NNTP feature myself, but since we're following the 
Thunderbird ESR releases, there's a high chance that it's a bug in 
upstream Thunderbird.


Unless the same works in other Debian dists (bullseye or bookworm, who 
also upgraded to 102esr), I'd suggest you look at the official 
Thunderbird contact points.


Cheers!
Sylvain Beucler
Debian LTS Team

On 05/10/2022 15:17, Miroslav Skoric wrote:
After a recent Thunderbird upgrade in Buster (from version 91-something 
to 101-something, or like), it stopped handling newsgroups properly 
(where the source is News Server (NNTP) on the same machine, and there 
nothing was changed/upgraded).


To be precise, Thunderbird now seems downloading new messages from the 
NNTP server, then shows the new number of messages in the folder pane, 
but displays an empty content in the message pane, i.e. Subject and From 
columns are empty, while Date column is filled with 1/1/70 - for all 
news messages that arrived since the Thunderbird upgrade.


Btw, handling personal emails (from the local POP Mail Server) is ok.

Any idea?

Debian LTS and ELTS - September 2022

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- Front Desk
  - Standardize/clarify buster-lts triage for golang* packages
  - Mark 10 packages for update
  - Triage or precise triage for multiple CVEs
  - Guide two non-team contributors (bzip2 and pcs)
https://lists.debian.org/debian-lts/2022/09/msg00042.html
https://lists.debian.org/debian-lts/2022/09/msg00060.html

- nodejs
  - Newly supported package / ecosystem
  - Reference CVEs information and patches, precise buster triage
  - Prepare DLA (in progress), backport patches
  - Fix test-suite, initiate documentation (see below)


ELTS

- Front Desk
  - Mark 3 supported packages for update
  - Associate CVEs from newer separate branched 'golang-1.x' packages
to ELTS' 'golang'


Documentation and tooling

- LTS Documentation
  - Clarify package claims and front-desk bypass procedures

https://lts-team.pages.debian.net/wiki/LTS-Development.html#claim-the-issue-in-the-security-tracker-in-dla-needed-txt
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/49
  - Unify front-desk docs (public and private), clarify role attributions

https://lts-team.pages.debian.net/wiki/LTS-Development.html#front-desk-duties
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/48
  - Discuss triage during stable->oldstable harmonization
https://lists.debian.org/debian-lts/2022/09/msg00072.html
  - nodejs testing procedures
https://lts-team.pages.debian.net/wiki/TestSuites/nodejs.html
  - Internal doc: reference bin/review-update-needed from the main
security-tracker, similar to a new tool

- Fixes to new (private) bin/package-operations front-desk tooling

- IRC meeting
  http://meetbot.debian.net/debian-lts/2022/debian-lts.2022-09-22-13.58.html


-- 
Sylvain Beucler
Debian LTS Team

Re: What do do with bullseye minor issues?

[Sylvain Beucler]

Hi,

On 29/09/2022 09:09, Emilio Pozuelo Monfort wrote:

On 28/09/2022 23:54, Ola Lundqvist wrote:

Took me a month to get down here in the email backlog. I think your
reasoning makes sense.
I have added the following to the LTS/Development page.

"If a CVE has been fixed in Debian Stable it should, in general, be fixed
in LTS as well, or marked as ignored. It does not make sense to have such
CVEs marked as postponed or no-dsa since either the Debian Security 
team or

the maintainer have decided that it was worth fixing."
Please update that page if you think I was unclear or wrong.


Note: the documentation was moved away from the wiki.


I don't think that's correct. Say for example:

Package foo has two CVEs:

- CVE-2022-1234 of high severity, affecting stable
- CVE-2022-5678 of minor severity, affecting stable and oldstable

The sec-team fixes both.

Now, what do we do? According to your reasoning, we should either do a 
DLA to fix a single minor issue, or mark it as ignored. I think marking 
it as postponed is the correct course of action here.


That would be a rare corner case in the "Issues postponed for 
, but already fixed in  via DSA or point releases (to 
be fixed or )" report in lts-cve-triage.py, which I've never 
seen happen so far.


Ola is basically documenting that report in the documentation, maybe in 
a too coercive phrasing.


Such as CVE would keep being reported until fixed (we can live with 
that). But since we do not time-limit such a  issue there's a 
chance that the "minor" CVE remains unfixed forever, so maybe it's good 
to fix it right away nonetheless.


I can think of similar situations when a maintainer fixes a minor issue 
through a point release. It could be fixed or postponed, but there's no 
need to ignore it.
 would be for e.g. a minor issue with invasive, 
risky-to-backport patch.  There's no need to ignore it indeed, but 
that's a possibility.


However, after a point-release, I believe leaving it  
indefinitely doesn't make sense.  We know whether we'll fix it like 
stable, or never will (ignored).  Hence the report and Ola's recommendation.



Note that all this is usually not decided during the first-pass 
triaging, but later on, after a fix landed in stable.


Cheers!
Sylvain

Re: Accepted pcs 0.10.1-2+deb10u1 (source) into oldstable

[Sylvain Beucler]

Hello,

On 14/09/2022 22:43, Valentin Vidic wrote:

On Wed, Sep 14, 2022 at 06:46:47PM +0200, Sylvain Beucler wrote:

Thank you for claiming 'pcs' in dla-needed.txt and uploading a fixed
version.

LTS uploads follow a procedure which notably involves reserving a DLA in the
security tracker and sending announcements to the mailing list and website,
see:
https://lts-team.pages.debian.net/wiki/LTS-Development.html

Note that uploads are not validated (provided you're DD) and are immediately
available to the end users.

I can handle this administrative part of the upload (announcement text would
be appreciated), but first I'm coordinating with you: do you have further
work to do, are you waiting for us to check/review something?


Hi and sorry about that. I was planning to follow the DLA procedure but
ran out of time lately. The description from stable can probably be
reused here:

A security issue was discovered in pcs, a corosync and pacemaker
configuration tool:

  * CVE-2022-1049
  
It was discovered that expired accounts were still able to login via

PAM.

For Debian 10 "Buster", the problem has been fixed in version
0.10.1-2+deb10u1.

Let me know if you will send this out or I should give it a try?


You can certainly give it a try if you have the time.
The description adapted from the DSA sounds good.

Feel free to ask here or at #debian-lts if you have further questions.

Cheers!
Sylvain Beucler
Debian LTS Team

Re: Accepted pcs 0.10.1-2+deb10u1 (source) into oldstable

[Sylvain Beucler]

Hello Valentin,

Thank you for claiming 'pcs' in dla-needed.txt and uploading a fixed 
version.


LTS uploads follow a procedure which notably involves reserving a DLA in 
the security tracker and sending announcements to the mailing list and 
website, see:

https://lts-team.pages.debian.net/wiki/LTS-Development.html

Note that uploads are not validated (provided you're DD) and are 
immediately available to the end users.


I can handle this administrative part of the upload (announcement text 
would be appreciated), but first I'm coordinating with you: do you have 
further work to do, are you waiting for us to check/review something?


Cheers!
Sylvain Beucler
Debian LTS Team

On 12/09/2022 00:50, Debian FTP Masters wrote:

Format: 1.8
Date: Sun, 04 Sep 2022 21:55:16 +0200
Source: pcs
Architecture: source
Version: 0.10.1-2+deb10u1
Distribution: buster-security
Urgency: high
Maintainer: Debian HA Maintainers 

Changed-By: Valentin Vidic 
Changes:
  pcs (0.10.1-2+deb10u1) buster-security; urgency=high
  .
* d/patches: add fix for CVE-2022-1049
Checksums-Sha1:
  256edea0145842422958382f44d4d6e5041013bf 2192 pcs_0.10.1-2+deb10u1.dsc
  e933ccad637141fc4814890d82c5d274cee45b32 1543718 pcs_0.10.1.orig.tar.gz
  6da49f52e5a32e9398f2b716ca655132c2feff5f 166556 
pcs_0.10.1-2+deb10u1.debian.tar.xz
  beb6e956ab70b02402c76d1b7b39e4bfed434078 6923 
pcs_0.10.1-2+deb10u1_source.buildinfo
Checksums-Sha256:
  016832a8dadc7330a43d0f75aa538ffea62e09506220e5ef8dc56495e7239764 2192 
pcs_0.10.1-2+deb10u1.dsc
  61d36fc96c05a4724b76f45216a483e514c9da5b486ba77e906ae45722592cf2 1543718 
pcs_0.10.1.orig.tar.gz
  c621dc384298849aa990cc027712f9a1d6eb9b14c557914e4273ad2b52beadd9 166556 
pcs_0.10.1-2+deb10u1.debian.tar.xz
  8aea519fc77163d2951fc845a9e4bd59d35e95024a53b06c600fd2e07d2d728c 6923 
pcs_0.10.1-2+deb10u1_source.buildinfo
Files:
  9222bc71db53999c37ce1c27d36ceb68 2192 admin optional pcs_0.10.1-2+deb10u1.dsc
  4c7af40096b89752e7fdcea636e9b8b9 1543718 admin optional pcs_0.10.1.orig.tar.gz
  17daac52a88b60e4293e920b59d9c6d7 166556 admin optional 
pcs_0.10.1-2+deb10u1.debian.tar.xz
  284b0d649f7934bf03fc12f5ec43250d 6923 admin optional 
pcs_0.10.1-2+deb10u1_source.buildinfo

Re: Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1

[Sylvain Beucler]

Hi,

IIUC this is about fixing 2 non-security bugs, that were introduced 
prior to buster's initial release.


I personally don't think this fits the LTS project scope.
Maybe other LTS members will have a different opinion.

Cheers!
Sylvain Beucler
Debian LTS Team

On 13/09/2022 15:27, Santiago R.R. wrote:

El 10/09/22 a las 19:11, Adam D. Barratt escribió:

On Wed, 2020-05-27 at 11:56 +0200, Santiago R.R. wrote:

Since 1.0.6-9, bzip2 was built without the -D_FILE_OFFSET_BITS=64
CPPFLAG, and so it's not able to handle > 2GB files in 32-bit archs.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557

I've uploaded a fixed version to unstable yesterday. It would be
great
to fix it also in buster. Please, consider the attached debdiff.
Would it be OK for you to upload it?



Apologies for apparently letting this sit unanswered. (FTR there was a
reply from a non-SRM member 18 months ago.)


And I am sorry I missed that answer.



The final point release for buster has now happened, so any further
updates to packages in buster will need to be handled via LTS. I'm
therefore going to close this request now.

[snip]

I am forwarding this to the LTS folks, so they can decide about this
change.

Re: node-thenify

[Sylvain Beucler]

Hi,

If sponsored packages are already handled, and we have time to fix this 
package, and I think we can fix it.


I think we need to evaluate a package's usage only when fixing is 
problematic (time constraints, backport issues, uncooperative 
upstream...). Package usage would then be used among other elements to 
make a decision about the supporting the package further.


That doesn't appear to be the case here, so I'll add it to dla-needed.txt.

Cheers!
Sylvain

On 09/09/2022 23:45, Ola Lundqvist wrote:

Hi follow LTS contributors

It is this kind of question again. "Is it worth it?".

We have CVE-2020-7677 on node-thenify.

According to popcorn we have three installations. That is of course a 
lower end number since popcorn only counts the popcorn users, but anyway 
it indicates that the installation number is really low. It is in fact 
the lowest popcorn score I have seen so far.


Then about the vulnerability itself. It is an arbitrary code execution, 
but it is on the client side, and the user have get some code injected 
into it that is passed to this function. This means you have to find 
some other code that use this functionality and in some way pass it 
through. It can be done but the likelihood is lower.


Further I can see that node-* packages were unsupported in stretch. They 
seem to be in buster however.


Quite a lot of node-* packages have fairly severe issues declared as 
minor issues. I could not find any arbitrary code execution 
vulnerabilities though.


So my question is, should we fix node-thenify?

I guess so but I want to raise the question.

Re: Updating OpenStack compute (aka src:nova) in Buster

[Sylvain Beucler]

Hi Thomas,

To answer the second part of your e-mail:
> How to proceed? Can I simply upload the normal way? IS there a 3rd
> party peer reviewing accepting / rejecting uploads for LTS?

While LTS is mostly handled by members of the LTS Team, any DD can
contribute directly; we have a few maintainers who want to handle the
upload and/or want to review any changes in their packages:
https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/packages/lts-do-call-me

The steps to handle the upload are described at:
https://lts-team.pages.debian.net/wiki/LTS-Development.html and of
course joint work is possible (e.g. delegate the announcement to the
LTS team).

Last, you can contribute to LTS-specific documentation, e.g.:
https://lts-team.pages.debian.net/wiki/TestSuites/OpenStack.html

How would you like to handle future OpenStack-related LTS uploads?

Cheers!
Sylvain

On Mon, Sep 12, 2022 at 07:14:05AM +0200, Anton Gladky wrote:
> Hi Thomas,
> 
> thanks for the note. I have added the package into the data/dla_needed.txt
> with
> the corresponding message. So, somebody will take care of it.
> 
> 
> Am So., 11. Sept. 2022 um 12:51 Uhr schrieb Thomas Goirand  >:
> 
> > Hi,
> >
> > In the OpenStack team git, there are updates for nova 2:18.1.0-6+deb10u1
> > (CVE-2019-14433/ OSSA-2019-003). Can someone pick it up and upload it to
> > Buster? It was never accepted in Buster due to the difficulties
> > communicating with the Stable release team (too slow response, etc. that
> > leads to /me giving up...). Though IMO, it'd be a very good candidate
> > for buster LTS.
> >
> > The latest Buster version is in the debian/rocky branch at:
> > https://salsa.debian.org/openstack-team/services/nova/
> >
> > How to proceed? Can I simply upload the normal way? IS there a 3rd party
> > peer reviewing accepting / rejecting uploads for LTS?

Debian LTS - August 2022

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- Coordinate update of unsupported packages list for buster
  https://lists.debian.org/debian-lts/2022/08/msg1.html
  https://salsa.debian.org/debian/debian-security-support/

- Unplanned triage/coordination
  - qemu: coordinate pending update from security team and work from
abhijith that got untracked in the buster transition
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007931#10
  - librecad: follow-up on possible mistriage
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010349#15
  - gst-plugins-good1.0: announce DLA from non-team contributor
https://lists.debian.org/debian-lts-announce/2022/08/msg1.html
  
- exim4
  - DLA 3082-1
https://lists.debian.org/debian-lts-announce/2022/08/msg00014.html


Documentation and tooling

- LTS documentation
  - Add link to PGP-based approvals for mailing lists
Restore table of contents

https://lts-team.pages.debian.net/wiki/LTS-Development.html#announce-the-update
  - Add copyright information for TestSuites pages
Sync test suites changes made during migration
Remove duplicate and fix filename typo
https://lts-team.pages.debian.net/wiki/LTS-TestSuites.html

- LTS/find-work
  - re-introduce packages sort by priority (sponsors funding) for buster
  - notify about possibly outdated priority information

- New weekly information report: internal discussion on how to present
  and handle outstanding package updates

- Monthly meeting (using Jitsi)


-- 
Sylvain Beucler
Debian LTS Team

Re: Accepted webkit2gtk 2.36.7-1~deb10u1 (source) into oldstable

[Sylvain Beucler]

Hi all,

On 30/08/2022 07:38, Carsten Schoenert wrote:

Hello Anton,

Am 29.08.22 um 22:28 schrieb Anton Gladky:

Hi Carsten,

thanks for update! As the buster is now in LTS hands, would you want
us to release a DLA?


sure, I've somehow forgotten that Buster is now LTS handled.

In the past Emilio did that job to take care about the releasing TB for 
LTS.


Emilio, while you're at it I saw another webkit2gtk buster update from 
Alberto (thanks!) 2 days ago;

not sure if you had already planned to announce a DLA for it like last time?

If you're busy let me know and I'll handle it.

Cheers!
Sylvain

Re: EOL candidates for security-support-ended.deb10 (recap)

[Sylvain Beucler]

Hi Holger,

On 12/08/2022 14:06, Holger Levsen wrote:

On Thu, Aug 11, 2022 at 02:26:09PM +0200, Emilio Pozuelo Monfort wrote:

I see those changes were applied in the master branch. Should they be
backported to the buster branch, with an eventual upload / DLA?


yes, I have uploading debian-security-support to buster for the last
point release on my agenda and will do that upload as needed.

Sylvain, regarding the master branch changes: a.) thank you! b.) do you have
any more planned "now" or should I upload to unstable as it is now?


I have nothing planned for the immediate future, and the discussion 
seems to have reached consensus, so I think it's good for upload :)


Cheers!
Sylvain Beucler
Debian LTS Team

Re: EOL candidates for security-support-ended.deb10 (recap)

[Sylvain Beucler]

Hi,

On 10/08/2022 11:47, Emilio Pozuelo Monfort wrote:

On 09/08/2022 19:04, Sylvain Beucler wrote:
Here's a little recap for security-support-ended.deb9 -> deb10 
evaluation, following our discussion, also including dropped entries 
for completeness/transparency:



Supported again in buster:
- ansible
- chromium


chromium was already EOL'd in buster by the Security Team:

https://lists.debian.org/debian-security-announce/2022/msg00012.html

We should keep it unsupported, I'd say.


Thanks, it wasn't marked unsupported in security-support-ended.deb10, so 
I assumed support was still ongoing (I should have perused the latest DSAs).


It now is referenced:
https://salsa.debian.org/debian/debian-security-support/-/commit/4ae91af1a7f8bd317e6e24ffcf6ed22fbc6cccb8

This appears to be the only missing package
$ grep 'discontinued' -r webwml/english/security/202[12]

Cheers!
Sylvain Beucler
Debian LTS Team

Re: EOL candidates for security-support-ended.deb10 (recap)

[Sylvain Beucler]

Hi,

Here's a little recap for security-support-ended.deb9 -> deb10 
evaluation, following our discussion, also including dropped entries for 
completeness/transparency:



Supported again in buster:
- ansible
- chromium
- keystone [openstack]
- node-.*  <-- important
- nodejs   <-- important
- pdns-recursor
- tor
- unbound

EOL'd as in stretch:
- ckeditor3
- gpac
- libspring-java [to address in stable/testing too]

Already EOL'd for buster:
- libperlspeak-perl
- xen

Removed from buster:
- guacamole-client
- jasperreports
- mongodb
- mysql-connector-java
- nasm-mozilla
- nodejs-mozilla
- reel
- tomcat6


https://salsa.debian.org/debian/debian-security-support/-/blob/master/security-support-ended.deb9
https://salsa.debian.org/debian/debian-security-support/-/blob/master/security-support-ended.deb10

Cheers!
Sylvain Beucler
Debian LTS Team

Re: gst-plugins-good1.0/1.14.4-1+deb10u2 for DLA

[Sylvain Beucler]

Hi,

Thanks for the heads-up. I'll make the announcement.

Cheers!
Sylvain Beucler
Debian LTS Team

On 09/08/2022 14:07, Salvatore Bonaccorso wrote:

Hi LTS team members!

The maintainer for gst-plugins-good1.0 uploaded for buster-security an
update to address current CVEs. I have thus added the package to
dla-needed list for making sure a DLA release happens.

Can someone of you please pick it up for a DLA release once the
packages are built?

Regards,
Salvatore

Re: EOL candidates for security-support-ended.deb10 (libspring-java support)

[Sylvain Beucler]

Hello Moritz,

On 05/08/2022 11:59, Moritz Mühlenhoff wrote:

Am Wed, Aug 03, 2022 at 11:54:28AM +0200 schrieb Sylvain Beucler:

I think the following stretch EOL entries also apply to buster, because the
rationale still applies to the buster versions:
- libspring-java https://lists.debian.org/debian-lts/2021/12/msg8.html


For Spring we need a more general solution, it's not only becoming
a problem when it reaches LTS, but it already a problem in testing.

Upstream (VmWare) hardly discloses any information on security issues
other than telling the version to update to. That bundled with the fact
that even the versions in unstable (4.3) are now outside the supported
range by upstream...


Thanks for your input.

(E)LTS needs to identify unsupportable packages, so that e.g. Freexian 
doesn't sell support contracts for those, hence why we need to mark this 
explicitly and early in debian-security-support.


I believe it is within the scope of LTS to help fix such issues more 
generally / at the source, so we could help.  Do you have a strategy in 
mind wrt libspring-java in Debian?
(for testing, in the link above Markus mentionned referencing it in the 
release notes on limitations in security support)


Cheers!
Sylvain Beucler
Debian LTS Team

Re: EOL candidates for security-support-ended.deb10 (OpenStack support)

[Sylvain Beucler]

Hi,

On Wed, Aug 03, 2022 at 11:54:28AM +0200, Sylvain Beucler wrote:
> OpenStack: we tend not to support openstack beyond upstream's support

My statement was influenced by the OpenStack 2020 EOL in jessie:
https://salsa.debian.org/debian/debian-security-support/-/merge_requests/3
"Jessie lost support fom upstream just a few weeks after the release."
 (https://lists.debian.org/debian-lts/2015/11/msg00024.html)
based on a 2015 conversation with zigo, which evidently is obsolete :)


On Thu, Aug 04, 2022 at 12:17:36AM +0200, Thomas Goirand wrote:
> All packages contain unit test at build time, so it's kind of safe to
> backport patches. If needed, I can do a setup from scratch if needed.

Thanks for all your inputs.  We would certainly welcome instructions
on how to setup a testing OpenStack environment for LTS updates, which
could be documented at https://wiki.debian.org/LTS/TestSuites
Is that what you offered?


On Sat, Aug 06, 2022 at 11:10:00AM +0200, Thomas Goirand wrote:
> If we take this decision, I'd like to announce it on the
> openstack-discuss list, so let's make it clear what route we're
> taking.

As pochu mentioned, we normally support packages in LTS unless there's
a solid reason /not/ to, and reading this conversation we appear to be
in capacity of supporting OpenStack Rocky packages in buster LTS.


Cheers!
Sylvain Beucler
Debian LTS Team

EOL candidates for security-support-ended.deb10

[Sylvain Beucler]

Hi,

I think the following stretch EOL entries also apply to buster, because 
the rationale still applies to the buster versions:

- ckeditor3 https://lists.debian.org/debian-lts/2022/05/msg00060.html
- gpac https://lists.debian.org/debian-lts/2022/04/msg8.html
- libspring-java https://lists.debian.org/debian-lts/2021/12/msg8.html


This one I'm unsure: Markus, does this apply to a particular ansible 
version, or only stretch's?

- ansible Lack of an effective test suite makes proper support impossible


OpenStack: we tend not to support openstack beyond upstream's support, 
but I'm having a hard time associating the components version with 
OpenStack's major version; possibly other openstack packages (horizon, 
manila, neutron...) are concerned; see also 
https://access.redhat.com/support/policy/updates/openstack/platform/ ; 
if somebody is more familiar with openstack, input would be appreciated :)

- keystone https://lists.debian.org/debian-lts/2020/05/msg00011.html


What do you think?

Cheers!
Sylvain

Debian LTS and ELTS - July 2022

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

Note: LTS was inactive during July, as stretch moved to ELTS, but
buster remained under standard Debian security support until August.

- front-desk / buster preparation
  - data/dla-needed.txt: reference workflow during buster transition (July)
  - data/dla-needed.txt: warn about conflict with proposed-updates (August)
  - ffmpeg: clean-up buster status (reference CVEs fixed by DSA-5126-1)
  - php: identify patches for CVE-2022-31625 and CVE-2022-31626
  - slurm-llnl: discuss EOL status
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/39


ELTS

- front-desk
  - Mark 8 supported packages for update
  - Associate CVEs with 7 related/renamed supported packages
  - Set vulnerability status for 6 CVEs, add information to others
  - Report webkit* support limitations


Documentation and tooling

- Discussions
  - Rationale on lts-cve-triage.py "to be fixed or " recommendation
https://lists.debian.org/debian-lts/2022/07/msg00036.html
  - Decide what to do with the  CVEs: contribute opinion
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/38

- LTS documentation: fix a couple migration issues

- IRC meeting

-- 
Sylvain Beucler
Debian LTS Team

Re: What do do with bullseye minor issues?

[Sylvain Beucler]

Hi,

On 14/07/2022 23:49, Ola Lundqvist wrote:

During my front desk work I have now got down to the CVEs for buster
that are "postponed".
The triage script suggests me to "ignore" or "fix".

You mean this particular section:
"Issues postponed for , but already fixed in  via DSA 
or point releases (to be fixed or ):"


There seem to be a misunderstanding between minor issues /in general/ 
(Anton's new ticket/discussion), and these very specific CVEs that are 
/already fixed/ in stable.


Since they are /already fixed/ in stable, we should either follow suit 
and fix them promptly in oldstable (for consistency with the maintainer 
and secteam's decision), or mark them  explaining why we won't. 
Keeping them  or  doesn't make sense, hence why the 
script reports it.

More info and rationale at:
https://lists.debian.org/debian-lts/2022/04/msg00011.html

Also let's note that "minor" in the tracker means 
"non-critical/non-urgent" (and not "trivial/unimportant"), i.e. not 
requiring active tracking and/or NMU from secteam (they leave it to the 
maintainer).



For minor issues /in general/, there's Anton's ticket/discussion:
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/38
which AFAIU addresses the opposite issue (fixing  that are /not 
fixed/ in stable).



In short, I believe the recommendation from lts-cve-triage.py is right.

Cheers!
Sylvain

Debian LTS - June 2022

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- mailman
  - Locate upstream patches
  - DLA-3049-1
https://lists.debian.org/debian-lts-announce/2022/06/msg00011.html

- vlc
  - Follow upstream stable branch, as in buster
  - DLA-3050-1
https://lists.debian.org/debian-lts-announce/2022/06/msg00012.html

- dpdk
  - Locate upstream patches
  - Drop update: stretch not-affected by all CVEs

- ntfs-3g
  - DLA-3055-1
https://lists.debian.org/debian-lts-announce/2022/06/msg00017.html

- firejail
  - Locate upstream patches for older versions (but newer than stretch's)
  - Upgrade to buster backport due to patch invasiveness
  - DLA-3061-1
https://lists.debian.org/debian-lts-announce/2022/06/msg00023.html

- systemd
  - DLA-3063-1
https://lists.debian.org/debian-lts-announce/2022/06/msg00025.html


Documentation and tooling

- ckeditor (v4): initiate discussion with maintainers,
  suggest following upstream stable branch in all dists
  https://lists.debian.org/debian-lts/2022/06/msg00023.html

- LTS documentation
  - Running tests: document direct run with newer/stretch syntax, some logging 
tips
https://wiki.debian.org/LTS/TestSuites/autopkgtest?action=diff&rev2=3&rev1=2


-- 
Sylvain Beucler
Debian LTS Team

ckeditor4 security update

[Sylvain Beucler]

Hello,

I'm working on Debian LTS (stretch), and I saw there are a number of 
CVEs against ckeditor (v4), as seen in #982587 #09 and #992290-2, 
and I'm willing to provide some help on this package.

https://security-tracker.debian.org/tracker/source-package/ckeditor

AFAIU ckeditor upstream does not provide much information on fixes, 
making it hard if not impossible to backport targeted fixes.

However they maintain branch 4.x cleanly.
Thus it may make sense to upgrade to 4.18 (or later) in all Debian 
dists, including stable/oldstable (possibly in the next point release).


Does that sound doable and safe enough, or do you think there's too much 
of a risk of breakage?


Cheers!
Sylvain Beucler
Debian LTS Team

Re: buster & ntpd leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 19 days

[Sylvain Beucler]

Hello Marc,

The exact switch dates aren't set yet.

I'd recommend opening a bug against buster's ntpd, and add 
debian-lts@lists.debian.org in Cc.


Cheers!
Sylvain Beucler
Debian LTS Team

On 09/06/2022 11:04, Marc SCHAEFER wrote:

buster is not yet handled by LTS, but it will be soon AFAIK.

Jun  9 09:10:02 virtual ntpd[20743]: leapsecond file 
('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 19 days

Could you look into it, or should I still report a bug against
buster's ntpd?

Thank you.

Debian LTS and ELTS - May 2022

[Sylvain Beucler]

Here is my public monthly report.

Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors


LTS

- front-desk
  - Leverage last month's new report on missing buster updates in LTS
- Mark 30 packages for update
- Clarify or fix triage for 11 packages
- Report: https://lists.debian.org/debian-lts/2022/05/msg00058.html
  - Mark 14 packages for update (regular front-desk triage workflow)
  - Set vulnerability status for 15 CVEs
  - Clarify postgresql-9.6 and nvidia-graphics-drivers-legacy-340xx status
https://lists.debian.org/debian-lts/2022/05/msg00055.html
https://lists.debian.org/debian-lts/2022/05/msg00057.html
  - Help fix incomplete announcement for DLA-2962-2 and DLA-3017-1

- rsyslog
  - Clarify related CVEs
  - Fix flaky tests in test suite on arm/slow architectures
  - DLA-3016-1
https://lists.debian.org/debian-lts-announce/2022/05/msg00028.html

- ckeditor (v4)
  - Assess supportability, probably requires mass upgrade
  - Postpone pending ckeditor3 status

- ckeditor3
  - Coordinate support status with maintainer and security team
https://lists.debian.org/debian-lts/2022/05/msg00018.html
  - Mark EOL for stretch
https://salsa.debian.org/debian/debian-security-support/-/merge_requests/14

- libdbi-perl
  - DLA-3035-1
https://lists.debian.org/debian-lts-announce/2022/05/msg00046.html


ELTS

- front-desk
  - Common work with TLS
  - Leverage last month's new report on missing buster update in LTS
- Mark 8 supported packages for update
  - Associate CVEs with 3 renamed supported packages
  - Mark 2 packages for update
  - Set vulnerability status for 13 CVEs

- ckeditor (v4)
  - Drop support (actually unused in jessie)

- rsyslog
  - Commmon work with LTS
  - No update (no affected CVEs, nothing to do for now)

- libdbi-perl
  - Commmon work with LTS
  - ELA-620-1
https://deb.freexian.com/extended-lts/updates/ela-620-1-libdbi-perl/


Documentation and tooling

- LTS documentation
  - CVEs triage: add reference to introductory commit when 
https://wiki.debian.org/LTS/Development?action=diff&rev2=291&rev1=290
  - gen-DLA now removes obsolete triage
https://wiki.debian.org/LTS/Development?action=diff&rev2=294&rev1=293
  - ffmpeg testing: link our libav (past fork) documentation
https://wiki.debian.org/LTS/TestSuites/ffmpeg?action=diff&rev2=4&rev1=3
  - Wiki notifications HOWTO for the LTS namespace (internal documentation)

- security-tracker: lts-cve-triage.py
  - Clarify intent and recommend against downgrading report priority
https://lists.debian.org/debian-lts/2022/05/msg00035.html
https://lists.debian.org/debian-lts/2022/05/msg00038.html
  - Clarify report label and document expected front-desk action

- Internal discussions
  - Recommend keeping documentation in the wiki and ad-hoc READMEs
  - Recommend leaving git-based workflow optional

- Help LTS newcomers on IRC

-- 
Sylvain Beucler
Debian LTS Team

Re: Support for ckeditor3 in Debian

[Sylvain Beucler]

Hi,

On 21/05/2022 12:06, Sylvain Beucler wrote:

On 21/05/2022 10:45, Mike Gabriel wrote:
as I have a company interest in Horde and thus in ckeditor3, I'd be 
happy to co-fund work hours on ckeditor3. Esp. because ckeditor3 in 
unstable needs the same love as in LTS. And we are currently working 
on upgrading the company mailserver.


The extra funding from DAS-NETZWETKTEAM could either be directly 
invoiced to me by the LTS contributor or funding could be piped 
through Freexian if they can go with that and see that as a requirement.


So, ping@Raphael? I have something like 4-6 hours in mind. What is 
your preferred way of handling individual package funding such as 
described above.


Given that ckeditor is pretty opaque about their security fixes, I 
personally wouldn't know how to identify fixes to ckeditor3 and 
ckeditor(4) as shipped in Debian.  (Actually I was asked to clarify 
ckeditor3's situation so we don't offer to support a package that is 
really unsupportable.)


Status:
https://security-tracker.debian.org/tracker/source-package/ckeditor
https://security-tracker.debian.org/tracker/source-package/ckeditor3

Maybe one way forward would be to upgrade ckeditor in upstream Horde, 
bump all ckeditor(4) to the currently maintained 4.x in all Debian 
dists, and fund this through e.g.

https://freexian-team.pages.debian.net/project-funding/
(with security team's OK of course)

Unless there are other ideas on how to maintain horde/ckeditor3 as-is.


To recap:

- CKEditor's security announcements are too vague to identify the 
vulnerabilities and their fixes,


- CKEditor4.x is maintained upstream,

- CKEditor3.x isn't,

- Upgrading to CKEditor4 breaks php-horde-editor and php-horde-imp's API 
calls and specific plugins


- Horde's usage of CKEditor3 is standard and all the vulnerabilities are 
relevant in this context.


Consequently I propose ckeditor3 be end-of-life for stretch.
I plan to prepare a pull request for debian-security-support next week.

Cheers!
Sylvain Beucler
Debian LTS Team

Re: What is going on with debian-security-support in stretch?

[Sylvain Beucler]

Hi,

For the record:
https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/03a7d97fa8090d6f48808b08265b970606cb1569/data/dla-needed.txt#L50

Cheers!
Sylvain Beucler
Debian LTS Team

On 20/05/2022 22:00, Roberto C. Sánchez wrote:

I've not looked at the debian-security-support project in some time and
just now looking it for gpac EOL I've noticed that it seems very
outdated on stretch.

Currently the version of debian-security-support in stretch is
1:9+2021.01.23.  The last entry in security-support-ended.deb9 when
installing the package on stretch is to drop support for reel on
2021-01-22.  Since that release there has been a single commit on the
stretch branch for dropping support for keystone.  However, it has not
been released.  Then looking at security-support-ended.deb9 on the
master branch, after reel there have been further entries added to drop
support for keystone, libspring-java, guacamole-client and gpac (which I
just committed a little while ago).

It is not clear what the procedure is for ensuring that the package
stays updated in stretch.  I think Holger was managing that in the past,
but it seems to have been somewhat forgotten.

It seems like it would be good to bring the stretch branch of
debian-security-support up to date to provide an accurate picture of the
packages that no longer have security support and then to build and
upload.  Then the upload should be followed by a DLA (example [0]).  If
there are no objections, I will go ahead and do this in two or three
days.

If anyone has any comments or feedback, those would be welcome.

Re: Tracking buster/stable updates suitable for LTS

[Sylvain Beucler]

Hi,

"Issues postponed for stretch, but fixed in buster via DSA or point 
releases" is now almost empty.  Hopefully it won't scare off FDs anymore ;)


For the 30ish other packages, I either revisited the triage, or could 
add them to dla-needed.txt (and some to ela-needed.txt).


We got several batches of pending minor CVEs, but also a few more severe 
missed updates and follow-ups, and checking the reported packages 
brought some past tangent mistakes into light (see my past 2 days 
commits for details).


I believe this report is an efficient tool for front-desk to keep track 
of oldstable work on the numerous postponed vulnerabilities, and I 
expect it to bring more interested packages in the future.


Cheers!
Sylvain

On 17/05/2022 20:47, Ola Lundqvist wrote:

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 happy to do either way, but I want to do the right thing :-)

Cheers

// Ola

On Tue, 17 May 2022 at 15:37, Anton Gladky <mailto:gl...@debian.org>> 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.

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
mailto:b...@beuc.net>>:
 >
 > 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 fixed in
buster via
 > > DSA or point releases".
 > >
 > > I think people before me have missed to help with that triaging
 > > because that list of packages to check is long. At least it is
easy to
 > > miss it.
 >
 > See https://lists.debian.org/debian-lts/2022/04/msg00011.html
<https://lists.debian.org/debian-lts/2022/04/msg00011.html> for
 > context. I also talked about it during the monthly meeting.
 >
 > "Issues postponed for stretch, but fixed in buster via DSA or point
 > releases" is a long section because it's new, it shouldn't stay
that way.
 >
 > I'm not sure why the past few front-desk didn't tackle it already
 > despite the above communications, in any case I plan to tackle it
during
 > my FD slot next week if nobody beats me to it.
 >
 >
 > > Now to the question. Do we generally wait for the Debian
Security team
 > > to do their analysis before LTS do it? If that is the case, the
 > > current list makes sense. If not I think my proposed change
should be
 > > done.
 > >
 > > I have done a change so that "Issues postponed for stretch, but
fixed
 > > in buster via DSA or point releases" is much further down in
the list
 > > because it is generally not so important for triaging work,
compared
 > > to the other ones.
 > >
 > > Any objections? If not, I'll commit the change tomorrow.
 >
 > This section is where we are late compared to stable/oldstable, where
 > CVEs are already fixed and published in Debian, but not in Debian
LTS,
 > sometimes months after.
 >
 > This sounds more urgent to me than checking untriaged CVEs, hence why
 > it's output before.  So I'd keep the ordering as-is.

Re: How to interpret packages-to-support

[Sylvain Beucler]

Hi,

In LTS triage, 'packages-to-support' is only relevant for non-free packages.

Some sponsors requested updates for nvidia-graphics-drivers, so even if 
it is in (unsupported) non-free, LTS supports it.


However no sponsors requested updates for (separate) 
nvidia-graphics-drivers-legacy-340xx, so we  those.


(also AFAIU we probably can't support 340xx which is EOL'd upstream, and 
I think the same issue is currently happening with 390xx.)


Cheers!
Sylvain

On 22/05/2022 23:20, Ola Lundqvist wrote:

Hi Roberto, Sylvain, all

I have the same view as you, almost. The LTS packages-to-support list
has some meaning since it indicates how important packages is to
update so it gives some priority information.

The thing here is that in this case the package I asked for is
non-free, and that means that it is not generally supported. But since
we have a very similar package in the packages-to-support list I was
wondering whether we should support this one too.

Specifically for nvidia-graphics-drivers-legacy-340xx I wonder if we
should support it even if it is in the non-free section because we say
we should support nvidia-graphics-drivers.

I guess I will not get an answer today so I'll leave this to the next
front-desk person (Sylvain) tomorrow.

Cheers

// Ola

On Fri, 20 May 2022 at 23:51, Roberto C. Sánchez  wrote:


On Fri, May 20, 2022 at 11:09:47PM +0200, Ola Lundqvist wrote:

Hi LTS team

I looked at nvidia-graphics-drivers-legacy-340xx who have two CVEs. I
can see that this package is not in "packages-to-support" for LTS. But
I can see that nvidia-graphics-drivers is.
I'm not sure how to interpret this. Do the entry in
packages-to-support mean that all nvidia-graphics-drivers packages
should be supported or just the specific one listed.

Anyone know this?


Hi Ola,

I encountered this some time back when I was doing FD work.  My
recollection of Raphael's guidance is that packages-to-support really
only applies for ELTS (where sponsors decide which specific packages
they will pay to support).  For LTS, we support all packages except
those which the Security Team had previously decided to drop and those
which the LTS Team has decided to drop.  The LTS triage script retrieves
the current list from debian-security-support package, so it should
point out which packages are EOL or have limited security support.  All
other packages are supported as usual.

Re: CVE-2022-1552/postgresql-9.6 for stretch

[Sylvain Beucler]

Hello Christoph,

On 23/05/2022 10:04, Christoph Berg wrote:

Re: Sylvain Beucler

According to the LTS files, you plan to take care of postgresql-9.6 security
updates for stretch.


I had told the security team that I do *not* intend to updated 9.6 in
stretch. I guess that got noted incorrectly.

If anyone wants to pick that up, I have no objections.


Thanks for the fast confirmation.

I updated the LTS files as follow:
https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/packages/lts-do-call-me#L11

Other LTS contributors will look into updating postgresql-9.6 for stretch.

Cheers!
Sylvain Beucler
Debian LTS Team

CVE-2022-1552/postgresql-9.6 for stretch

[Sylvain Beucler]

Hello Christoph,

According to the LTS files, you plan to take care of postgresql-9.6 
security updates for stretch.


I reserved postgresql-9.6 for you in
https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/dla-needed.txt

AFAICS postgresql-9 is not supported upstream since 2021-11
https://www.postgresql.org/support/versioning/
so if this changes anything in your plans please let me know.

Cheers!
Sylvain Beucler
Debian LTS Team