Re: Jessie update of freeimage?

[Anton Gladky]

Hello Chris,

I will take care of it.

Regards

Anton

Am Do., 23. Mai 2019 um 07:33 Uhr schrieb Chris Lamb :
>
> Dear maintainer(s),
>
> The Debian LTS team would like to fix the security issues which are
> currently open in the Jessie version of freeimage:
> https://security-tracker.debian.org/tracker/source-package/freeimage
>
> Would you like to take care of this yourself?
>
> If yes, please follow the workflow we have defined here:
> https://wiki.debian.org/LTS/Development
>
> If that workflow is a burden to you, feel free to just prepare an
> updated source package and send it to debian-lts@lists.debian.org
> (via a debdiff, or with an URL pointing to the source package,
> or even with a pointer to your packaging repository), and the members
> of the LTS team will take care of the rest. Indicate clearly whether you
> have tested the updated package or not.
>
> If you don't want to take care of this update, it's not a problem, we
> will do our best with your package. Just let us know whether you would
> like to review and/or test the updated package before it gets released.
>
> You can also opt-out from receiving future similar emails in your
> answer and then the LTS Team will take care of freeimage updates
> for the LTS releases.
>
> Thank you very much.
>
> Chris Lamb,
>   on behalf of the Debian LTS team.
>
> PS: A member of the LTS team might start working on this update at
> any point in time. You can verify whether someone is registered
> on this update in this file:
> https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/dla-needed.txt
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

amd64-microcode, test

[Anton Gladky]

/amd-ucode
diff -Nru 
amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.modprobe-blacklist 
amd64-microcode-3.20191218.1+deb8u1/debian/amd64-microcode.modprobe-blacklist
--- 
amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.modprobe-blacklist   
1970-01-01 00:00:00.0 +
+++ 
amd64-microcode-3.20191218.1+deb8u1/debian/amd64-microcode.modprobe-blacklist   
2019-12-20 21:33:42.0 +
@@ -0,0 +1,3 @@
+# The microcode module attempts to apply a microcode update when
+# it autoloads.  This is not always safe, so we block it by default.
+blacklist microcode
diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.postinst 
amd64-microcode-3.20191218.1+deb8u1/debian/amd64-microcode.postinst
--- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.postinst 
1970-01-01 00:00:00.0 +
+++ amd64-microcode-3.20191218.1+deb8u1/debian/amd64-microcode.postinst 
2019-12-20 21:33:42.0 +
@@ -0,0 +1,46 @@
+#!/bin/sh
+# postinst script for amd64-microcode
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#*  `configure' 
+#*  `abort-upgrade' 
+#*  `abort-remove' `in-favour' 
+#  
+#*  `abort-remove'
+#*  `abort-deconfigure' `in-favour'
+#`removing'
+#   
+# for details, see http://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+case "$1" in
+configure)
+   # do it like udev and firmware-linux-*
+   if [ -x /usr/sbin/update-initramfs ] && [ -e 
/etc/initramfs-tools/initramfs.conf ] ; then
+   update-initramfs -u && {
+   echo "amd64-microcode: microcode will be updated at next boot" 
>&2
+   }
+   else
+   echo "amd64-microcode: initramfs support missing" >&2
+   fi
+;;
+
+abort-upgrade|abort-remove|abort-deconfigure)
+;;
+
+*)
+echo "postinst called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+exit 0
diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.postrm 
amd64-microcode-3.20191218.1+deb8u1/debian/amd64-microcode.postrm
--- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.postrm   
1970-01-01 00:00:00.0 +
+++ amd64-microcode-3.20191218.1+deb8u1/debian/amd64-microcode.postrm   
2019-12-20 21:33:42.0 +
@@ -0,0 +1,42 @@
+#!/bin/sh
+# postrm script for amd64-microcode
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#*  `remove'
+#*  `purge'
+#*  `upgrade' 
+#*  `failed-upgrade' 
+#*  `abort-install'
+#*  `abort-install' 
+#*  `abort-upgrade' 
+#*  `disappear' 
+#  
+# for details, see http://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+case "$1" in
+purge|remove)
+   if [ -x /usr/sbin/update-initramfs -a -e 
/etc/initramfs-tools/initramfs.conf ] ; then
+   update-initramfs -u
+   fi
+;;
+
+upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
+;;
+
+*)
+echo "postrm called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+exit 0
diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/changelog 
amd64-microcode-3.20191218.1+deb8u1/debian/changelog
--- amd64-microcode-2.20160316.1~deb8u1/debian/changelog2016-03-19 
17:22:44.0 +
+++ amd64-microcode-3.20191218.1+deb8u1/debian/changelog2020-03-10 
20:18:47.0 +
@@ -1,8 +1,140 @@
-amd64-microcode (2.20160316.1~deb8u1) stable; urgency=critical
+amd64-microcode (3.20191218.1+deb8u1) UNRELEASED; urgency=high
 
-  * This is exactly the same release as 2.20160316.1
+  * Non-maintainer upload by the LTS team.
+  * New upstream release.
+  * Add IBPB support for family 17h AMD processors (CVE-2017-5715)
+(since 3.20180515.1).
 
- -- Henrique de Moraes Holschuh   Sat, 19 Mar 2016 14:21:54 
-0300
+ -- Anton Gladky   Tue, 10 Mar 2020 21:18:47 +0100
+
+amd64-microcode (3.20191218.1) unstable; urgency=medium
+
+  * New microcode update packages from AMD upstream:
++ Removed Microcode updates (known to cause issues):
+  sig 0x00830f10, patch id 0x08301025, 2019-07-11
+  * README: update for new release
+
+ -- Henrique de Moraes Holschuh   Fri, 20 Dec 2019 18:36:27 
-0300
+
+amd64-microcode (3.20191021.1) unstable; urgency=medium
+
+  * New microcode update packages from AMD upstream:
++ New Microcodes:
+  sig 0x00830f10, patch id 0x08301025, 2019-07

Re: amd64-microcode, test

[Anton Gladky]

Thank you for the feedback!

I have fixed the version number and uploaded again to [1].

[1]  https://people.debian.org/~gladk/amd64-microcode/

Anton


Am Mi., 11. März 2020 um 21:06 Uhr schrieb Salvatore Bonaccorso <
car...@debian.org>:

> Hi,
>
> A smaller comment on the update:
>
> On Wed, Mar 11, 2020 at 08:19:11PM +0100, Anton Gladky wrote:
> > After discussion with the maintainer I decided to backport the latest
> > upstream version, available in Debian (3.20191218.1). Prepared package
> > is available here [1]. Debdiff is attached.
> [...]
> > [1] https://people.debian.org/~gladk/amd64-microcode/
>
> If this is 3.20191218.1 upload backported/rebuild for jessie then
> please use 3.20191218.1~deb8u1, rather than 3.20191218.1+deb8u1, which
> will not correctly sort before  3.20191218.1 otherwise.
>
> Regards,
> Salvatore
>

Re: amd64-microcode, test

[Anton Gladky]

Thanks Emilio and Salvatore for very valuable comments!

I think then, that it would be more proper way to upload the lower
upstream version 3.20181128.1 into the Jessie and Stretch to escape
higher versions on older releases.

This 3.20181128.1 version also fixes CVE-2017-5715 and is now the
current one in Buster. Also it seems to be reliable on AMD EPYC 7542,
which showed regression previously [1].

Thus I am asking for testing of newly updated package for Jessie [2], if
somebody has an access to the hardware with AMD processors. If no
negative feedback will come within the next few days, I will upload it
into archive on Saturday evening.

Debdiff is attached.

[1] https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/1853614

[2] https://people.debian.org/~gladk/amd64-microcode_jessie/

Best regards

Anton

On 3/11/20 9:37 PM, Emilio Pozuelo Monfort wrote:
> On 11/03/2020 21:06, Salvatore Bonaccorso wrote:
>> Hi,
>>
>> A smaller comment on the update:
>>
>> On Wed, Mar 11, 2020 at 08:19:11PM +0100, Anton Gladky wrote:
>>> After discussion with the maintainer I decided to backport the latest
>>> upstream version, available in Debian (3.20191218.1). Prepared package
>>> is available here [1]. Debdiff is attached.
>> [...]
>>> [1] https://people.debian.org/~gladk/amd64-microcode/
>>
>> If this is 3.20191218.1 upload backported/rebuild for jessie then
>> please use 3.20191218.1~deb8u1, rather than 3.20191218.1+deb8u1, which
>> will not correctly sort before  3.20191218.1 otherwise.
> 
> This should also be coordinated with buster and stretch point updates, so that
> we avoid having a higher version in jessie.
> 
> Cheers,
> Emilio
> 
diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.default 
amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.default
--- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.default  
1970-01-01 01:00:00.0 +0100
+++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.default  
2018-12-15 03:43:55.0 +0100
@@ -0,0 +1,13 @@
+# Configuration script for amd64-microcode version 3
+
+#
+# initramfs helper
+#
+
+#
+# Set this to "no" to disable automatic microcode updates on boot;
+# Set this to "early" to always install microcode updates to the early 
initramfs
+# Set this to "auto" to autodetect mode for current system (default);
+#
+#AMD64UCODE_INITRAMFS=auto
+
diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.dirs 
amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.dirs
--- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.dirs 
1970-01-01 01:00:00.0 +0100
+++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.dirs 
2018-12-15 03:43:55.0 +0100
@@ -0,0 +1,3 @@
+etc/default
+etc/modprobe.d
+lib/firmware/amd-ucode
diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.docs 
amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.docs
--- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.docs 
1970-01-01 01:00:00.0 +0100
+++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.docs 
2018-12-15 03:43:55.0 +0100
@@ -0,0 +1,3 @@
+README
+microcode_amd.bin.README
+microcode_amd_fam*.README
diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.install 
amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.install
--- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.install  
1970-01-01 01:00:00.0 +0100
+++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.install  
2018-12-15 03:43:55.0 +0100
@@ -0,0 +1,2 @@
+microcode_amd.bin  /lib/firmware/amd-ucode
+microcode_amd_fam*.bin /lib/firmware/amd-ucode
diff -Nru 
amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.modprobe-blacklist 
amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.modprobe-blacklist
--- 
amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.modprobe-blacklist   
1970-01-01 01:00:00.0 +0100
+++ 
amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.modprobe-blacklist   
2018-12-15 03:43:55.0 +0100
@@ -0,0 +1,3 @@
+# The microcode module attempts to apply a microcode update when
+# it autoloads.  This is not always safe, so we block it by default.
+blacklist microcode
diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.postinst 
amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.postinst
--- amd64-microcode-2.20160316.1~deb8u1/debian/amd64-microcode.postinst 
1970-01-01 01:00:00.0 +0100
+++ amd64-microcode-3.20181128.1+deb8u1/debian/amd64-microcode.postinst 
2018-12-15 03:43:55.0 +0100
@@ -0,0 +1,46 @@
+#!/bin/sh
+# postinst script for amd64-microcode
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+# 

Re: amd64-microcode, test

[Anton Gladky]

20160316.1~deb8u1/debian/amd64-microcode.postrm   
1970-01-01 01:00:00.0 +0100
+++ amd64-microcode-3.20181128.1~deb8u1/debian/amd64-microcode.postrm   
2018-12-15 03:43:55.0 +0100
@@ -0,0 +1,42 @@
+#!/bin/sh
+# postrm script for amd64-microcode
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#*  `remove'
+#*  `purge'
+#*  `upgrade' 
+#*  `failed-upgrade' 
+#*  `abort-install'
+#*  `abort-install' 
+#*  `abort-upgrade' 
+#*  `disappear' 
+#  
+# for details, see http://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+case "$1" in
+purge|remove)
+   if [ -x /usr/sbin/update-initramfs -a -e 
/etc/initramfs-tools/initramfs.conf ] ; then
+   update-initramfs -u
+   fi
+;;
+
+upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
+;;
+
+*)
+echo "postrm called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+exit 0
diff -Nru amd64-microcode-2.20160316.1~deb8u1/debian/changelog 
amd64-microcode-3.20181128.1~deb8u1/debian/changelog
--- amd64-microcode-2.20160316.1~deb8u1/debian/changelog2016-03-19 
18:22:44.0 +0100
+++ amd64-microcode-3.20181128.1~deb8u1/debian/changelog2020-03-12 
20:29:09.0 +0100
@@ -1,8 +1,119 @@
-amd64-microcode (2.20160316.1~deb8u1) stable; urgency=critical
+amd64-microcode (3.20181128.1~deb8u1) jessie-security; urgency=high
 
-  * This is exactly the same release as 2.20160316.1
+  * Non-maintainer upload by the LTS Security Team.
+  * New upstream release.
+  * Add IBPB support for family 17h AMD processors (CVE-2017-5715)
+(since version 3.20180515.1).
 
- -- Henrique de Moraes Holschuh   Sat, 19 Mar 2016 14:21:54 
-0300
+ -- Anton Gladky   Thu, 12 Mar 2020 20:29:09 +0100
+
+amd64-microcode (3.20181128.1) unstable; urgency=medium
+
+  * New microcode update packages from AMD upstream:
++ New Microcodes:
+  sig 0x00800f82, patch id 0x0800820b, 2018-06-20
+  * README: update for new release
+
+ -- Henrique de Moraes Holschuh   Sat, 15 Dec 2018 18:42:12 
-0200
+
+amd64-microcode (3.20180524.1) unstable; urgency=high
+
+  * New microcode update packages from AMD upstream:
++ Re-added Microcodes:
+  sig 0x00610f01, patch id 0x06001119, 2012-07-13
+  * This update avoids regressing sig 0x610f01 processors on systems with
+outdated firmware by adding back exactly the same microcode patch that was
+present before [for these processors].  It does not implement Spectre-v2
+mitigation for these processors.
+  * README: update for new release
+
+ -- Henrique de Moraes Holschuh   Fri, 25 May 2018 15:38:22 
-0300
+
+amd64-microcode (3.20180515.1) unstable; urgency=high
+
+  * New microcode update packages from AMD upstream:
++ New Microcodes:
+  sig 0x00800f12, patch id 0x08001227, 2018-02-09
++ Updated Microcodes:
+  sig 0x00600f12, patch id 0x0600063e, 2018-02-07
+  sig 0x00600f20, patch id 0x06000852, 2018-02-06
++ Removed Microcodes:
+  sig 0x00610f01, patch id 0x06001119, 2012-07-13
+  * Adds Spectre v2 (CVE-2017-5715) microcode-based mitigation support,
+plus other unspecified fixes/updates.
+  * README, debian/copyright: update for new release
+
+ -- Henrique de Moraes Holschuh   Sat, 19 May 2018 13:51:06 
-0300
+
+amd64-microcode (3.20171205.2) unstable; urgency=medium
+
+  * debian/control: update Vcs-* fields for salsa.debian.org
+
+ -- Henrique de Moraes Holschuh   Fri, 04 May 2018 07:51:40 
-0300
+
+amd64-microcode (3.20171205.1) unstable; urgency=high
+
+  * New microcode updates (closes: #886382):
+sig 0x00800f12, patch id 0x08001213, 2017-12-05
+Thanks to SuSE for distributing these ahead of AMD's official release!
+  * Add IBPB support for family 17h AMD processors (CVE-2017-5715)
+  * README: describe source for faml17h microcode update
+  * Upload to unstable to match IBPB microcode support on Intel in Debian
+unstable.
+  * WARNING: requires at least kernel 4.15, 4.14.13, 4.9.76, 4.4.111 (or a
+backport of commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf
+"x86/microcode/AMD: Add support for fam17h microcode loading") otherwise
+it will not be applied to the processor.
+
+ -- Henrique de Moraes Holschuh   Mon, 08 Jan 2018 12:19:57 
-0200
+
+amd64-microcode (3.20160316.3) unstable; urgency=medium
+
+  * initramfs: Make the early initramfs reproducible (closes: #845194)
+  * rules: switch to simplified dh-based build (debhelper v9)
+
+ -- Henrique de Moraes Holschuh   Tue, 29 Nov 2016 23:54:53 
-0200
+
+amd64-microcode (3.20160316.2) unstable; urgency=medium
+
+  * NEWS.debian: fix minor typo
+  * debian/control, debian/compat: bump debhelper com

amd64-microcode, version number, no-dsa

[Anton Gladky]

Dear LTS team,

I am still preparing an update for amd64-microcode for Jessie to fix
CVE-2017-5715. Security team marked this issue as no-dsa for Stretch
[1], it can be fixed through next point release.

For Jessie I am not able to use now the package version
3.20181128.1~deb8u1, because it is higher than the current Stretch
version 3.20160316.3, so upgrade would not be possible in the meantime.

Thus I'm asking for an advice:

  * May I set the version number for this update as
2.20160316.1+really3.20181128.1~deb8u1? After the next Stretch point
release I can reupload it with the version number 3.20181128.1~deb8u1.
Or there are better alternatives?

  * Package is non-free, should the amd64 and i386 binary packages both
be uploaded?

[1]
https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/1c9dda4132363fd5b169a3aad5fec48a4e4d2f72

Thank you

Anton



signature.asc
Description: OpenPGP digital signature

Re: amd64-microcode, version number, no-dsa

[Anton Gladky]

I have filed #954023 and prepared upload for Debian Stretch to prevent
higher versions in older releases. Still no feedback from debian-release-team.

But in this particular case it should not be a problem, if Stretch
will have an older version for the moment. During the upgrade
Jessie->Stretch the Jessie-version(3.20181128.1~deb8u1)
will not be upgraded to the older vulnerable Stretch-version (3.20160316.3).
The Jessie fixed version can live in the meantime in the Stretch.

Best regards

Anton

[SECURITY] [DLA 2200-1] mailman security update

[Anton Gladky]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: mailman
Version: 1:2.1.18-2+deb8u5
CVE ID : CVE-2020-12137


A vulnerability was discovered in mailman. GNU Mailman 2.x before 2.1.30
uses the .obj extension for scrubbed application/octet-stream MIME
parts. This behavior may contribute to XSS attacks against list-archive
visitors, because an HTTP reply from an archive web server may lack a
MIME type, and a web browser may perform MIME sniffing, conclude that
the MIME type should have been text/html, and execute JavaScript code.


For Debian 8 "Jessie", this problem has been fixed in version
1:2.1.18-2+deb8u5.

We recommend that you upgrade your mailman packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl6ul7wACgkQ0+Fzg8+n
/wbZ9g//Q+FFmQ2beDonA+YS3zk44DdQsnhlGTZMd3jkmEdlwGsv3r9V9ZS0ho64
rMhWwRGzixBEf0C+7p/UMVBfRVAZS23Usz8dHjtuvTdllD2mAGhZ+IHAoSwpZ3mS
9wvjSqTLrPG/6JZJaH95q0cI3ZkrdZLjLSnB3nJ2eJ7QoSYEpTSHdjNc6xRswdkt
AawzUHN8g1cQrf0HX8mSvL6yirwp+Wc9oNVJT1HQL3MU95Pr2A1h+D7z4MhcUTMW
zKe1RaKPEozvqsyZ5Op7R2nDdWali9JuRDURCqoFaO4KENUf8CIkWpxKsla2rieU
z7F7C6TL/fubhLUdWX11A4ZCYyX0d0m0EGIhsEX6NhqSn6gsLasv0bOlGwvK5hvt
B5rktpjIEW7YF1Ao4weMLsryrWTyaY3saP0Ou7eiLc40/Tlwn7Ey/iaf1WT8PhCY
YRVZMCmvxKfHIsDC5Nj6QVIXlhr60f2t8SK6hHz9rVZT0EZ++ZNQb89wZJIIS9Mc
/NZTpJdoJRdSzCE0S6nt/PjRphQdDnMihq4puaf50tILyi3j/LnFdztU7I+3QD+7
FWOz3al9IWw4nXFtNdiN/jy07Fm9FiOzbFnMld+9KTq2mgpmt9gKwmjGwA6Xb+vI
oetZV6nG+jVpX+EYDUL5gtXQSJJDVVbEZmvk4ii2GN+lrodUUzk=
=EF8p
-END PGP SIGNATURE-

FTBFS on i386

[Anton Gladky]

Dear LTS team,

I prepared and uploaded python2.7_2.7.13-2+deb9u5, fixing
two CVEs.

Unfortunately it fails on i386 due to timeout during the network
test. I believe that one more try should fix the problem, because
most of the other archs are already green.

But in the security suite the givebacks from usual users do not work.
Do you have tips on how I can trigger the recompilation of the package
without doing a new source upload?

Thank you

Anton

Re: FTBFS on i386

[Anton Gladky]

Thank you all for the very quick response and help!
It is built now successfully!

Have a nice weekend.

Anton



Am Sa., 17. Apr. 2021 um 18:53 Uhr schrieb Utkarsh Gupta :

> Hi Salvatore,
>
> On Sat, Apr 17, 2021 at 10:19 PM Salvatore Bonaccorso 
> wrote:
> > > I have given it back to try a rebuild.
> > Should be built now.
>
> Awesome, thanks a bunch for your help!
>
>
> - u
>
>

Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)

[Anton Gladky]

Hi Lynoure,

Thanks for pointing this out! DLA 2628-1 was released [1],
but the website update did not work well (not pushed). I have fixed
it and it should appear on the website shortly.

[1] https://lists.debian.org/debian-lts-announce/2021/04/msg00015.html

Best regards

Anton


Am Mo., 26. Apr. 2021 um 17:39 Uhr schrieb Lynoure Braakman <
lyno...@lynoure.net>:

> hi,
>
> As I am gradually taking coordination duties over fro Holger, here's my
> first
> time doing these mails.
>
> Nobody claimed 4 packages or more.
>
> Nothing was unclaimed for LTS or ELTS.
>
> Four DLAs have been reserved and haven't been published yet:
>  DLA 2637-1 (23 Apr 2021)  (drupal7)
>  DLA 2636-1 (23 Apr 2021) (pjproject)
>  DLA 2629-1 (18 Apr 2021) (libebml)
>  DLA 2628-1 (17 Apr 2021) (python2.7)
>  DLA 2618-2 (16 Apr 2021) (smarty3)
>  DLA 2610-1 (29 Mar 2021) (linux-4.19)
>
>
> Have a splendid week,
>
> --
> Lynoure Braakman
>
>
>

Re: bind9 security update

[Anton Gladky]

Hi Emilio,

I have prepared a repo for bind9-lts-upload and salsa pipelines are passed
[2].
I needed to disable blhc-test though, but it should not be fixed by targeted
security upload.

[1] https://salsa.debian.org/lts-team/packages/bind9
[2] https://salsa.debian.org/lts-team/packages/bind9/-/pipelines/251693

Best regards

Anton



Am Mo., 3. Mai 2021 um 14:17 Uhr schrieb Emilio Pozuelo Monfort <
po...@debian.org>:

> Hi,
>
> I have prepared a security update for LTS for the recent bind9 CVEs. I
> have done
> some testing on them, but if someone can give them some additional testing
> that'd be great. The packages can be found at:
>
>https://people.debian.org/~pochu/lts/bind9/
>
> Thanks!
> Emilio
>
>

Re: bind9 security update

[Anton Gladky]

I have added autopkgtest to the stretch-version of bind9 [1].
And the pipelines passed [2].

Feel free to commit there the following versions.

[1]
https://salsa.debian.org/lts-team/packages/bind9/-/tree/master-stretch/debian/tests
[2] https://salsa.debian.org/lts-team/packages/bind9/-/jobs/1620698

Regards

Anton


Am Di., 4. Mai 2021 um 12:54 Uhr schrieb Utkarsh Gupta :

> Hello,
>
> On Mon, May 3, 2021 at 5:47 PM Emilio Pozuelo Monfort 
> wrote:
> > I have prepared a security update for LTS for the recent bind9 CVEs. I
> have done
> > some testing on them, but if someone can give them some additional
> testing
> > that'd be great.
>
> If it still helps, I had set up a DNS server, etc to do a smoke +
> sanity test and it looked OK and all works, so far! \o/
>
> Besides this, at some point, it's worth adding a DEP8 test from the
> master branch at salsa to what's there in stretch and jessie. But more
> of a nice-to-have wishlist item. If I'll remember next time, I'll do
> it myself.
>
>
> - u
>
>

libgetdata

[Anton Gladky]

Hi Chris,

as you are having an FD-role this week, I would like
you to ask to add libgetdata to dla-needed. I have prepared
an update for sid/bullseye (waiting for approval) and would
like also to update a package for stretch.

Thank you

Anton

Re: libgetdata

[Anton Gladky]

Hi Chris,

thank you. I needed to create a patch (for sid/bullseye) because the patch
is not available/hidden.

Best regards

Anton


Am Mo., 10. Mai 2021 um 11:11 Uhr schrieb Chris Lamb :

> Hi Anton,
>
> > as you are having an FD-role this week, I would like
> > you to ask to add libgetdata to dla-needed. I have prepared
> > an update for sid/bullseye (waiting for approval) and would
> > like also to update a package for stretch.
>
> Sure thing; and I have just done this and assigned the package to you.
> I couldn't easily find the patch for CVE-2021-20204 to confirm that
> the version in LTS is vulnerable, but from your message I will assume
> that you have access.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
>`-
>

Re: Propose to ignore libxstream-java CVEs

[Anton Gladky]

Hi Markus,

I have applied your patch and the pipelines are passed [1]. So, at least
nothing breaks from the "build side of view".

Yes, I took this package, but uf your are working on it, feel free to
reclaim it.

[1]
https://salsa.debian.org/lts-team/packages/libxstream-java/-/pipelines/292916

Best regards

Anton


Am Mi., 22. Sept. 2021 um 15:37 Uhr schrieb Markus Koschany :

> Hi all,
>
> so far I have not found any regressions in Debian packages which depend on
> libxstream-java. I propose to switch to the whitelist in all suites because
> this is the only reasonable way to secure XStream. I have prepared an
> update
> for Stretch. Anton, could you take a look at it because I saw you have
> claimed
> libxstream-java?
>
> https://people.debian.org/~apo/lts/libxstream-java/libxstream-java.debdiff
>
>
> Regards,
>
> Markus
>
>
>
>
>
>

Re: [SECURITY] [DLA 2775-1] plib security update

[Anton Gladky]

Hi Marc,

thanks for the note. Yes, I will add a short package description
next time to DLAs if it helps to make an update-decision.

Best regards

Anton


Am Sa., 2. Okt. 2021 um 14:34 Uhr schrieb Marc SCHAEFER <
schae...@alphanet.ch>:

> On Sat, Oct 02, 2021 at 01:45:33PM +0200, Anton Gladky wrote:
> > Package: plib
> > Version: 1.8.5-7+deb9u1
> > CVE ID : CVE-2021-38714
> >
> > One security issue has been discovered in plib.
>
> Yes, what is the purpose of this library?  This helps planning upgrades.
>
> Other advisories always give a short summary of what the software does.
>
> Actually, I think this is against libplib1, which seems to be:
>
>  Provides a Joystick interface, a simple GUI built on top of OpenGL,
>  some standard geometry functions, a sound library and a simple scene
>  graph API built on top of OpenGL.
>
> Oh, great, this probably does not run on my servers, so no need to plan
> anything.
>
> Thank you for updating DLAs, like DSAs are doing, to add a short summary
> of the
> purpose of the package, and give the correct package name so that it can be
> quickly found.
>
>

Re: Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Anton Gladky]

Hi Adrian,

well, I was thinking that upstream should request a CVE. Neverheless
I could not reproduce the issue with the modern GCC-versions.
Even on 32bit-systems.

Regards

Anton

Am Sa., 13. Nov. 2021 um 21:09 Uhr schrieb Adrian Bunk :
>
> On Fri, Sep 17, 2021 at 07:02:48AM +0200, Anton Gladky wrote:
> > Thanks, Vincent, for the information. I would still wait for CVE,
> > so we can apply a patch and track vulnerability for other
> > Debian versions (stable/oldstable/o-o-stable etc.).
>
> Hi Anton,
>
> did you manage to get a CVE assigned for this issue, or has there been
> any problem with tnat?
>
> > Regards
> >
> > Anton
>
> Thanks
> Adrian

Re: Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Anton Gladky]

Thanks, Vincent,

now I am able to reproduce the issue!

I will request CVE.

Regards

Anton

Am So., 14. Nov. 2021 um 15:44 Uhr schrieb Vincent Lefevre :
>
> On 2021-11-14 14:15:25 +0100, Anton Gladky wrote:
> > well, I was thinking that upstream should request a CVE. Neverheless
> > I could not reproduce the issue with the modern GCC-versions.
> > Even on 32bit-systems.
>
> I can still reproduce the segmentation fault under Debian/unstable.
> Simplified testcase:
>
> #include 
> #include 
>
> int main (void)
> {
>   mpz_t s;
>   mpz_init (s);
>   mpz_inp_raw (s, stdin);
>   return 0;
> }
>
> Compile with gcc -m32 and execute:
>
>   printf 12345 | ./testcase
>
> Note that even if you don't get a segmentation fault, there may be
> other erratic behaviors, such as silent memory corruption (which may
> be even worse).
>
> --
> Vincent Lefèvre  - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>

Re: Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines

[Anton Gladky]

CVE-2021-43618 is assigned to this issue.

Adrian Bunk  schrieb am Sa., 13. Nov. 2021, 21:09:

> On Fri, Sep 17, 2021 at 07:02:48AM +0200, Anton Gladky wrote:
> > Thanks, Vincent, for the information. I would still wait for CVE,
> > so we can apply a patch and track vulnerability for other
> > Debian versions (stable/oldstable/o-o-stable etc.).
>
> Hi Anton,
>
> did you manage to get a CVE assigned for this issue, or has there been
> any problem with tnat?
>
> > Regards
> >
> > Anton
>
> Thanks
> Adrian
>

Re: Semi-automatic package unclaim after two weeks of inactivity

[Anton Gladky]

Hi Jeremiah,

> DLA 2839-1 (03 Dec 2021) (gerbv)

thanks, it was announced and just pushed to the website.
Will appear there soon.

Regards

Anton

Am Di., 7. Dez. 2021 um 01:05 Uhr schrieb Jeremiah C. Foster
:
>
> Hi,
>
> Today three packages were "unclaimed" for LTS, and two for ELTS;
>
> -firmware-nonfree (Markus Koschany)
> -gpac (Roberto C. Sánchez)
> -libssh2 (Ola Lundqvist)
>
> -firmware-nonfree (Markus Koschany)
> -samba (Utkarsh)
>
> No one has claimed 4 or more packages.
>
> There appears to be just a single DLA which is reserved but not yet
> published, namely;
>
> DLA 2839-1 (03 Dec 2021) (gerbv)
>
> Have a great week!
>
> Cheers,
>
> Jeremiah
>

Re: [SECURITY] [DLA 2879-1] lighttpd security update -> DLA=2887-1

[Anton Gladky]

Dear all,

lighttpd security update was announced recently under the wrong DLA-number. The
proper one is [DLA-2887-1]. Sorry for inconvenience.

[DLA-2887-1] https://www.debian.org/lts/security/2022/dla-2887

Best regards

Anton


On 1/18/22 18:55, Anton Gladky wrote:
> -
> Debian LTS Advisory DLA-2879-1debian-lts@lists.debian.org
> https://www.debian.org/lts/security/     Anton Gladky
> January 14, 2022  https://wiki.debian.org/LTS
> -
> 
> Package: lighttpd
> Version: 1.4.45-1+deb9u1
> CVE ID : CVE-2018-19052
> 
> One issue has been discovered in lighttpd: fast webserver with minimal memory
> footprint.
> 
> CVE-2018-19052: an issue was discovered in mod_alias_physical_handler in
> mod_alias.c in lighttpd before 1.4.50. There is potential ../ path traversal 
> of
> a single directory above an alias target, with a specific mod_alias
> configuration where the matched alias lacks a trailing '/' character, but the
> alias target filesystem path does have a trailing '/' character.
> 
> For Debian 9 stretch, this problem has been fixed in version
> 1.4.45-1+deb9u1.
> 
> We recommend that you upgrade your lighttpd packages.
> 
> For the detailed security status of lighttpd please refer to
> its security tracker page at:
> https://security-tracker.debian.org/tracker/lighttpd
> 
> Further information about Debian LTS security advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://wiki.debian.org/LTS


OpenPGP_signature
Description: OpenPGP digital signature

Re: MariaDB security vulnerabilities

[Anton Gladky]

Dear Otto,

thanks for providing this valuable information.

Providing new binaries in LTS release can potentially break some
stuff. But if both
10.1 and 10.3 can co-exist, it could be an option.

Another problem is that 10.3 provides a new ABI (libmariadb19 instead
of libmariadb18), so
basically the rebuilding of all dependent binaries is needed (some
kind of transition). It is unlikely
possible as a security-only-support version.

Anyway, I have added mariadb-10.1 into the dla-needed.txt just to keep
it on track. But I am
not really sure that backporting of 10.3 will be a reality.

Best regards

Anton

Am Di., 22. Feb. 2022 um 09:51 Uhr schrieb Otto Kekäläinen :
>
> Hi!
>
> On Mon, Feb 14, 2022 at 4:04 AM Markus Koschany  wrote:
> >
> > Hello,
> >
> > Just a heads-up. New CVE have been reported for MariaDB 10.3. It is likely 
> > that
> > 10.1 in Stretch is affected as well. Otto Kekäläinen (maintainer) is 
> > currently
> > investigating if it is feasible to backport a newer MariaDB version to 
> > Stretch
> > because 10.1 is no longer supported upstream. Do we have any past 
> > experiences
> > how to handle MySQL/MariaDB updates if they are no longer supported?
>
> MariaDB 10.6 has so many changes in its build dependencies that making
> it build on Stretch library versions is probably too much work.
> Test build log at
> https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/2480109
>
> MariaDB 10.3 at least builds:
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/2498645
> However the mariadb-plugin-myrocks installation fails due to missing
> run-time dependencies:
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/2498653
>
> MariaDB 10.3 is also easier as it can use the existing galera-3
> package already in Stretch. Upstream support is until spring 2023.
>
> I think backporting MariaDB 10.3 might be feasible, but requires work.
> Is there really a lot of demand?
>
> - Otto
>

Re: Update of debian-archive-keyring in stretch?

[Anton Gladky]

I have followed the steps described in README.maintainer,
added my key to the team for stretch and imported keys.

It looks like everything works.Testing it.

Regards

Anton

Am Fr., 11. März 2022 um 14:28 Uhr schrieb Utkarsh Gupta
:
>
> Hi Jonathan,
>
> On Mon, Oct 11, 2021 at 6:24 AM Utkarsh Gupta  wrote:
> > On Tue, Oct 5, 2021 at 1:26 PM Jonathan Wiltshire  wrote:
> > > You will need (but may not want) the commit removing jessie's keys as 
> > > well.
> > > Basically all intermediate commits which touch keyrings - a removal is
> > > really a move from the main keyring to the archive keyring, so it will
> > > change the makeup of the keyring and fail the validation.
> > >
> > > If you actually need the jessie keys kept, as I suspect you do, I can
> > > prepare a stretch branch with new signatures on it in a few days.
> >
> > That'd be really helpful, yes. Though I am still unsure what am I missing.
> > When you prep a branch for stretch, please let me know and as I said,
> > that'd be really helpful. Thank you so much!
>
> Friendly ping on this. Any status update on this, please? :)
> Do you think you can take a look at this sooner? Let me/us know.
>
> > > I intend to simplify the whole thing significantly in bookworm; this whole
> > > jetring and gpg validation thing makes for a lot of maintenance pain.
> >
> > Perfect, that'll indeed help a lot. :)
>
>
> - u
>

Re: How to handle gpac?

[Anton Gladky]

Hi Roberto,

I agree with Utkarsh basically. Fixing over 100 (or even over 20)
issues through patches drastically increases chances to make a
mistake. Backporting newer version also has downsides.

I would propose to declare it as EOL.

Best regards

Anton

Am Do., 14. Apr. 2022 um 17:22 Uhr schrieb Roberto C. Sánchez
:
>
> Hello everyone,
>
> I've been working on gpac vulnerabilities.  The situation has reached a
> point where it seemed wise to seek some input from other folks in the
> LTS community before continuing.  With this message I am specifically
> seeking to start a discussion about the best way forward.
>
> First, some context from the PTS [0].
>
> Versions present in Debian:
>
> bookworm (and unstable): 2.0.0+dfsg1-2
> bullseye: 1.0.1+dfsg1-4+deb11u1
> buster: 0.5.2-426-gc5ad4e4+dfsg5-5
> stretch: 0.5.2-426-gc5ad4e4+dfsg5-3+deb9u1
>
> Open security issues:
>
> bookworm: 4
> bullseye: 100
> buster: 124
> stretch: 126
>
> Most of the open vulnerabilities are tagged either  or 
> with the note "Minor issue".  If there were only a small handful, it
> might make sense to not worry about them.  However, given the sheer
> number and the fact that new vulnerabilities are being reported
> regularly, leaving things as is does not appear to be a sensible choice.
>
> As the buster and stretch versions are the same I am working on updating
> both at the same time (coordinated with the security team).  I've
> managed to integrate fixes for about 35 of the open CVEs.  I've also
> been able to identify that several do not actually affect the buster and
> stretch versions of gpac.  I have also encountered now two issues where
> the proof of concept in the upstream GitHub issue produces a failure,
> but not the precise one described by the upstream report and
> subsequently assigned CVE.  It seems likely that there is at least one
> significant vulnerability affecting the older buster/stretch gpac that
> hasn't been discovered/reported upstream.  I have what seems like a
> possible fix for that issue, but it isn't entirely clear that it is the
> right approach (I would seek assistance from upstream on that particualr
> point).
>
> The other concern that I have is that as I move into the more recently
> reported vulnerabilities, which are necessarily fixed in later versions
> by upstream, applying the patches becomes progressivley more
> challenging.  There are still somewhere around 75 vulnerabilities left
> to deal with, which is concerning.
>
> The specific paths forward that I see include:
>
> 
>
> 1. continue plodding through the vulnerabilities and upstream patches,
> trying to make all the patches work (as noted, this is becoming
> increasingly difficult because the newer fixes are made in code that is
> vastly different from what is present in buster/stretch)
>
> 2. drop gpac from stretch LTS support (and buster LTS when it reaches
> that stage)
>
> 3. update the gpac package in one of the following ways:
>
> 3a. apply fixes to the 100 open issues in the bullseye version
> (1.0.1+dfsg1-4+deb11u1) and then backport that to buster and stretch
> (either now in coordination with the security team, or later once buster
> is LTS); I considered this possibility because the fixes are most likely
> more straightforward to apply given the smaller delta betweeen upstream
> releases involved
>
> 3b. backport the bookwork version (2.0.0+dfsg1-2) to bullseye, buster,
> and stretch (definitely must be coordinated with the security team)
>
> 4. don't bother with trying to patch all the vulnerabilities
>
> 
>
> My concern with trying to continue along the current path (#1) is that
> it seems like it will be nearly impossible to properly test this many
> patches.  Something is bound to break and the amount of testing required
> to ensure no breakage or minimal breakage seems very large.
>
> Dropping support for gpac (#2) or updating (#3) it does have some
> additional consequences, as it is not a leaf package.  The first package
> that would be affected by a significant change to gpac is x264.  It has
> a build-depends on libgpac-dev and at least one of its binary packages
> subsequently depends on the associated libgpac runtime library.
>
> The second affected package is ccextractor.  Starting in bookworm,
> ccextractor build depends on libgpac-dev, but its binary package has no
> installation dependencies on any gpac binary packages.  It would require
> a little bit of investigation to determine the specific effect that a
> major gpac update would have on it.
>
> I would very much appreciate feedback/comments/suggestions/etc from
> anyone who would like to contribute to the discussion.  I am certain
> that I have missed things, so feel free to point out any gaps in my
> summary/analysis and of course, any suggestions for other possible
> solutions I overlooked would be very much appreciated.
>
> Regards,
>
> -Roberto
>
> [0] https://tracker.d

Re: Tracking buster/stable updates suited for LTS

[Anton Gladky]

Hi Sylvian,

thanks for your work! Could you please create a merge request,
so we can discuss this nice improvement there?

Regards


Anton


Am Mi., 20. Apr. 2022 um 17:33 Uhr schrieb Sylvain Beucler :

> Now with the patch.
>
> On Wed, Apr 20, 2022 at 05:08:20PM +0200, Sylvain Beucler wrote:
> > During my last front-desk week I noticed that we tend to miss or delay
> > some buster security updates, in particular those that come in point
> > releases, and a few batches of minor postponed fixes.  See for
> > instance, 'dpdk' [1] or 'mailman' [2].
> >
> > Attached is a patch to 'bin/lts-cve-triage.py' to help exhibit those
> > updates so we schedule them in dla-needed.txt.  This includes fixes
> > from stable/oldstable point releases or past DSAs, but excludes issues
> > explicitly ignored, and old fixes from back when buster was unstable.
> >
> > The current output is manageable (40-50 packages), and I plan to trim
> > it further down by properly tagging  some no-dsa issues that
> > are not meant to be fixed in stretch (see e.g. 'ark' [3]), and tagging
> >  a few others (e.g. 'node-*').
> >
> > At this point front-desk can proceed as usual using the enhanced
> > 'lts-cve-triage.py' output.  Front-desk may need to use 'no-dsa'
> > sparingly in the future, in favor of its 'postponed' and 'ignored'
> > sub-states [4], so as to better help the tool.
> >
> > What do you think?
> >
> > Cheers!
> > Sylvain Beucler
> > Debian LTS Team
> >
> > [1] https://security-tracker.debian.org/tracker/source-package/dpdk
> > [2] https://security-tracker.debian.org/tracker/source-package/mailman
> > [3] https://security-tracker.debian.org/tracker/source-package/ark
> > [4]
> https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
>

Re: Tracking buster/stable updates suited for LTS

[Anton Gladky]

Hi Sylvian,

I have just tested the patch and it really produces much more packages
to be triaged and they are really reasonable!

I would propose to merge it into the master branch and start to use it.

Thanks for that!

Anton


Am Mi., 20. Apr. 2022 um 20:54 Uhr schrieb Sylvain Beucler :

> Hi Anton,
>
> There's no need for a MR for this short lts-specific patch, and I
> believe this list has better visibility for the LTS team than the
> security-tracker salsa project (where lts-cve-triage.py resides).
>
> Cheers!
> Sylvain
>
> On 20/04/2022 18:09, Anton Gladky wrote:
> > Hi Sylvian,
> >
> > thanks for your work! Could you please create a merge request,
> > so we can discuss this nice improvement there?
> >
> > Regards
> >
> > Am Mi., 20. Apr. 2022 um 17:33 Uhr schrieb Sylvain Beucler
> > mailto:b...@beuc.net>>:
> >
> > Now with the patch.
> >
> > On Wed, Apr 20, 2022 at 05:08:20PM +0200, Sylvain Beucler wrote:
> >  > During my last front-desk week I noticed that we tend to miss or
> > delay
> >  > some buster security updates, in particular those that come in
> point
> >  > releases, and a few batches of minor postponed fixes.  See for
> >  > instance, 'dpdk' [1] or 'mailman' [2].
> >  >
> >  > Attached is a patch to 'bin/lts-cve-triage.py' to help exhibit
> those
> >  > updates so we schedule them in dla-needed.txt.  This includes
> fixes
> >  > from stable/oldstable point releases or past DSAs, but excludes
> > issues
> >  > explicitly ignored, and old fixes from back when buster was
> unstable.
> >  >
> >  > The current output is manageable (40-50 packages), and I plan to
> trim
> >  > it further down by properly tagging  some no-dsa issues
> that
> >  > are not meant to be fixed in stretch (see e.g. 'ark' [3]), and
> > tagging
> >  >  a few others (e.g. 'node-*').
> >  >
> >  > At this point front-desk can proceed as usual using the enhanced
> >  > 'lts-cve-triage.py' output.  Front-desk may need to use 'no-dsa'
> >  > sparingly in the future, in favor of its 'postponed' and 'ignored'
> >  > sub-states [4], so as to better help the tool.
> >  >
> >  > What do you think?
> >  >
> >  > Cheers!
> >  > Sylvain Beucler
> >  > Debian LTS Team
> >  >
> >  > [1]
> > https://security-tracker.debian.org/tracker/source-package/dpdk
> > <https://security-tracker.debian.org/tracker/source-package/dpdk>
> >  > [2]
> > https://security-tracker.debian.org/tracker/source-package/mailman
> > <https://security-tracker.debian.org/tracker/source-package/mailman>
> >  > [3]
> > https://security-tracker.debian.org/tracker/source-package/ark
> > <https://security-tracker.debian.org/tracker/source-package/ark>
> >  > [4]
> >
> https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
> > <
> https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
> >
>
>

Re: Tracking buster/stable updates suited for LTS

[Anton Gladky]

Hi Sylvain,

Thanks for the update and fixing the unintended commit!

I do really encourage you to use the merge-request
mechanism next time. It is really useful, helps to keep
a discussion in one place and provides easier testing.

Best regards!

Anton


Am Do., 21. Apr. 2022 um 09:08 Uhr schrieb Sylvain Beucler :

> Hi Anton,
>
> Thanks for testing the patch.
>
> I see you committed it by mistake while triaging; I reverted and
> recommitted with proper authorship and commit information (linking this
> thread).
>
> Newly identified packages are ready to be triaged :)
>
> Cheers!
> Sylvain
>
> On 21/04/2022 08:15, Anton Gladky wrote:
> > I have just tested the patch and it really produces much more packages
> > to be triaged and they are really reasonable!
> >
> > I would propose to merge it into the master branch and start to use it.
> >
> > Thanks for that!
> >
> > Am Mi., 20. Apr. 2022 um 20:54 Uhr schrieb Sylvain Beucler
> > mailto:b...@beuc.net>>:
> >
> > Hi Anton,
> >
> > There's no need for a MR for this short lts-specific patch, and I
> > believe this list has better visibility for the LTS team than the
> >     security-tracker salsa project (where lts-cve-triage.py resides).
> >
> > Cheers!
> > Sylvain
> >
> > On 20/04/2022 18:09, Anton Gladky wrote:
> >  > Hi Sylvian,
> >  >
> >  > thanks for your work! Could you please create a merge request,
> >  > so we can discuss this nice improvement there?
> >  >
> >  > Regards
> >  >
> >  > Am Mi., 20. Apr. 2022 um 17:33 Uhr schrieb Sylvain Beucler
> >  > mailto:b...@beuc.net> <mailto:b...@beuc.net
> > <mailto:b...@beuc.net>>>:
> >  >
> >  > Now with the patch.
> >  >
> >  > On Wed, Apr 20, 2022 at 05:08:20PM +0200, Sylvain Beucler
> wrote:
> >  >  > During my last front-desk week I noticed that we tend to
> > miss or
> >  > delay
> >  >  > some buster security updates, in particular those that
> > come in point
> >  >  > releases, and a few batches of minor postponed fixes.  See
> for
> >  >  > instance, 'dpdk' [1] or 'mailman' [2].
> >  >  >
> >  >  > Attached is a patch to 'bin/lts-cve-triage.py' to help
> > exhibit those
> >  >  > updates so we schedule them in dla-needed.txt.  This
> > includes fixes
> >  >  > from stable/oldstable point releases or past DSAs, but
> > excludes
> >  > issues
> >  >  > explicitly ignored, and old fixes from back when buster
> > was unstable.
> >  >  >
> >  >  > The current output is manageable (40-50 packages), and I
> > plan to trim
> >  >  > it further down by properly tagging  some no-dsa
> > issues that
> >  >  > are not meant to be fixed in stretch (see e.g. 'ark' [3]),
> and
> >  > tagging
> >  >  >  a few others (e.g. 'node-*').
> >  >  >
> >  >  > At this point front-desk can proceed as usual using the
> > enhanced
> >  >  > 'lts-cve-triage.py' output.  Front-desk may need to use
> > 'no-dsa'
> >  >  > sparingly in the future, in favor of its 'postponed' and
> > 'ignored'
> >  >  > sub-states [4], so as to better help the tool.
> >  >  >
> >  >  > What do you think?
>
>

Re: [SECURITY] [DLA 2991-1] twisted security update

[Anton Gladky]

Hi Stefano.

congratulations on the first DLA! Good job!

Just a small advice. It would be good to add one line into the DLA
with a short description of the package. Something like this:

"Several issues were discovered in Twisted, an event-based framework
for internet applications..." .
You will find much more examples on the debian-lts-announce mailing list [1].

It can people help to understand what the package is for, whether do
they need to make an update.

[1] https://lists.debian.org/debian-lts-announce/

Best regards


Anton

Am Di., 3. Mai 2022 um 14:22 Uhr schrieb Stefano Rivera :
>
> -
> Debian LTS Advisory DLA-2991-1debian-lts@lists.debian.org
> https://www.debian.org/lts/security/   Stefano Rivera
> May 03, 2022  https://wiki.debian.org/LTS
> -
>
> Package: twisted
> Version: 16.6.0-2+deb9u3
> CVE ID : CVE-2022-24801
> Debian Bug : 1009030
>
> The Twisted Web HTTP 1.1 server, located in the twisted.web.http module, 
> parsed
> several HTTP request constructs more leniently than permitted by RFC 7230. 
> This
> non-conformant parsing can lead to desync if requests pass through multiple
> HTTP parsers, potentially resulting in HTTP request smuggling.
>
> For Debian 9 stretch, this problem has been fixed in version
> 16.6.0-2+deb9u3.
>
> We recommend that you upgrade your twisted packages.
>
> For the detailed security status of twisted please refer to
> its security tracker page at:
> https://security-tracker.debian.org/tracker/twisted
>
> Further information about Debian LTS security advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://wiki.debian.org/LTS

Re: Lintian errors on ffmpeg

[Anton Gladky]

Hi Enrico,

I do sometimes disable lintian and reprotest for the LTS releases.
We are mostly working on security issues and we do unlikely
introduce a new lintian error, providing the minimal patch for the
source code.

When I create a new repo on lts-packages group, I just check, whether
all "jobs" are passing. And if lintian and/or reprotest are failing, I just
disable them. If they are green - that's good and I just leave it enabled.

So I propose you here just modify the debian/.gitlab-ci.yml adding
"SALSA_CI_DISABLE_LINTIAN: 1"
in this case.

Best regards

Anton

Am Mi., 4. Mai 2022 um 13:32 Uhr schrieb Enrico Zini :
>
> On Wed, May 04, 2022 at 12:02:57PM +0200, Santiago Ruano Rincón wrote:
>
> > The rationale about that change (or rather the decision about how to fix
> > broken lintian image/job) is here, after input by lechner:
> > https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/347#note_303815
> >
> > Ideally, I would expect lintian be clever enough to analyse the package
> > according to the target release. But that's not the case, and I can
> > image that's not a simple solution, so we are seeing errors like this
> > you are reporting.
> >
> > Is the current lintian behaviour in Salsa CI broken?
> > Should the lintian job run the lintian version found in ${RELEASE}?
>
> Ok, I'll step out of the conversation on what the Salsa CI should do.
>
> As a takeaway point about my specific issue I'll ignore those specific
> lintian errors on ffmpeg for now.
>
> I also won't add lintian overrides for them, unless someone tells me
> that those errors would cause an upload to be rejected.
>
>
> Enrico
>
> --
> GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Re: Lintian errors on ffmpeg

[Anton Gladky]

Hi Santiago,

well, from my point of view it is better to use the current lintian
the version which is available in the corresponding release, not the
latest one.

If we are working with stable/oldstable/oldoldstable and older versions
we do have to disable or override lintian warnings because the main
work with those releases is just security and some other important fixes.

Maybe it makes sense to add a variable to choose the newer lintian
version if somebody needs it. But it can be too complicated.

Thanks a lot for caring about salsa-ci! It is really useful and convenient!

Best regards

Anton

Am Mi., 4. Mai 2022 um 12:03 Uhr schrieb Santiago Ruano Rincón
:
>
> Hi!
>
> El 04/05/22 a las 10:14, Enrico Zini escribió:
> > On Wed, May 04, 2022 at 08:58:36AM +0100, Neil Williams wrote:
> >
> > > > I'm working at a LTS release of ffmpeg, and the CI is failing with
> > > > Lintian errors that weren't present in the previous version:
> > >
> > > Is the version of lintian in this Salsa CI environment correct for 
> > > Stretch?
> > >
> > > I've seen reports like this in other suites because of problems within
> > > the Salsa images with incorrect versions of lintian.
> >
> > Thanks, I had a closer look.
> >
> > In the pipeline that I've just run[1], I see:
> >
> >$ lintian --version
> >Lintian v2.114.0
> >
> > While in the pipeline run one month ago[1] for a previous upload, I see:
> >
> >$ lintian --version
> >Lintian v2.5.50.4
>
> That was due to a broken behaviour on Salsa CI's side.
>
> >
> > This looks like the relevant change:
> >
> >
> > https://salsa.debian.org/salsa-ci-team/pipeline/-/commit/3eab2b9180b052dc7b3e4d7427a1d561214e2b53
> >which references
> >https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/347
> >
> > I'm adding Santiago to Cc, as I'm unable to evaluate the bigger picture
> > for that change, and so I cannot guess what would be the expected way to
> > deal with errors that come as a consequence of it.
>
> The rationale about that change (or rather the decision about how to fix
> broken lintian image/job) is here, after input by lechner:
> https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/347#note_303815
>
> Ideally, I would expect lintian be clever enough to analyse the package
> according to the target release. But that's not the case, and I can
> image that's not a simple solution, so we are seeing errors like this
> you are reporting.
>
> Is the current lintian behaviour in Salsa CI broken?
> Should the lintian job run the lintian version found in ${RELEASE}?
>
> Cheers,
>
>  -- Santiago
>
> P.S. No need to CC me, I am subscribed to the list.

Re: Urgency for uploads

[Anton Gladky]

Hi Enrico,

regarding the content of d/changelog only. I think it is good
and can be uploaded.

I am not sure, whether the mention "CVE-2021-3566" in
d/changelog will be parsed and this CVE will unintentionally
be closed again in the security database. Please double-check
when you generate DLA.

Best regards

Anton

Am Mi., 4. Mai 2022 um 11:48 Uhr schrieb Enrico Zini :
>
> Hello,
>
> in the Developers's reference[1] it says, in boldface, that security
> updates should be built with "urgency=high".
>
> In ffmpeg's changelog[2] however, everything is urgency=medium.
>
> The LTS/Development wiki page does not mention urgency values.
>
> Should I:
>
> * assume previous ffmpeg uploads used the dch default and start
>   using urgency=high as requested in the devref,
> * assume that LTS uploads don't have the same urgency as non-LTS
>   security uploads, keep urgency=medium, and update LTS/Development
>   accordingly
> * other?
>
>
> [1] 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#preparing-packages-to-address-security-issues
> [2] 
> https://salsa.debian.org/lts-team/packages/ffmpeg/-/blob/debian/stretch/debian/changelog
> [3] https://wiki.debian.org/LTS/Development
>
> Enrico
>
> --
> GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Re: [DLA-3007-1] imagemagick security update incomplete

[Anton Gladky]

Thanks, Philipp, for the information.

Andreas, please analyze, whether this failure is related to your changes.
If not - we can try to rebuild.

Regards

Anton

Am Mo., 16. Mai 2022 um 13:26 Uhr schrieb Emilio Pozuelo Monfort
:
>
> On 16/05/2022 11:04, Philipp Hahn wrote:
> > Hello Andreas,
> >
> > The upload of https://packages.debian.org/source/stretch/imagemagick
> > (8:6.9.7.4+dfsg-11+deb9u14) seems to be incomplete: It only includes the
> > architecture-independant files and files for arm64,armel,armhf, but *not*
> > i386,amd64; see
> > http://security.debian.org/debian-security/pool/main/i/imagemagick/ for
> > yourself. Is this known? According to
> > https://lists.debian.org/debian-lts-announce/2022/05/msg00018.html you 
> > prepared
> > te DLA.
>
> Looks like the update failed to build on those two architectures, see
>
> https://buildd.debian.org/status/package.php?p=imagemagick&suite=stretch-security
>
>  From the build log for amd64:
>
> FAIL: tests/validate-formats-disk.tap 1
> FAIL: tests/validate-formats-map.tap 1
> FAIL: tests/validate-formats-memory.tap 1
>
> Cheers,
> Emilio
>

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

[Anton Gladky]

Hello Markus,

thanks for the update! Could you please push your last change into the
git-repo [1] and tag an upload?

 gbp buildpackage --git-tag-only --git-sign-tags
--git-debian-branch=debian/stretch

Regards

[1] https://salsa.debian.org/lts-team/packages/libxml2

Anton

Am Di., 17. Mai 2022 um 01:04 Uhr schrieb Markus Koschany :
>
> -
> Debian LTS Advisory DLA-3012-1debian-lts@lists.debian.org
> https://www.debian.org/lts/security/  Markus Koschany
> May 17, 2022  https://wiki.debian.org/LTS
> -
>
> Package: libxml2
> Version: 2.9.4+dfsg1-2.2+deb9u7
> CVE ID : CVE-2022-29824
> Debian Bug : 1010526
>
> Felix Wilhelm discovered that libxml2, the GNOME XML library, did not 
> correctly
> check for integer overflows or used wrong types for buffer sizes. This could
> result in out-of-bounds writes or other memory errors when working on large,
> multi-gigabyte buffers.
>
> For Debian 9 stretch, this problem has been fixed in version
> 2.9.4+dfsg1-2.2+deb9u7.
>
> We recommend that you upgrade your libxml2 packages.
>
> For the detailed security status of libxml2 please refer to
> its security tracker page at:
> https://security-tracker.debian.org/tracker/libxml2
>
> Further information about Debian LTS security advisories, how to apply
> these updates to your system and frequently asked questions can be
> found at: https://wiki.debian.org/LTS

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

[Anton Gladky]

As far as I understand all of those packages can be
added into the dla-needed without pre-review? Why not just
put all of them together.

OK, maybe with the short note "needs manual checking" or
similar.

Regards

Anton

Am Di., 17. Mai 2022 um 14:43 Uhr schrieb Sylvain Beucler :
>
> Hi,
>
> On 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 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.
>
> Cheers!
> Sylvain Beucler
> Debian LTS Team
>

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

[Anton Gladky]

I agree with Utkarsh, Even one CVE should be
fixed if there are no objective reasons not to do it.

Yes, if it is minor, it can be postponed, but not longer
over a reasonable amount of time.

Regards

Anton

Am Di., 17. Mai 2022 um 14:28 Uhr schrieb Utkarsh Gupta
:
>
> Hi Ola,
>
> On Tue, May 17, 2022 at 12:35 PM Ola Lundqvist  wrote:
> > While triaging today I noticed this rather old CVE. The elog package
> > is clearly vulnerable (at least when looking through the source code).
> > However I noticed that elog is removed (exists in buster and bullseye
> > though) and it has a very low popcon score.
> >
> > Is it worth fixing?
>
> I think this is a " (Fix along with the next DLA)"
> candidate. It doesn't appear to be severe to warrant a DLA
> independently (unless I've overlooked something here).
>
> > If not, we should say that this package is unsupported.
>
> I don't think so. The only open CVE has a fix present. We should only
> mark something as unsupported when there's a solid reason to, for
> instance, the number of CVEs are too much with no or little
> help/cooperation from upstream, et al, et al. In this case, I don't
> think we should mark this as EOL yet.
>
>
> - u
>

Re: pyjwt CVE-2022-29217 and stretch

[Anton Gladky]

Hi Enrico,

please pay attention that marking the CVE as no-dsa for LTS release
means that it still needs to be fixed!

We do not have point releases for o-o-stable so this state can just postpone
the upload, but it still needs to be fixed somehow.

If you feel that the patch is too destructive or something similar
that preserves
a fix for this particular CVE, so the  tag is more appropriate with
corresponding comment.

Best regards

Anton

Am Fr., 10. Juni 2022 um 12:24 Uhr schrieb Enrico Zini :
>
> Hello,
>
> I've been looking and pyjwt and CVE-2022-29217 for stretch.
>
> In theory, the CVE does not apply, because pyjwt < 2.0.0 (stretch has
> 1.4.2) does not support ed25519, which is the algorithm that uses
> the specific PEM header that pygwt was failing to blocklist.
>
> However, the patch at 
> https://github.com/jpadilla/pyjwt/commit/9c528670c455b8d948aff95ed50e22940d1ad3fc#diff-e952a2551c16d8c3865536b2bffb440e37f64fce6c4e23266f8722e1a48e8f19L564
> still introduces a stricter blocklisting of key material for the HMAC
> algorithm (line 188).
>
> I could either mark CVE-2022-29217 as no-dsa for stretch or, if we
> consider the stricter blocklisting worthwhile, prepare a DLA with only
> that part of the patch.
>
> https://security-tracker.debian.org/tracker/CVE-2022-29217 does consider
> the issue as minor, and I would agree, so my call would be to mark this
> as no-dsa.
>
> Let me know if you'd like me to still backport the applicable parts of
> the patch, otherwise I'll mark this as no-dsa in a few days.
>
>
> Enrico
>
> --
> GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 

Re: RFR: openscad update

[Anton Gladky]

Hi Helmut,

I would propose that you are contacting the original openscad maintainer
and ask him, whether you can make a p-u upload for buster (if it is still
possible).

Thus you can get an experience with dealing of such uploads. Anyway, for
LTS we do not have any point releases. So basically it is possible to fix
even those CVEs which are not DSA-considered. But for not-important issue
it is better to pick up several issues (maybe together with some important
ones) and make an upload.

Leaving the package in dla-needed.txt without any action is not a good idea.
Or the upload should be done with the fixes. Or CVEs should be tagged as
 in tracker. In both cases the package should be removed from
dla-needed.txt as well.

The package can stay in dla-needed.txt longer (due to some testing
issues, or waiting for upstream reaction etc.) and it is OK. But simpl
leaving the package in dla-needed without any action can not bring a benefit.

Best regards


Anton

Am Do., 23. Juni 2022 um 17:03 Uhr schrieb Helmut Grohne :
>
> Hi,
>
> I've been looking into updating openscad in buster to fix CVE-2022-0496
> and CVE-2022-0497. They're already fixed in bullseye and later. They are
> input sanitization issues and CVE-2022-0496 needed a little porting of
> the patch. I verified that the provided PoCs for CVE-2022-0496 do
> trigger in an asan/ubsan build and no longer trigger after applying the
> patch. The provided PoC for CVE-2022-0497 did not trigger in an
> asan/ubsan build, but the fix is quite obvious and the PoC looks quite
> sensitive to the memory layout, so that's unsurprising. Beyond the
> build-time test suite, autopkgtests also pass.
>
> Given the buster -> LTS transition, I'm unsure where to upload this to.
> Adam's mail seems to indicate that it's late for the point release.
>
> Full build available at https://subdivi.de/~helmut/openscad_lts/, and
> .debdiff attached. Did I miss anything obvious on the process side?
>
> Helmut

Re: [Debian Wiki] Update of "LTS" by BenWestover

[Anton Gladky]

Thanks, Utkarsh for fixing this!

That is one of the reasons, why we should migrate to the website.

Regards

Anton


Am Sa., 2. Juli 2022 um 08:58 Uhr schrieb Utkarsh Gupta <
guptautkarsh2...@gmail.com>:

> Hello,
>
> Someone (Ben Westover) made 2 (incorrect) revisions to the LTS wiki page:
> https://wiki.debian.org/LTS?action=diff&rev1=88&rev2=89
> https://wiki.debian.org/LTS?action=diff&rev1=89&rev2=90
>
> I've reverted them for now. Will TAL closely and add changes worth keeping.
>
>
> - u
>
> On Sat, Jul 2, 2022 at 3:01 AM Debian Wiki  wrote:
> >
> > Dear Wiki user,
> >
> > You have subscribed to a wiki page or wiki category on "Debian Wiki" for
> change notification.
> >
> > The "LTS" page has been changed by BenWestover:
> > https://wiki.debian.org/LTS?action=diff&rev1=88&rev2=89
> >
> > Comment:
> > Debian 10 is now LTS, 9 is now extended LTS
> >
> >
> >   /!\ For more information see [[LTS/Stretch]], [[LTS/Using]] and
> [[LTS/FAQ]].
> >
> > - LTS time table from June 30,2020
> > + LTS time table from July 1, 2022
> >
> >   ||<:> '''Version''' ||<:> '''support architecture''' ||<:>
> '''schedule''' ||
> >   ||<#F06C47-3> __Previous LTS Releases__ ||
> >   ||<#F06C47> Debian 6 “Squeeze” ||<#F06C47> i386 and
> amd64 ||<#F06C47> until 29th of February 2016 ||
> >   ||<#F06C47> Debian 7 “[[LTS/Wheezy|Wheezy]]”   ||<#F06C47> i386,
> amd64, armel and armhf ||<#F06C47> from 26th April 2016 to 31st May 2018 ||
> >   ||<#F06C47> Debian 8 “[[LTS/Jessie|Jessie]]”   ||<#F06C47> i386,
> amd64, armel and armhf ||<#F06C47> from 17th June 2018 to June 30, 2020  ||
> > + ||<#F06C47> Debian 9 “[[LTS/Stretch|Stretch]]” ||<#F06C47> i386,
> amd64, armel, armhf and arm64  ||<#F06C47> July 6, 2020 to June 30, 2022 ||
> >   ||<#FCED77-3> __'''Current LTS Release(s)'''__ ||
> > - ||<#FCED77> '''Debian 9 “[[LTS/Stretch|Stretch]]”''' ||<#FCED77>
> '''i386, amd64, armel, armhf and arm64'''  ||<#FCED77> '''July 6, 2020 to
> June 30, 2022''' ||
> > + ||<#FCED77> Debian 10 “[[LTS/Buster|Buster]]”  ||<#FCED77> i386,
> amd64, armel, armhf and arm64  ||<#FCED77> July, 2022 to June, 2024  ||
> >   ||<#98fb98-3> __Future LTS Release(s)__ ||
> > - ||<#98fb98> Debian 10 “Buster” ||<#98fb98> i386,
> amd64, armel, armhf and arm64  ||<#98fb98> July, 2022 to June, 2024  ||
> >   ||<#98fb98> Debian 11 “Bullseye”   ||<#98fb98> i386,
> amd64, armel, armhf and arm64  ||<#98fb98> July, 2024 to June, 2026  ||
> >
> >   ||<:> {i} '''Legend:''' ||<#F06C47> End of life ||<#FCED77>
> '''Supported by LTS team'''||<#98fb98> [[DebianOldStable|Supported by
> security and release teams]] ||
>
>

Re: What do do with bullseye minor issues?

[Anton Gladky]

Hi Ola,

thanks for rising this very important question.

Please use this ticket [1] for the discussion. So we will
be able to formulate the common position and put everything
into the documentation.

[1] https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/38

Regards

Anton



Am Do., 14. Juli 2022 um 23:50 Uhr schrieb Ola Lundqvist :

> Hi fellow LTS contributors
>
> 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".
> I know I should not change triaging status for buster, yet but I'm now
> working on setting some best practices to use later on.
>
> The question is what to do with them in general.
>
> Here are some examples.
>
> composer CVE-2022-24828
> e2guardian CVE2021-44273
> bullseye is fixed but I cannot find any trace of a DSA. This must mean
> that it was fixed in a point release without a DSA. I have not
> checked.
> For buster it was marked as no-dsa (Minor issue). Note not proposed
> for point release.
> One of them was unaffected in stretch the other was also marked as
> minor issue for stretch.
>
> The security team have clearly indicated that this is a minor issue so
> I guess it should not be added to dla-needed.
>
> But what should I do? Should I (or rather some future front desk when
> buster is LTS responsibility) change the status from no-dsa to
> ignored?
>
> Or should we change the lts-triage script to not tell that it should be
> ignored?
>
> I'm asking since from earlier discussions we have said that we should
> generally not mark issues as "ignored" unless we really should not fix
> it, because of too intrusive change, backwards compatibility issues
> and the like. Now our triaging script tells us that we should and that
> is contradicting the earlier conclusions we had.
>
> Anyone with good advice?
>
> The other type is CVE-2021-28210 for edk2. It is marked as minor issue
> for buster, but it was fixed in the scope of a DLA for stretch.
>
> In this case I'm more inclined to add it to dla-needed with the
> motivation that it was fixed in stretch and if someone upgrade the
> system should not get worse from a security perspective.
> Maybe we should automate the detection of this case in some way.
>
> There are probably more, but now it is getting late for today so I
> will continue checking tomorrow.
>
> Cheers
>
> // Ola
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> |  o...@inguza.como...@debian.org|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
>  ---
>
>

Re: libxslt: some CVEs not fixed in debian buster

[Anton Gladky]

Hi,

thanks for this information. We do not have buster under the LTS
control yet. But your information about possible vulnerable libxslt
is important. We will try to check it.

Regards

Anton


Am Fr., 29. Juli 2022 um 06:31 Uhr schrieb Akira Shibakawa <
arabishi...@gmail.com>:

> Hi,
> CVE-2019-5815 and CVE-2021-30560 are vulnerabilities of libxslt
> included in chromium source code as third-party code.
> And not only chromium but also libxslt upstream has already fixed them.
> https://gitlab.gnome.org/GNOME/libxslt/-/commit/08b62c258
> https://gitlab.gnome.org/GNOME/libxslt/-/commit/50f9c9cd3
>
> Because libxslt in debian buster is older than the fixed version in
> upstream, these bugs are still present in debian buster.
> Is there any plans to fix them in debian buster ?
> (I am wonder why these CVEs are linked to only chromium, not libxslt.)
>
>

Re: updating debian-security-support(.limited) in buster and bullseye (Re: EOL candidates for security-support-ended.deb10 (recap))

[Anton Gladky]

Hi Holger,

thanks for taking care of it!

Regarding your question, if there are not other objections, I would say
please go ahead with an upload (despite python2.7).

Regards


Anton


Am Sa., 13. Aug. 2022 um 11:30 Uhr schrieb Holger Levsen <
hol...@layer-acht.org>:

> On Fri, Aug 12, 2022 at 12:06:21PM +, Holger Levsen wrote:
> > yes, I have uploading debian-security-support to buster for the last
> > point release on my agenda and will do that upload as needed.
>
> As there has now been a date announced for the final buster point release,
> the timeline for this has become:
>
> - today prepare buster branch for release (33% done, see below)
> - today until aug 23: possible further updates to the master branch
>   which then get copied to the buster branch
> - aug 23: upload & SRM bug
> - aug 27: freeze
> - sep 10: buster 10.13 point release
>
> I've prepared the buster branch accordingly, that is, I have copied
> security-support-ended.deb10 from 1:12+2022.08.12 from unstable.
>
> Two questions remain, the first I have just raised in #debian-release:
>
>  given that debian-security-support now has the release number
>  in its version, do you still want additional ~deb11u1 version
>  suffixes? eg debian-security-support is 1:11+2021.03.19, are
>  you fine with 1:11+2022.08.13 now or would you prefer
>  1:11+2022.08.13~deb11u1 ? (sid/bullseye is at 1:12+2022.08.12
>  and will not get ...08.13.)
>  happy to ask this in an SRM bug too :)
>
> (no reply on #d-release yet, though I only asked 15min ago...)
>
> The second question is about security-support-limited, which is not
> versioned atm, though maybe it should. Anyway, the current diff
> between buster and master/unstable/bookworm is:
>
> --- a/security-support-limited
> +++ b/security-support-limited
> @@ -8,24 +8,26 @@
>
>  adnsStub resolver that should only be used with trusted
> recursors
>  binutilsOnly suitable for trusted content; see
> https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
> +cython  Only included for building packages, not running them,
> #975058
>  ganglia See README.Debian.security, only supported behind an
> authenticated HTTP zone, #702775
>  ganglia-web See README.Debian.security, only supported behind an
> authenticated HTTP zone, #702776
> -glpiOnly supported behind an authenticated HTTP zone for
> trusted users
> -golang*See
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking
> +golang.*See
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking
>  kde4libskhtml has no security support upstream, only for use on
> trusted content
> +khtml   khtml has no security support upstream, only for use on
> trusted content, see #1004293
>  libv8-3.14  Not covered by security support, only suitable for
> trusted content
> -ltp Pure Testsuite, only supported on non-production
> non-multiuser systems
>  mozjs   Not covered by security support, only suitable for
> trusted content
>  mozjs24 Not covered by security support, only suitable for
> trusted content
>  mozjs52 Not covered by security support, only suitable for
> trusted content
>  mozjs60 Not covered by security support, only suitable for
> trusted content
> +mozjs68 Not covered by security support, only suitable for
> trusted content, see #959804
> +mozjs78 Not covered by security support, only suitable for
> trusted content, see #959804
>  ocsinventory-server Only supported behind an authenticated HTTP zone
> +python2.7   Only included for building packages, not running them,
> #975058
> +python-stdlib-extensions Only included for building packages, not running
> them, #975058
>  qtwebengine-opensource-src No security support upstream and backports not
> feasible, only for use on trusted content
>  qtwebkitNo security support upstream and backports not feasible,
> only for use on trusted content
>  qtwebkit-opensource-src No security support upstream and backports not
> feasible, only for use on trusted content
>  sql-ledger  Only supported behind an authenticated HTTP zone
>  swftoolsNot covered by security support, only suitable for
> trusted content
>  webkitgtk   No security support upstream and backports not feasible,
> only for use on trusted content
> -wine-gecko-2.21 Not covered by security support, see
> https://bugs.debian.org/804058
> -wine-gecko-2.24  Not
> covered by security support, see https://bugs.debian.org/804058
>  zoneminder  See README.Debian.security, only supported behind an
> authenticated HTTP zone, #922724
>
> I'm leaning towards not updating security-support-limited for buster. What
> do
> you think?
>
>
> --
> cheers,
> Holger
>
>  ⢀⣴⠾⠻⢶⣦⠀
>  ⣾⠁⢠⠒⠀⣿⡁  h

Re: updating debian-security-support(.limited) in buster and bullseye (Re: EOL candidates for security-support-ended.deb10 (recap))

[Anton Gladky]

Hi Holger,

just to clarify the things. If the "-limited" file will be versioned,
I think it is better not to include python2.7 or cython
into the buster-file, as we still support them for buster. But,
some internal scripts should be modified in this case to
use the suffix.

If it remains versioned, well, I do not know then. Maybe it is
better to include them into the "debisan-security-support-limited".

Regards


Anton


Am Mo., 15. Aug. 2022 um 21:11 Uhr schrieb Holger Levsen <
hol...@layer-acht.org>:

> On Mon, Aug 15, 2022 at 07:51:56PM +0200, Anton Gladky wrote:
> > Regarding your question, if there are not other objections, I would say
> > please go ahead with an upload (despite python2.7).
>
> Anton, what do you mean with that python2.7 comment?
>
> pochu also said on irc:
>
>  h01ger: I think it makes sense to merge them, except for the
> [pc]ython
> ones, as python2.7 is fully supported in buster
>
>
> --
> cheers,
> Holger
>
>  ⢀⣴⠾⠻⢶⣦⠀
>  ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
>  ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
>  ⠈⠳⣄
>
> In Germany we don‘t say „Happy Valentine‘s Day, I love you“, we say „ich
> werde
> diesen vom Markt kreierten, konsumorientierten Trend des Kapitalismus nicht
> unterstützen,“ and I think that’s beautiful. (Hazel Brugger)
>

Re: Accepted thunderbird 1:91.13.0-1~deb10u1 (source) into oldstable

[Anton Gladky]

Hi Carsten,

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

Best regards.

Anton


Am Mo., 29. Aug. 2022 um 17:58 Uhr schrieb Debian FTP Masters <
ftpmas...@ftp-master.debian.org>:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Mon, 29 Aug 2022 08:15:33 +0200
> Source: thunderbird
> Architecture: source
> Version: 1:91.13.0-1~deb10u1
> Distribution: buster-security
> Urgency: medium
> Maintainer: Carsten Schoenert 
> Changed-By: Carsten Schoenert 
> Changes:
>  thunderbird (1:91.13.0-1~deb10u1) buster-security; urgency=medium
>  .
>* Rebuild for buster-security
> Checksums-Sha1:
>  288fd9815beda05f078da798dc2933b1a4a106bb 8420
> thunderbird_91.13.0-1~deb10u1.dsc
>  a0d0de06ad8f2a0d7916c2fff5feeaa734f0779b 548696
> thunderbird_91.13.0-1~deb10u1.debian.tar.xz
> Checksums-Sha256:
>  0d7c1b58493ad97b4519f0fb69d6bb48d22d79951f4ec82a2cae15cb8d4e89aa 8420
> thunderbird_91.13.0-1~deb10u1.dsc
>  34fbb1c635a9d527ecb53335e0dd89996368d1436de5fae8e9e26e3af8fa9dcc 548696
> thunderbird_91.13.0-1~deb10u1.debian.tar.xz
> Files:
>  6061e6cd85806d7de4aa95feeef926c9 8420 mail optional
> thunderbird_91.13.0-1~deb10u1.dsc
>  2758c96803b17cfc09a5370d4bc3c2f3 548696 mail optional
> thunderbird_91.13.0-1~deb10u1.debian.tar.xz
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEtw38bxNP7PwBHmKqgwFgFCUdHbAFAmMM2moACgkQgwFgFCUd
> HbD2tA//ScZocOAr8mE6ub8kEt5GsLzi4S9qovQFiEtHGMBwIw3WjZhDmLpG+uwH
> 6PTy3SaTYlopcAhfRMzxpaSphzAGuroALWUjbsLqwfPXbi/Q4KiDWdHEnXuteTTI
> hFRTogyb0hzW42YY1GLyjTaHh1NtB4YrqtzLyyGZz8Lrpsi/i6xzn2ZHLDwGB5yh
> kfsSMYQcUg0l+hbYZvGP+YqcZN+ME4tjczUQBtscP7wxhzeSAXTUgoRfzsfvQ24k
> u4CMeGbNx1UPljm68/lWyit2bqgfYi4YLOEqXdz614I3zCxoZbhTe9BnHP1SZKDO
> vvpMUlOADWswFrfZwGEzvtoLJujl7dAeEbRcbP1qALIHl1QzBUET+lY16lcX6EOX
> gqNzqasEDLKFHr6LDdE9nOU6l8UH6sr4ABTiFj+YiO0ma2xQTUV2oRFpVKwUqULr
> kIocFMrM6+HcX+J2qAaA5e+ILi0jJCLx0wGhL6HJOm51GI703OFhy8rt9rEHd285
> Y2twxetaqhcyiVGp3Y0j/WiXyP1z7rq/YFivyj8nDGJ7puewi8Q7ZtS0528cf2m7
> 9RtRZ+BtZF5tli6lAkMGaRqFZaTNZysQTt4170TGsl+aKzeLK3ScsiChhWFgL610
> B+qCBnBYkp81g/+CKafsMZaK9jEKW8FMZTqtqsS5ISxTCh1D044=
> =9kLz
> -END PGP SIGNATURE-
>
>

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

[Anton Gladky]

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.

Best regards


Anton


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?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>

Re: Updating the LTS/ELTS instructions on freexian.com

[Anton Gladky]

Hi Chris,

I am not sure whether you are able to access this repo [1].
If not - the md-file is in attachment, please update it
and feel free to send me.

b) I am not able to answer right now,. Maybe some other
team members will help.

[1] https://gitlab.com/freexian/organization/website/


Anton


Am Mo., 10. Okt. 2022 um 19:43 Uhr schrieb Chris Lamb :

> Hi friends,
>
> I noticed that some of the URLs on the ELTS instructions page are now
> outdated:
>
>   https://www.freexian.com/lts/extended/docs/how-to-use-extended-lts/
>
> In particular, the references to:
>
>   a) freexian-archive-keyring_2020.09.19_all.deb
>   b) archive-key.gpg
>
> … return a 404.
>
> "a)" simply needs updating to the latest version
> (freexian-archive-keyring_2022.06.08_all.deb), but I'm not sure what
> to do with "b)", as well as how to update these instructions in the
> first place.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
>`-
>
>
+++
type = "docs"
title = "How to use Extended LTS"
date = 2018-05-30T12:13:12+02:00
weight = 100
draft = false
bref = "To benefit from the security updates, you just have to configure APT to use our extended LTS repository"
toc = false
+++

### Adding extended LTS repositories to APT

 Installing the freexian archive GPG key

The extended LTS repositories are signed with the following GPG key:
```
sec   rsa4096 2018-05-28 [SC] [expires: 2025-07-18]
  AB597C4F6F3380BD4B2BEBC2A07310D369055D5A
uid   [ultimate] Extended LTS Repository 
```

To enable this key in your APT configuration, you have the following
choices:

* manually install the freexian-archive-keyring package with `wget http://deb.freexian.com/extended-lts/pool/main/f/freexian-archive-keyring/freexian-archive-keyring_2020.09.19_all.deb && sudo dpkg -i freexian-archive-keyring_2020.09.19_all.deb`
* manually fetch the key with `sudo wget http://deb.freexian.com/extended-lts/archive-key.gpg -O /etc/apt/trusted.gpg.d/freexian-archive-extended-lts.gpg`

You might want to double check that the key fingerprint outputted by
`apt-key finger` matches the one shown above.

 sources.list entries for APT

# For Debian 8 jessie

Here's what you should put in `/etc/apt/sources.list.d/extended-lts.list`:

```
deb http://deb.freexian.com/extended-lts jessie-lts main contrib non-free
```

Note that this repository only contains the security updates, not all
packages from Debian 8. If you want all packages from Debian 8, you
should keep another repository pointing to a Debian 8 mirror.

We do provide a repository combining all Debian 8 packages and our security
updates, but please use it only for small setups:

```
deb http://deb.freexian.com/extended-lts jessie main contrib non-free
```

### Be nice, use local mirrors/caches

There are currently no mirrors of this service and it runs on a single
dedicated server. If you have many machines to keep secure, please
make a local mirror (or use some cache) and point your machines to your
local mirror (or cache) instead of pointing them to the 
repositories provided by Freexian.

Re: Upgrades from Stretch to Bullseye and from Buster to Bookworm broken

[Anton Gladky]

Hi,

thanks for the information. AFAIK skipping releases is not supported.
You have to go through all releases step-by-step.

Regards

Anton



Am Mo., 24. Okt. 2022 um 05:42 Uhr schrieb Otto Kekäläinen :

> Hello LTS team!
>
> Users of Debian LTS are currently affected by a bug that prevents
> skipping Debian releases. If skipping a release is not possible in an
> upgrade, it makes using LTS kind of moot.
>
> For discoverability, I posted a summary and workaround steps at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993755#62
>
> I hope you find this useful.
>
>
> - Otto
>
>

Re: Roll existing backports into ELTS update for distro-info-data?

[Anton Gladky]

Hi Stefano,

I would say we should rely only on release and security suites, Backports
are optional.

Just be sure to provide a smooth upgrade from both release and backport
suites.

Regards

Anton




Am So., 30. Okt. 2022 um 15:08 Uhr schrieb Stefano Rivera <
stefa...@debian.org>:

> I'm an uploader for distro-info-data (a data only package like tzdata,
> mostly useful to distro developers, but also potentially sysadmin
> tools). We try to get updates out to all supported releases, but I
> haven't been updating it in (E)LTS, before I joined Freexian & LTS.
>
> I just did a round of updates now, including LTS, because I can,
> trivially.
>
> I see it in ELTS customer's package lists, but we have never issued an
> update in ELTS. I can do updates for jessie and stretch ELTS, easily
> enough (and fairly quickly), but quickly hit a policy question:
>
> Back in those days, we used to publish distro-info-data updates via
> backports, not stable updates. So there were backports published to both
> stretch-backports and jessie-backports. Backports don't support LTS,
> never mind ELTS.
>
> So should I start (and version) ELTS updates based on the release suite
> or the backport suite? I have to use the latter to ensure that users who
> installed the backport get the update.
>
> Where do we usually stand on existing backports, when issuing updates?
>
> Another option is to just ignore the whole thing, because chances are
> that if nobody has complained yet about old data, maybe they never will :)
>
> SR
>
> --
> Stefano Rivera
>   http://tumbleweed.org.za/
>   +1 415 683 3272
>
>

Re: clickhouse - Please review

[Anton Gladky]

Hi Tobias,

well, having a CI for most of the packages is the goal if it
is technically possible, but is not a dogma. If it is very
difficult or not possible feel free to deactivate some of
the tests or in the worst-case scenario just disable them
completely.

Regards


Anton


Am Di., 1. Nov. 2022 um 11:36 Uhr schrieb Tobias Frost :

> Hi,
>
> I'm currently working on clickhoue for LTS and imported the repository
> to the lts-team group [0].
>
> As per git workflow instructions I ask for an exception to enable CI:
>
> I can't get CI working as during linking it seems to go OOM
> on the salsa workers. I've tried disabling lto (the package does
> uncondtionally on amd64 enable it, already on buster) then the compiling
> will succeed.
>
> However, there will be then a test suit error, due to the salsa CI runners
> are running a more recent than buster kernel, triggering cpuinfo being
> noisy
> on stderr, [1] which fails the testsuite with message alike: [2]
>
>  11: 00802_daylight_saving_time_shift_backwards_at_midnight:
> [ FAIL ] - having stderror:
>  11: Warning in cpuinfo: kernel_max value of 8191 parsed from
> /sys/devices/system/cpu/kernel_max exceeds platform-default limit 1023
>
> As said I believe this is due to the kernel on the CI is newer than
> buster's.
> Buster's value of /sys/devices/system/cpu/kernel_max is (at leas in my
> buster VM) 511
> while in my sid machine it is 8192.
>
> On said buster VM, the package builds correctly and also the test suite
> executes without error.
>
> I expect that the build will fail on the buildds as seem to have recent
> kernels, so I anticipate that I need to disable the offending test for the
> upload
>
> TIA for any feedback you might have…
>
> Cheers,
> --
> tobi
>
> [0] https://salsa.debian.org/lts-team/packages/ClickHouse
> [1] https://bugs.launchpad.net/ubuntu/+source/cpuinfo/+bug/1840847
> [2]
> https://salsa.debian.org/lts-team/packages/ClickHouse/-/jobs/3455769#L1741
>

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

[Anton Gladky]

Hi Sylvain,

thanks for your feedback!

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.

You are right, now the bot "anonymously" creates repos, it will
be changed in the next couple of days.

Best regards

Anton

Am Mo., 7. Nov. 2022 um 09:53 Uhr schrieb 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
>

Re: Status of buster/armel

[Anton Gladky]

Hi Sergio,

armel is not being supported by the LTS as well
as some other platforms. One of reasons is that
we have limited resources so we can only support
only the subset of archs.

Best regards

Anton

Am Fr., 2. Dez. 2022 um 14:21 Uhr schrieb Sergio Callegari
:
>
>  From the LTS web site, I see that armel is not listed among the
> architectures that are given LTS support for buster.
>
> I would like to check that this is indeed the case or whether armel is
> going to come.
>
> On one hand, it is quite understandable that supporting armel today may
> not very desirable from your perspective as it brings a lot of work on
> slow hardware. On the other hand upgrading such old hardware is a pain,
> so having the possibility to keep it at buster until it is eventually
> replaced could be useful.
>
> Thanks for your help and effort,
>
> Best regards,
>
> Sergio
>
>

Re: libappimage lts update

[Anton Gladky]

Hello Scarlett,

thanks for your email!

Please prepare a fix for the package, upload it to your salsa repo, and let
us know.
We will take care of adding the package to the dla-needed list and
preparing all necessary
steps for that.

If you prefer to upload the package on your own, we can also support and
consult you.

Best regards.

Anton


Am Sa., 21. Jan. 2023 um 16:21 Uhr schrieb Scarlett Moore <
scarlett.gately.mo...@gmail.com>:

> Hello,
> The security team pointed me here as Buster is now LTS.
> I am reaching out to see if/how I should update libappimage in buster.
> The bug is https://security-tracker.debian.org/tracker/CVE-2020-25265
> The upstream fix is:
> https://github.com/AppImageCommunity/libappimage/pull/146
> I followed instructions here:
>
> https://lts-team.pages.debian.net/wiki/Development.html#claim-the-issue-in-the-security-tracker-in-dla-needed-txt
>
> and the CVE is not listed. I need to know how I proceed as it stated Do
> not
> add it, frontdesk needs to. I am a maintainer of the package and I do have
> the
> upstream fix.
>
> Thank you for any assistance in the matter.
> Scarlett Moore
> 

Re: RFC: ruby-loofah 2.2.3-1+deb10u2

[Anton Gladky]

Hi Daniel,

congratulations on your first update!

Some notes:

1) to be consistent with all other updates please do not add the suffix
in the version number
2) t is not quite a team upload. Better use "dch --lts" which converts to
"* Non-maintainer upload by the LTS Security Team."
3) Please check, why piuparts is failing on CI.
4) Regarding behavioral change... I cannot evaluate without the context.
Maybe someone else from LTS team or the original maintainer can help.

Best regards

Anton


Am Mo., 13. März 2023 um 23:18 Uhr schrieb Daniel Leidert <
dleid...@debian.org>:

> Hi there,
>
> I prepared my first LTS update. You can find it here:
>
> https://salsa.debian.org/lts-team/packages/ruby-loofah
>
> When I ran some test cases to see if all the vulnerabilities are fixed,
> I discovered that there is a slight behavioral change:
>
> As part of the fix for CVE-2022-23516, loofah will no longer remove
> nested  sections, but escape the tags instead. They also
> adjusted their tests for that. To demonstrate:
>
> This:
>
> 

>
> What do you think? I wonder if that is an acceptable change?
>
> if you have any other feedback, please don't hesitate to leave it here.
>
> Regards, Daniel
>

Re: (E)LTS improved salsa pipeline support

[Anton Gladky]

Hello Emilio,

thanks for this update! I will test it on a couple of projects in the
lts-team namespace
and if everything is OK, we will switch all of them per batch-update.

So, does it mean that we can drop the gitlab-ci.yml almost in all repos and
let it be there only for those, where fine-tuning is needed?

If some tests need to be disabled for one particular package, one need to
include
the new recipe and let the disabled stuff be in the old gitlab-ci.yml?

Can something from this work be proposed for the general salsa-ci
Debian-wide?

Thanks and regards.


Anton


Am Do., 16. März 2023 um 10:34 Uhr schrieb Emilio Pozuelo Monfort <
po...@debian.org>:

> Hi,
>
> I have been working in improving our Salsa pipeline support for LTS and
> ELTS.
> Right now builds were failing for jessie and while stretch builds were
> still
> somewhat working, they were bound to break once the move to
> archive.debian.org
> happens, plus they were only building on a vanilla stretch LTS image
> instead of
> ELTS.
>
> The result is an improved pipeline with better support for both LTS and
> ELTS. [1]
>
> tl;dr:
>
> Just set the CI/CD salsa configuration to:
>
> recipes/lts.yml@lts-team/pipeline
>
> That will automatically work for any *jessie*, *stretch* and *buster*
> branches,
> without needing to add per-branch .gitlab-ci.yml files. However if you
> branches
> aren't set up that way, or if you have other branches (e.g. you're sharing
> the
> repository with other non-LTS branches), or if you need to further
> configure the
> pipelines, you can configure your repository to use debian/gitlab-ci.yml
> and
> include one of the recipes such as buster.yml, or simply include
> debian.yml and
> set RELEASE and whatever other variables your project needs. Note that
> we're
> limiting the images that we build to the LTS/ELTS releases, so this won't
> work
> for bullseye atm. I'd be happy to add support for that if that helped
> anybody.
>
> Also note that one of the differences wrt the main pipeline is that this
> runs
> lintian and blhc from the release instead of the sid version, which IMHO
> makes
> more sense.
>
> Feedback welcome!
>
> Cheers,
> Emilio
>
> [1] https://salsa.debian.org/lts-team/pipeline
>
>

Re: (E)LTS improved salsa pipeline support

[Anton Gladky]

Hello Emilio,

could you please provide an example, how the pipeline can be prepared?
I set the value here [1], but it looks like the pipeline did not start.

[1] https://salsa.debian.org/lts-team/packages/389-ds-base/-/pipelines

Thanks

Anton

Am Do., 16. März 2023 um 10:34 Uhr schrieb Emilio Pozuelo Monfort <
po...@debian.org>:

> Hi,
>
> I have been working in improving our Salsa pipeline support for LTS and
> ELTS.
> Right now builds were failing for jessie and while stretch builds were
> still
> somewhat working, they were bound to break once the move to
> archive.debian.org
> happens, plus they were only building on a vanilla stretch LTS image
> instead of
> ELTS.
>
> The result is an improved pipeline with better support for both LTS and
> ELTS. [1]
>
> tl;dr:
>
> Just set the CI/CD salsa configuration to:
>
> recipes/lts.yml@lts-team/pipeline
>
> That will automatically work for any *jessie*, *stretch* and *buster*
> branches,
> without needing to add per-branch .gitlab-ci.yml files. However if you
> branches
> aren't set up that way, or if you have other branches (e.g. you're sharing
> the
> repository with other non-LTS branches), or if you need to further
> configure the
> pipelines, you can configure your repository to use debian/gitlab-ci.yml
> and
> include one of the recipes such as buster.yml, or simply include
> debian.yml and
> set RELEASE and whatever other variables your project needs. Note that
> we're
> limiting the images that we build to the LTS/ELTS releases, so this won't
> work
> for bullseye atm. I'd be happy to add support for that if that helped
> anybody.
>
> Also note that one of the differences wrt the main pipeline is that this
> runs
> lintian and blhc from the release instead of the sid version, which IMHO
> makes
> more sense.
>
> Feedback welcome!
>
> Cheers,
> Emilio
>
> [1] https://salsa.debian.org/lts-team/pipeline
>
>

Re: Apache2 => slow progress

[Anton Gladky]

Hi Bastien,

thanks for the information. If you add it into the
NOTES of the dla-needed, the automatic unclaim
will skip it.

Best regards

Anton


Am Mo., 10. Apr. 2023 um 17:18 Uhr schrieb Bastien ROUCARIES <
roucaries.bast...@gmail.com>:

> Hi,
>
> In order to avoid a semi automatic unclaim, I work on apache2 trying
> to reproduce the CVE or at least creating autopkgtest avoiding
> regression.
>
> Bastien
>
>

c-ares, CVE-2023-31147, CVE-2023-31124

[Anton Gladky]

Hi,

two CVEs might be irrelevant for Debian systems. Can they be
tagged as "unaffected"? Or we have some systems, where
/dev/urandom is not existing?

Thanks

Anton

Re: c-ares, CVE-2023-31147, CVE-2023-31124

[Anton Gladky]

Thank you all for your replies!

@Moritz, could you please create an issue with a
the possible proposal, how it should look like?

Best regards

Anton

Am Fr., 23. Juni 2023 um 20:49 Uhr schrieb Ola Lundqvist :
>
> Hi Anton, all
>
> Well even if there are some systems affected I must say that if
> someone have removed urandom the behavior described is expected. I
> mean /dev/urandom is there for a reason. And yes there are better
> functions than rand() but I can hardly see this as a vulnerability. Or
> well it is, but it is the kind of vulnerability when you remove the
> device that provide randomness in the system.
>
> I would have marked them as "minor issue".
>
> Cheers
>
> // Ola
>
>
> On Fri, 23 Jun 2023 at 06:49, Anton Gladky  wrote:
> >
> > Hi,
> >
> > two CVEs might be irrelevant for Debian systems. Can they be
> > tagged as "unaffected"? Or we have some systems, where
> > /dev/urandom is not existing?
> >
> > Thanks
> >
> > Anton
> >
>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> |  o...@inguza.como...@debian.org|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
>  ---

CVE-2023-33460, ruby-yajl affected?

[Anton Gladky]

Hello,

I am looking into CVE-2023-33460 and I am not sure that ruby-yajl
is affected. There is no direct dependency on yajl, where the vulnerability
was detected.

Should ruby-yajl be unmarked as affected by this CVE?

Thank you

Anton

Re: CVE-2023-33460, ruby-yajl affected?

[Anton Gladky]

Thanks all for the discussion.
@Tobias, thanks for marking the CVE in the list.

Best regards

Anton


Am Mi., 5. Juli 2023 um 17:56 Uhr schrieb Tobias Frost :

> On Wed, Jul 05, 2023 at 09:06:15AM +, Bastien Roucaričs wrote:
> > Le mercredi 5 juillet 2023, 04:52:48 UTC Anton Gladky a écrit :
> > > Hello,
> > >
> > > I am looking into CVE-2023-33460 and I am not sure that ruby-yajl
> > > is affected. There is no direct dependency on yajl, where the
> vulnerability
> > > was detected.
> > ruby-yajl include a old version of yajl 1.01.12
> >
> > The vuln code was introduced by
> https://github.com/lloyd/yajl/commit/cfa9f8fcb12d80dd5ebf94f5e6a607aab4d225fb
> in version 2.1.0 in 2010
>
> This matches my investation, however, a small correction: This commit is
> already part of version 2.0.0.
>
> I've added note in data/CVE/list accordingly.
>
> --
> Cheers,
> tobi
>
>

Re: [SECURITY] [DLA 3562-1] orthanc security update

[Anton Gladky]

Hi,

The fix is basically the backport from the bullseye, where the call is
being dropped,
if the configuration does not explicitly allow it.

If you call export, it returns 403. If this is not the case, please share
details.

Regards

Anton


Am Di., 12. Sept. 2023 um 13:30 Uhr schrieb Abhishek Dutt <
duttabhish...@gmail.com>:

> Hi,
> Please look into the vulnerability test that is not supposed to work
> today. Moreover, look into the case where the API is not calling the option
> and is not included in most options. I am not worried about the case where
> option 2 is not working and this has to be done in the case. Therefore I
> would request you to check the details:
>
> 1. DICOM HTTP status 200 OK .
>
> On Tue, Sep 12, 2023 at 1:50 PM Anton Gladky  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> -
>> -
>> Debian LTS Advisory DLA-3562-1debian-lts@lists.debian.org
>> https://www.debian.org/lts/security/ Anton Gladky
>> September 12, 2023https://wiki.debian.org/LTS
>> -
>> -
>>
>> Package: orthanc
>> Version: 1.5.6+dfsg-1+deb10u1
>> CVE ID : CVE-2023-33466
>> Debian Bug : 1040597
>>
>> A security vulnerability was identified in Orthanc, a DICOM server used
>> for
>> medical imaging, whereby authenticated API users had the capability to
>> overwrite
>> arbitrary files and, in certain configurations, execute unauthorized code.
>>
>> This update addresses the issue by backporting a safeguard mechanism: the
>> RestApiWriteToFileSystemEnabled option is now included, and it is set to
>> "true"
>> by default in the /etc/orthanc/orthanc.json configuration file. Should
>> users
>> wish to revert to the previous behavior, they can manually set this option
>> to "true" themselves.
>>
>> For Debian 10 buster, this problem has been fixed in version
>> 1.5.6+dfsg-1+deb10u1.
>>
>> We recommend that you upgrade your orthanc packages.
>>
>> For the detailed security status of orthanc please refer to
>> its security tracker page at:
>> https://security-tracker.debian.org/tracker/orthanc
>>
>> Further information about Debian LTS security advisories, how to apply
>> these updates to your system and frequently asked questions can be
>> found at: https://wiki.debian.org/LTS
>> -BEGIN PGP SIGNATURE-
>>
>> iQIzBAEBCgAdFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmUAHycACgkQ0+Fzg8+n
>> /wbzLw/+OwxSnkOEATh2LGqRA4RwOFzCdCZxQvjRL+gzb6dvM2eG9P0aSs5/Ek2e
>> kd9uSTRUvgkBoH00ku5QXVytXfiSbzEKZFqowRgCOaCTPfEHJDY6xxzXd8uPdfRY
>> ZmaRUuwJDi4Wu0k8HBBZ+47vv8jXCXKLb2Z16aAjKaegCfMINujgMH5N/Ld6RlfX
>> i4Gr+f1YTfwIHssEKj7IWGYd5+uoY/RoRbgWcIRWDjWUQ3a+/evTx8k6OV3E978G
>> x9PC6loQGDZZLCypdhB6paIyKVpwD66h2AnIG5xAK+awv2SW0lb+SywcnJAqyaHa
>> Hu3UvRI3YCSOMVkkuOyQ/GN3PhUOJ0+hhFGsaM9UFWWlZheARpqLSNYHdRRTw5rf
>> XNPDiKkieUL4HC0bQQxuSGf3h71OpHIavfPX7OeysgKz3NfjYBl0l4RbmwQi1kNs
>> 6zfOSPx+5hJbPGoQssMn1j7TWnWnZTOPPrgWVy/PX1JF6y47465gJeoxIQ8tFqbs
>> 8Mx+LeH0HyjteYtVCCMPg1OPATTMSDBzfiY0JUKcowoOanLvL/+0MRH1A2iBcSAw
>> HW3xRLA/6AB14iJGDwN7DyFXIkkNk/pLMM/siSMiBDP2NU68+ortlN6Lec+n7QFF
>> YJAFJqeaLqTLf2fnJ9oUs9fyD3uBioec3uCqcm3rjTt7rsabpT4=
>> =uDem
>> -END PGP SIGNATURE-
>>
>>
>
> --
> Regards,
> Abhishek Dutt
>