(E)LTS report for September 2024
LTS: booth: - Released DLA-3894-1, fixing CVE-2024-3049. - Provided the package for DSA-5777-1, fixing CVE-2024-3049 in bookworm. nghttp2: - Released DLA-3898-1, fixing CVE-2024-28182. - Submitted a package fixing CVE-2024-28182 in the next bookworm point release. php-twig: - Released DLA-3888-1, fixing CVE-2024-45411. puredata: - Released DLA-3895-1, fixing CVE-2023-47480. - Submitted a package fixing CVE-2023-47480 in the next bookworm point release. mediawiki: - Released DLA-3896-1, fixing CVE-2023-51704. ruby-httparty: - Released DLA-3900-1, fixing CVE-2024-22049. ruby-loofah: - Released DLA-3901-1, fixing CVE-2022-23514, CVE-2022-23515 and CVE-2022-23516. ruby-rails-html-sanitizer: - Released DLA-3902-1, fixing CVE-2022-23517, CVE-2022-23518, CVE-2022-23519, CVE-2022-23520 and CVE-2022-32209. sqlite3: - Determined that CVE-2021-31239 does not affect <= bullseye. - Released DLA-3907-1, fixing CVE-2021-36690 and CVE-2023-7104. - Submitted a package fixing CVE-2023-7104 in the next bookworm point release. trafficserver: - Released DLA-3897-1, fixing CVE-2023-38522, CVE-2024-35161 and CVE-2024-35296. wireshark: - Determined that CVE-2021-4183 does not affect bullseye. - Determined that CVE-2023-0414 does not affect bullseye. - Released DLA-3906-1, fixing CVE-2021-4181, CVE-2021-4182, CVE-2021-4184, CVE-2021-4185, CVE-2021-4186, CVE-2021-4190, CVE-2022-0581, CVE-2022-0582, CVE-2022-0583, CVE-2022-0585, CVE-2022-0586, CVE-2022-3190, CVE-2022-4344, CVE-2022-4345, CVE-2023-0411, CVE-2023-0412, CVE-2023-0413, CVE-2023-0415, CVE-2023-0416, CVE-2023-0417, CVE-2023-0666, CVE-2023-0667, CVE-2023-0668, CVE-2023-1161, CVE-2023-1992, CVE-2023-1993, CVE-2023-1994, CVE-2023-2855, CVE-2023-2856, CVE-2023-2858, CVE-2023-2879, CVE-2023-2906, CVE-2023-2952, CVE-2023-3648, CVE-2023-3649, CVE-2023-4511, CVE-2023-4512, CVE-2023-4513, CVE-2023-6175, CVE-2024-0208, CVE-2024-0209, CVE-2024-0211, CVE-2024-2955, CVE-2024-4853, CVE-2024-4854, CVE-2024-8250 and CVE-2024-8645. - Submitted a package fixing CVE-2024-0208, CVE-2024-0209, CVE-2024-0211, CVE-2024-2955, CVE-2024-4853, CVE-2024-4854, CVE-2024-4855, CVE-2024-8250 and CVE-2024-8645 in the next bookworm point release. ELTS: iproute2: - Released ELA-1185-1, fixing CVE-2019-20795 in buster. libpam-tacplus: - Released ELA-1180-1, fixing CVE-2016-20014 in buster. sqlite3: - Released ELA-1191-1, fixing CVE-2019-19244, CVE-2021-36690 and CVE-2023-7104 in buster. wireshark: - Determined that CVE-2024-0209 does not affect buster. - Released ELA-1188-1, fixing CVE-2023-0667, CVE-2023-3649, CVE-2023-4512, CVE-2024-0211, CVE-2024-2955, CVE-2024-4853, CVE-2024-4854, CVE-2024-8250 and CVE-2024-8645 in buster and stretch. zeromq3: - Determined that CVE-2021-20237 does not affect jessie. - Released ELA-1184-1, fixing CVE-2021-20234, CVE-2021-20235 and CVE-2021-20237 in buster.
Re: bullseye-security arm64 buildds seem to be broken
On Thu, Sep 12, 2024 at 12:46:08AM +0200, Ben Hutchings wrote: > Building linux-6.1 in the bullseye-security suite for arm64 has been > attempted and failed on 4 different buildds today, with the messages: > > E: /srv/chroot/bullseye_arm64.tar.gz: Failed to stat file: No such file or > directory > E: session:: Chroot not found > chroot:bullseye-security-arm64-sbuild chroot does not exist > E: Error creating chroot session: skipping linux-6.1 The problem was also on armhf, and it built now on both architectures. buildd chroots are regenerated on Wednesdays and Sundays and the successful builds were after Wednesday regeneration, so I guess that fixed it. I don't know what broke it. > Ben. cu Adrian
(E)LTS report for August 2024
LTS: amanda: - Released DLA-3880-1, fixing CVE-2022-37703, CVE-2022-37704, CVE-2022-37705 and CVE-2023-30577. aom: - Released DLA-3881-1, fixing CVE-2024-5171. bluez: - Released DLA-3879-1, fixing CVE-2021-3658, CVE-2021-41229, CVE-2021-43400, CVE-2022-0204, CVE-2022-39176, CVE-2022-39177, CVE-2023-27349, CVE-2023-50229 and CVE-2023-50230. calibre: - Released DLA-3862-1, fixing CVE-2021-44686 and CVE-2023-46303. exfatprogs: - Released DLA-3861-1, fixing CVE-2023-45897. libxml2: - Released DLA-3878-1, fixing CVE-2016-3709 and CVE-2022-2309. systemd: - Released DLA-3859-1, fixing CVE-2023-7008, CVE-2023-50387 and CVE-2023-50868. ELTS: bluez: - Released ELA-1177-1, fixing CVE-2023-50229 CVE-2023-50230 in stretch and buster, and CVE-2023-27349 in stretch. gdk-pixbuf: - Released ELA-1151-1, fixing CVE-2022-48622 in jessie, stretch and buster. hsqldb1.8.0: - Released ELA-1178-1, fixing CVE-2023-1183 in jessie. indent: - Released ELA-1156-1, fixing CVE-2023-40305 and CVE-2024-0911 in buster. libxml2: - Released ELA-1176-1, fixing CVE-2022-2309 in jessie, stretch and buster and CVE-2016-3709 in buster. python-aiosmtpd: - Released ELA-1147-1, fixing CVE-2024-27305 and CVE-2024-34083 in buster. systemd: - Determined that CVE-2023-50387 does not affect jessie. - Determined that CVE-2023-50868 does not affect jessie. - Fixed the autopkgtest in stretch and buster. - Released ELA-1165-1, fixing CVE-2023-7008, CVE-2023-50387 and CVE-2023-50868 in stretch and buster. suricata: - Determined that CVE-2024-32663 does not affect <= buster. - Determined that CVE-2024-38535 does not affect <= buster. - Released ELA-1162-1, fixing CVE-2019-10050, CVE-2019-10051, CVE-2019-10052, CVE-2019-10053, CVE-2019-10054, CVE-2019-10055, CVE-2019-10056, CVE-2019-15699, CVE-2019-16410, CVE-2019-16411, CVE-2019-18625, CVE-2019-18792, CVE-2019-1010279, CVE-2021-35063, CVE-2021-37592 and CVE-2024-37151 in buster. wpa: - Released ELA-1153-1, fixing CVE-2024-5290 in jessie, stretch and buster. Note: Some of the above advisories were published in September, but are listed for August (and won't be listed in September) since most of the work was done in August.
Re: bullseye-security upload queue open (was: [SECURITY] [DLA 3856-1] python-html-sanitizer security update)
Hi Aurelien, On Tue, Sep 03, 2024 at 07:17:08PM +0200, Aurelien Jarno wrote: > On 2024-08-31 11:29, Santiago Ruano Rincón wrote: > > El 31/08/24 a las 16:43, Adrian Bunk escribió: > > > On Sat, Aug 31, 2024 at 10:12:19AM -0300, Santiago Ruano Rincón wrote: > > > >... > > > > It seems the bullseye-security upload queue is finally open (now that > > > > the point release has been published). > > > >... > > > > > > Are you talking only about the ftp side, or also about the buildd side? > > > > > > https://buildd.debian.org/ still looks wrong, that's why I'm asking. > > > > I cannot really tell, I am afraid. Adding the FTP team and Buildd Teams > > to the loop to ask for their help. > > Can please you tell us what is wrong on buildd.d.o? Not knowning the > issue, it is difficult to fix it. > > Just a few details on the wanna-build / buildd side to avoid the usual > endless and useless discussions: > - The buildds are able to handle LTS builds since a bit before the > release of Bullseye, as the choice is now to reuse the existing > -security suite. Nothing has to be done besides making the suites > public on the web interface. > - The bullseye-security suite was made public on Aug 19. > - The non-LTS architecture got removed from wanna-build on Aug 31 after > the release of the latest Bullseye point release. I replied to Santiago sending the "upload queue is finally open" email, this was after the move of wuiet to faster hardware but before you removed the non-LTS architectures. Regarding the buildd side, removing the non-LTS architectures from bullseye-security was desirable before doing LTS uploads. It all got overshadowed by the ftp team making the required changes to bullseye-security only after the point release, and them being unresponsive in the two weeks before that. > Regards > Aurelien cu Adrian
Re: bullseye-security upload queue open (was: [SECURITY] [DLA 3856-1] python-html-sanitizer security update)
On Sat, Aug 31, 2024 at 10:12:19AM -0300, Santiago Ruano Rincón wrote: >... > It seems the bullseye-security upload queue is finally open (now that > the point release has been published). >... Are you talking only about the ftp side, or also about the buildd side? https://buildd.debian.org/ still looks wrong, that's why I'm asking. > -- Santiago cu Adrian
Re: [SECURITY] [DLA 3856-1] python-html-sanitizer security update
Hi, where has the binary package been built, and where is it available for our users to download? Except for this announcement, I have not seen traces of it anywhere. cu Adrian On Mon, Aug 26, 2024 at 04:55:35PM +0100, Chris Lamb wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > - - > Debian LTS Advisory DLA-3856-1debian-lts@lists.debian.org > https://www.debian.org/lts/security/ Chris Lamb > August 26, 2024 https://wiki.debian.org/LTS > - - > > Package: python-html-sanitizer > Version: 1.9.1-2+deb11u1 > CVE ID : CVE-2024-34078 > Debian Bug : 1070710 > > It was discovered that there was a sanitisation bypass issue in > python-html-sanitizer, a library used ensure that user-specified > content cannot inject HTML or JavaScript into a webpage. > > If the default "keep_typographic_whitespace=False" value was set, > malicous users could have exploited the fact that some Unicode > characters normalise to chevrons, which allowed specially-crafted > HTML to escape sanitization. > > For Debian 11 bullseye, this problem has been fixed in version > 1.9.1-2+deb11u1. > > We recommend that you upgrade your python-html-sanitizer packages. > > For the detailed security status of python-html-sanitizer please refer to > its security tracker page at: > https://security-tracker.debian.org/tracker/python-html-sanitizer > > 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- > > iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAmbModMACgkQHpU+J9Qx > HljLvhAAriMt4e8j+vTlDJzh+eaNhfcGNhetCdeQBvhy0W80eFs3znusramI3A/s > R1TIrj8fOhWg9NMLwwUs9/OHHAtGUEIrmluj8RfQD4cMOKjWbDXgnxqNQzg1+njD > ZLnO3OvMAneXz52C4A5ts47RGJswhFASEd2WHCpsH5FjtbzqQDRe/auVjOe4Lf3v > Fk8Fo4Y98M4JBfPKOGECXajjUvhSSuhKCVURiybkqoc9RCVocBy/8ukG8lfB8Bhe > zRz9/Dfbj/Ftljgg4LDuYvA0x5vQR5d4MPl5R/ON/vS7RlkW8LUL1eyLpjdZyj1I > Pg3ihhg0gzXFPCYMNQmLxsnDfWSTBahXtSxNw81+SPwd/IBi6OE9pTSP/tgGu6oI > dCti9nzeglNqtakLthtq13UklDrD9MqgZoRmNnVgTdyHPgas3ZL8qbzQbrZJSFvs > tLhnLwNm+ASECbKcceJxiT11Yyn6pn0j4MCCg5xw99cCcnh9DawCcfXJ2DF/oipZ > aEP0G0Gs7eFsPi2nVVVQfZARfenN71mtiPTGkZ5whSyhZT8/QbrRKEjpexLqgMmg > VeqTbKkxSTECC7rJtneq7/dZXDdobsveuRfcmwK9btwGpiqPUot5CqjuT0e8lzPV > O5iRTL5EONTqt6kJMK3t6myy6MGZYBHfDbfYVzi+tIBtPNWMcoQ= > =QfUA > -END PGP SIGNATURE-
wb: bullseye-security still configured for all architectures?
Hi, looking at [1], bullseye-security still lists all architectures for bullseye-security. Intended[2] is the same architecture list as was for buster-security (all amd64 arm64 armhf i386). cu Adrian [1] https://buildd.debian.org/ [2] https://wiki.debian.org/LTS
ELTS report for July 2024
aom: - Released ELA-1143-1, fixing CVE-2024-5171 in buster. binutils: - Released ELA-1130-1, fixing CVE-2018-12934 and CVE-2018-1000876 in jessie, stretch and buster. krb5: - Determined that CVE-2024-26462 does not affect <= bullseye. - Released ELA-1141-1, fixing CVE-2024-26458, CVE-2024-26461, CVE-2024-37370 and CVE-2024-37371 in jessie, stretch and buster. python2.7: - Determined that python2.7 is not affected by CVE-2024-4032. - Determined that CVE-2024-5642 does not affect the python2.7 packages in buster. python3.4: - Fixed the autopkgtest. - Fixed build test failures and made them fatal. - Released ELA-1138-1, fixing CVE-2024-4032 and CVE-2024-5642 in jessie. python3.5: - Fixed the autopkgtest. - Fixed build test failures and made them fatal. - Released ELA-1137-1, fixing CVE-2024-0397, CVE-2024-4032 and CVE-2024-5642 in stretch. python3.7: - Determined that CVE-2024-5642 does not affect the python3 packages in buster or bullseye. - Fixed the autopkgtest. - Fixed build test failures and made them fatal. - Released ELA-1135-1, fixing CVE-2024-0397 and CVE-2024-4032 in buster.
(E)LTS report for June 2024
LTS: cyrus-imapd: - Marked CVE-2024-34055 (sole unfixed CVE) as ignored due to being too intrusive to backport, following upstream and bullseye. dcmtk: - Determined that CVE-2024-27628 does not affect <= bullseye - Released DLA-3847-1, fixing CVE-2021-41687, CVE-2021-41688 CVE-2021-41689, CVE-2021-41690, CVE-2022-2121, CVE-2022-43272, CVE-2024-28130, CVE-2024-34508 and CVE-2024-34509. glibc: - Released DLA-3850-1, fixing CVE-2024-33599, CVE-2024-33600, CVE-2024-33601 and CVE-2024-33602. libvpx: - Released DLA-3830-1, fixing CVE-2024-5197. - Provided the packages for DSA-5722-1, fixing the CVE also in for bullseye and bookworm. nano: - Released DLA-3831-1, fixing CVE-2024-5742. - Submitted updates with the CVE fix for bullseye and bookworm, they were included in the Debian 11.10 and 12.6 point releases. plasma-workspace: - Determined that CVE-2024-1433 does not affect <= bullseye, but does affect plasma-framework. - Released DLA-3827-1, fixing CVE-2024-36041. - Provided the packages for DSA-5723-1, fixing the CVE also in for bullseye and bookworm. sredird: - Discussed with the security team that CVE-2004-2386 (sole unfixed CVE) is considered to refer only to a vulnerability that was fixed in Debian 20 years ago. ELTS: dcmtk: - Released ELA-1118-1, fixing CVE-2019-1010228, CVE-2021-41687, CVE-2021-41688, CVE-2021-41689, CVE-2021-41690, CVE-2022-2121, CVE-2022-43272, CVE-2024-28130, CVE-2024-34508 and CVE-2024-34509 in stretch. glibc: - Released ELA-1119-1, fixing CVE-2024-33599, CVE-2024-33600, CVE-2024-33601 and CVE-2024-33602 in jessie and stretch. libvpx: - Determined that CVE-2016-3881 does not affect jessie. - Released ELA-1112-1, fixing CVE-2024-5197 in jessie and stretch, and CVE-2016-6711 and CVE-2017-0393 in jessie. nano: - Released ELA-1109-1, fixing CVE-2024-5742 in jessie and stretch.
Re: Opencryptoki fixes for CVE-2024-0914
On Sat, Jun 22, 2024 at 11:04:49AM +, Bastien Roucariès wrote: > Hi, Hi Bastien, > After a few hours I get the impression that fixing CVE-2024-0914 even for > bookworm will be extremly hard (lack of constant time operation, massive code > change...) > > I suppose the best way is to a full bakport of unstable way to buster and for > ELTS to stretch/jessie > > What it your point of view about this ? after a quick look, backporting the latest openCryptoki to jessie might be more work than backporting the fixes to the version in jessie since you have to revert the OpenSSL API changes. The CVE is marked " (Minor issue)" in (old)stable, and CVE-2022-4304 for the same issue is ignored in OpenSSL 1.0 in jessie and stretch. If backporting to older openCryptoki versions is not feasible, I'd suggest to ignore the CVE. > Bastien cu Adrian
(E)LTS report for May 2024
LTS: glibc: - Released DLA-3807-1, fixing CVE-2024-2961. - Fixed and enabled the build tests and autopkgtest. gst-plugins-base1.0: - Released DLA-3824-1, fixing CVE-2024-4453. libkf5ksieve: - Released DLA-3809-1, fixing CVE-2023-52723. ELTS: glibc: - Released ELA-1087-11, fixing CVE-2024-2961 in jessie and stretch. - Fixed and enabled the build tests and autopkgtest in stretch. gst-plugins-base1.0: - Released ELA-1102-1, fixing CVE-2024-4453 in jessie and stretch. inetutils: - Released ELA-1103-1, fixing CVE-2019-0053 and CVE-2023-40303 in stretch. Additionally, work was done on dcmtk and glibc for DLAs/ELAs to be released in June.
(E)LTS report for April 2024
LTS: glibc: - First part of work released as DLA-3807-1 in May. gtkwave: - DLA-3785-1 and DSA-5653-1 were released in April, but the actual work was done and submitted for review in March. pillow: - Determined that CVE-2021-25291 does not affect buster. - Released DLA-3786-1, fixing CVE-2024-28219. ruby-rack: - Released DLA-3800-1, fixing CVE-2024-25126, CVE-2024-26141 and CVE-2024-26146. - These fixes were also uploaded to unstables and submitted for bullseye and bookworm. trafficserver: - Released DLA-3799-1, fixing CVE-2024-31309. zabbix: - Determined that CVE-2022-40626 does not affect <= bullseye - Released DLA-3798-1, fixing CVE-2024-22119. xorg-server: - Released DLA-3787-1, fixing CVE-2024-31080, CVE-2024-31081 and CVE-2024-31083. ELTS: glibc: - First part of work released as ELA-1087-1 in May for jessie and stretch openexr: - Determined that CVE-2024-31047 does not affect the binary packages in stretch or buster. pillow: - Released ELA-1079-1, fixing CVE-2024-28219 in jessie and stretch. ruby-rack: - Determined that CVE-2024-25126 does not affect jessie or stretch. - Released ELA-1081-1, fixing CVE-2024-26141 and CVE-2024-26146 in stretch. zabbix: - Determined that CVE-2024-22119 (sole remaining not ignored CVE) does not affect jessie or stretch. xorg-server: - Released ELA-1072-1, fixing CVE-2024-31080, CVE-2024-31081 and CVE-2024-31083 in jessie and stretch.
Re: bind9 LTS
On Sun, Mar 31, 2024 at 10:12:34PM +0800, Sean Whitton wrote: >... > - looks like backporting the old branches is what's done in bullseye and > bookworm; do you know of some reason we're not doing this for buster too? bind9 in buster provides shared libraries, with soversion changes in every release. > - CVE-2023-50387 and CVE-2023-50868 are both DoS vulnerabilities for > DNSSEC. The fixes for CVE-2023-50387 is large, and I am not sure > there is one for CVE-2023-50868 for bind-9.11. It's the same fix for both. > I think that these fixes are too intrusive to fix by backporting, > unless we decide to start backporting whole upstream 9.11.y releases. >... Fixing KeyTrap might be possible. The change that breaks ABI looks unnecessary to me even when including the commit that introduces it, which might anyway not be desirable since it might break existing setups. Testing everything really carefully is surely the hardest part. > Sean Whitton cu Adrian
Re: How to handle freeimage package
On Thu, Apr 11, 2024 at 09:34:00PM +0200, Ola Lundqvist wrote: >... > On Thu, 11 Apr 2024 at 15:34, Santiago Ruano Rincón > wrote: > ... > > Taking one of the recent changes to data/CVE/list: > > > > @@ -6999,6 +7000,7 @@ CVE-2024-28579 (Buffer Overflow vulnerability in open > > source FreeImage v.3.19.0 > > - freeimage (bug #1068461) > > [bookworm] - freeimage (Revisit when fixed upstream) > > [bullseye] - freeimage (Revisit when fixed upstream) > > + [buster] - freeimage (Revisit when fixed upstream, low > > severity DoS in tool) > > NOTE: > > https://github.com/Ruanxingzhi/vul-report/tree/master/freeimage-r1909 > > > > Are you completely sure the related buffer overflow doesn't make > > possible to cause arbitrary code execution. > > Can one be completely sure about anything? So, no I'm not completely > sure. I have worked long enough to learn that even if I think I'm > right I may not be. The only thing you can be sure about is that the PoC reproduces the CVE without your fix, and does no longer reproduce it with your fix. > I'm pretty sure that the ones that mention code execution are more severe. >... I'm pretty sure this is not a realistic assumption. Everyone who has done CVE fixing in recent years knows that fuzzer CVEs are relatively nice to handle since they usually come with a PoC and tend to have a short fix, but the CVE descriptions are often garbage since many of the CVE reporters do not have any clue how an exploit would work. > // Ola cu Adrian
Re: How to handle freeimage package
On Thu, Apr 11, 2024 at 10:34:13AM -0300, Santiago Ruano Rincón wrote: >... > El 11/04/24 a las 08:25, Ola Lundqvist escribió: >... > > The ones I have now postponed are of the "local DoS" class. I'm here > > interpreting that "local DoS" is the same as DoS after human > > interaction. It is not entirely accurate but similar enough for > > triaging decision. See my other mail thread about triaging guide. > > > > I have not postponed any of the ones of type "permits code execution > > after user interaction" yet. > > Taking one of the recent changes to data/CVE/list: > > @@ -6999,6 +7000,7 @@ CVE-2024-28579 (Buffer Overflow vulnerability in open > source FreeImage v.3.19.0 > - freeimage (bug #1068461) > [bookworm] - freeimage (Revisit when fixed upstream) > [bullseye] - freeimage (Revisit when fixed upstream) > + [buster] - freeimage (Revisit when fixed upstream, low > severity DoS in tool) > NOTE: > https://github.com/Ruanxingzhi/vul-report/tree/master/freeimage-r1909 > > Are you completely sure the related buffer overflow doesn't make > possible to cause arbitrary code execution. Are you 100% sure it is > limited to a local DoS? For being on the safe side, I would just left as > note (Revisit when fixed upstream). Fellows doing FD work could also > confirm if this is correct or not. >... "in tool" looks wrong in any case. The 21 new CVEs were from a fuzzer who was using a trivial tool that uses the library APIs to load and unload images: https://github.com/Ruanxingzhi/vul-report/blob/master/freeimage-r1909/poc.c (I assume poc.c is a polished version of the work.cpp in the traces) > Cheers, > > -- Santiago cu Adrian
Re: How to handle freeimage package
On Wed, Apr 10, 2024 at 10:08:51PM +0200, Ola Lundqvist wrote: > Hi all Hi Ola, > Sorry for late reply. It took me too long today to answer the CVE > triaging discussion. Now to this issue. > > Regarding the fedora patches. The patches seem to help for those > specific issues they solve. > > My intention for claiming the package was to go through the CVEs and > mark them with postponed or similar. > When I'm done with that maybe I will start to fix things, but I > claimed it just to avoid double work when going through the issues. > > I'll start with that now and I hope I can release the package when I'm > done with that. I'll re-claim it when/if I think they are worth > fixing. > > What is clear after checking all reverse dependencies is that all > software packages using freeimage library are of the "tool" type. You > run it with human interaction and the user using the tool should know > the input. This reduces the severity of the problems. your claims cannot be trusted. It might even be technically true that an Image Viewer for a Desktop Environment is a "tool" that "runs with human interaction", but "the user using the tool should know the input" is an absurd claim. Please correct me if I am wrong, but as far as I can see the last time you have published a DLA or ELA was 4 years ago. Your non-involvement in actual work likely explains why you have so many questions, and why you make suggestions without practical relevance. Your non-involvement in actual work likely explains some of your many mistakes when touching CVE metadata and dla-needed. Your game of claiming packages in dla-needed and then doing whatever it takes to "handle" them while doing zero actual work might cause serious harm. > Cheers > > // Ola cu Adrian
Re: How to handle freeimage package
On Wed, Apr 10, 2024 at 12:17:33PM -0400, Roberto C. Sánchez wrote: > On Mon, Apr 08, 2024 at 07:56:40PM +0300, Adrian Bunk wrote: > > On Mon, Apr 08, 2024 at 05:34:47PM +0200, Moritz Muehlenhoff wrote: > > > > > > So a useful next step would be to break those reports down into separate > > > bug reports and file them there so that upstream actually learns about > > > them. > > > > I don't think that makes much sense. > > > > When I checked, the last activity from upstream in the bug tracker was > > a year ago. > > > > Some of the older CVEs are fixed in the upstream VCS, but there are > > unfixed ones in the bug tracker going back to 2020. > > > > The 2024 CVEs are 21 buffer overflows and 2 NULL pointer dereferences, > > there is likely a lot of low hanging fruit one could fix (and then > > forward upstream) when spending 2 or 3 days on the package. > > > Even if upstream is dead, dormant, or not acting on bug reports, I agree > with Moritz that submitting the reports upstream (to SourceForge) is > still good and something that we should make an effort to do. > > First, the bugs are in fact upstream bugs and if we can break them down, > identify, fix them, and then forward the fixes (as patches or PRs) > upstream, others will be able to find the issues and the related fixes. > Second, it seems like we would have to do all of those things (except > the "forward to upstream" part) in any case to fix the CVEs for LTS, so > the "forward to upstream" step is a only a very small additional step. My point was that an opposite approach of doing only "file upstream bugs and wait for upstream to fix the CVEs" is unlikely to have a positive outcome in this case. Forwarding fixes upstream is of course desirable, even when upstream is dead. > > For me it was an "I don't want to do that right now" and I didn't work > > on the package at that point, but I don't see a technical reason against > > someone fixing the CVEs. > > So, whoever is working on freeimage (Ola?) should take into account that > this is part of what needs to be done. > > Regards, > > -Roberto cu Adrian
(E)LTS report for March 2024
LTS: cpio: - Added note that upstream considers CVE-2023-7216 (sole unfixed CVE) normal behavior. fontforge: - Released DLA-3754-1, fixing CVE-2020-5395, CVE-2020-5496, CVE-2024-25081 and CVE-2024-25082. - Fixed CVE-2024-25081 and CVE-2024-25082 in sid. - Fixed CVE-2024-25081 and CVE-2024-25082 as DSA-5641-1 in bullseye and bookworm. gtkwave: - Released DLA-3785-1, upgrading to a new upstream version fixing CVE-2023-32650 CVE-2023-34087 CVE-2023-34436 CVE-2023-35004 CVE-2023-35057 CVE-2023-35128 CVE-2023-35702 CVE-2023-35703 CVE-2023-35704 CVE-2023-35955 CVE-2023-35956 CVE-2023-35957 CVE-2023-35958 CVE-2023-35959 CVE-2023-35960 CVE-2023-35961 CVE-2023-35962 CVE-2023-35963 CVE-2023-35964 CVE-2023-35969 CVE-2023-35970 CVE-2023-35989 CVE-2023-35992 CVE-2023-35994 CVE-2023-35995 CVE-2023-35996 CVE-2023-35997 CVE-2023-36746 CVE-2023-36747 CVE-2023-36861 CVE-2023-36864 CVE-2023-36915 CVE-2023-36916 CVE-2023-37282 CVE-2023-37416 CVE-2023-37417 CVE-2023-37418 CVE-2023-37419 CVE-2023-37420 CVE-2023-37442 CVE-2023-37443 CVE-2023-37444 CVE-2023-37445 CVE-2023-37446 CVE-2023-37447 CVE-2023-37573 CVE-2023-37574 CVE-2023-37575 CVE-2023-37576 CVE-2023-37577 CVE-2023-37578 CVE-2023-37921 CVE-2023-37922 CVE-2023-37923 CVE-2023-38583 CVE-2023-38618 CVE-2023-38619 CVE-2023-38620 CVE-2023-38621 CVE-2023-38622 CVE-2023-38623 CVE-2023-38648 CVE-2023-38649 CVE-2023-38650 CVE-2023-38651 CVE-2023-38652 CVE-2023-38653 CVE-2023-38657 CVE-2023-39234 CVE-2023-39235 CVE-2023-39270 CVE-2023-39271 CVE-2023-39272 CVE-2023-39273 CVE-2023-39274 CVE-2023-39275 CVE-2023-39316 CVE-2023-39317 CVE-2023-39413 CVE-2023-39414 CVE-2023-39443 CVE-2023-39444 - Submitted a similar upgrade to unstable. - Submitted similar upgrades to bullseye-security and bookworm-security, where they were released as DSA-5653-1. - The DSA and DLA were released in April, but they are listed here since all work was done and submitted for review in March. gross: - Released DLA-3774-1, fixing CVE-2023-52159. - Submitted the CVE-2023-52159 fix for the next bullseye and bookworm point releases. iwd: - Determined that CVE-2024-28084 does not affect buster. libuv1: - Released DLA-3752-1, fixing CVE-2024-24806. node-xml2js: - Released DLA-3760-1, fixing CVE-2023-0842. postgresql-11: - Released DLA-3764-1, fixing CVE-2024-0985. python2.7: - Determined that CVE-2023-6597 does not affect python2.7. - Released DLA-3771-1, fixing CVE-2024-0450. python3.7: - Released DLA-3772-1, fixing CVE-2023-6597 and CVE-2024-0450. qemu: - Determined that qemu 1:5.2+dfsg-11+deb11u3 in bullseye had fixed CVE-2022-1050 (fix already applied in buster), not CVE-2023-1544. - Determined that CVE-2023-1544 does not affect buster. - Determined that CVE-2023-6683 does not affect <= bullseye. - Determined that CVE-2024-24474 does not affect <= bullseye. - Determined that CVE-2023-42467 does not affect <= bullseye. - Released DLA-3759-1, fixing CVE-2023-2861, CVE-2023-3354 and CVE-2023-5088. tar: - Released DLA-3755-1, fixing CVE-2023-39804. unadf: - Released DLA-3762-1, fixing CVE-2016-1243 and CVE-2016-1244. yard: - Released DLA-3753-1, fixing CVE-2019-1020001 and CVE-2024-27285. ELTS: clamav: - Determined that CVE-2024-20290 and CVE-2024-20328 (sole unfixed CVEs) do not affect jessie or stretch. imlib2: - Determined that CVE-2024-25447, CVE-2024-25448 and CVE-2024-25450 (sole unfixed CVEs) do not affect <= buster. libgit2: - Determined that CVE-2024-24575 does not affect jessie or stretch. - Released ELA-1053-1, fixing CVE-2024-24577 in stretch. libuv1: - Determined that CVE-2024-24806 does not affect stretch. postgresql-9.4: - Released ELA-1061-1, fixing CVE-2024-0985 in jessie. postgresql-9.6: - Released ELA-1060-1, fixing CVE-2024-0985 in stretch. putty: - Determined that CVE-2020-14002 does not affect jessie or stretch. - Determined that CVE-2023-48795 does not affect jessie or stretch. python2.7: - Released ELA-1065-1, fixing CVE-2024-0450 in jessie and stretch. python3.4: - Released ELA-1067-1, fixing CVE-2024-0450 in jessie. python3.5: - Released ELA-1066-1, fixing CVE-2024-0450 in stretch. qemu: - Determined that CVE-2024-26327 does not affect jessie or stretch. - Determined that CVE-2024-26328 does not affect jessie or stretch. - Released ELA-1063-1, fixing CVE-2020-14394, CVE-2023-0330, CVE-2023-2861, CVE-2023-3180, CVE-2023-3354 and CVE-2023-5088 in stretch.
Re: How to handle freeimage package
On Mon, Apr 08, 2024 at 05:34:47PM +0200, Moritz Muehlenhoff wrote: > On Mon, Apr 08, 2024 at 01:59:55PM +0200, Sylvain Beucler wrote: > > Hi, > > > > I think this requires a bit of coordination: > > - the package is basically dead upstream, there hasn't been a fix in the > > official repos, neither Debian or other distros attempted to fix them > > Some of the past fixes got addressed by upstream. But the recent people > who run fuzzers never reported them upstream to the rather byzantine > Sourceforge bug tracker and only posted it some unrelated tree on > Github to get a CVE assigned. > > So a useful next step would be to break those reports down into separate > bug reports and file them there so that upstream actually learns about > them. I don't think that makes much sense. When I checked, the last activity from upstream in the bug tracker was a year ago. Some of the older CVEs are fixed in the upstream VCS, but there are unfixed ones in the bug tracker going back to 2020. The 2024 CVEs are 21 buffer overflows and 2 NULL pointer dereferences, there is likely a lot of low hanging fruit one could fix (and then forward upstream) when spending 2 or 3 days on the package. For me it was an "I don't want to do that right now" and I didn't work on the package at that point, but I don't see a technical reason against someone fixing the CVEs. > Cheers, > Moritz cu Adrian
Re: How to handle freeimage package
On Mon, Apr 08, 2024 at 12:06:25AM +0200, Ola Lundqvist wrote: > Hi again > > Today I looked at the freeimage package that we have in dla-needed. > My conclusion is that we have 19 CVEs postponed with motivation "revisit > when fixed upstream" and 23 CVEs that are in bullseye declared as no-dsa > with the same motivation. > > Since we have this postpone decision for the 19 CVEs we should declare the > rest as postponed as well. This means that the package should go away from > dla-needed after such an operation. > > Or am I reasoning in the wrong way? > > In fact I think all the ones with local DoS class should be declared "low" > severity. > > If I do not hear anything about this I will change this in the way I > describe above. The new issues were already there when I wrote Lack of upstream activity, postponed issues are "Revisit when fixed upstream in dla-needed two weeks ago. Since you decided to take freeimage anyhow, I'd suggest that you go through the CVEs and develop fixes for them (but check with the LTS Coordinators first). > Cheers > > // Ola cu Adrian
Re: gtkwave update for {bookworm,bullseye,buster}-security
On Thu, Apr 04, 2024 at 11:21:21AM +0200, Emilio Pozuelo Monfort wrote: > On 29/03/2024 00:06, Adrian Bunk wrote: >... > > As already mentioned in #1060407, the ghwdump tool (and manpage) was > > dropped in 3.3.110 from the upstream sources, and is now in ghdl-tools. > > For bullseye and buster it is therefore readded. > > > > As mentioned in #1060407 there are different tarballs for GTK 2 and GTK 3. > > Looking closer I realized that this is actually one tarball that > > supports GTK 1+2, and one tarball that supports GTK 2+3. > > I did stay at the GTK 1+2 tarball that was already used before > > for bullseye and buster since there was anyway a different upstream > > tarball required for the +really version that is required to avoid > > creating file conflicts with ghwdump when upgrading to bookworm. > > > > What does the security team consider the best versioning for bullseye? > > In #1060407 I suggested 3.3.104+really3.3.118-0.1, but now I ended up > > preferring 3.3.104+really3.3.118-0+deb11u1 > > I saw this earlier but I couldn't think of a better versioning scheme, > though this looked awkward. Now I have thought of a (possibly) better one, > so I'm stating it here in case we find ourselves in a similar situation in > the future and someone remembers this thread. > > I would have gone with > > 3.3.118-0.1~deb12u1 > 3.3.118+gtk2-0+deb11u1 > 3.3.118+gtk2-0+deb10u1 Rather 3.3.118~gtk2, since 3.3.118+gtk2 > 3.3.118 And as described above, +really is required due to ghwdump: Package: ghdl-tools Replaces: gtkwave (<< 3.3.110~) Breaks: gtkwave (<< 3.3.110~) Since I am readding ghwdump, the version has to be << 3.3.110~ > Cheers, > Emilio cu Adrian
Re: gtkwave update for {bookworm,bullseye,buster}-security
On Sun, Mar 31, 2024 at 01:52:40PM +0200, Moritz Mühlenhoff wrote: > Hi Adrian, Hi Moritz, >... > > debdiffs contain only changes to debian/ > > The bookworm/bullseye debdiffs looks good, please upload to security-master, > thanks! both are now uploaded. > Note that both need -sa, but dak needs some special attention when > uploading to security-master. You'll need to wait for the ACCEPTED mail > before you can upload the next one. Done, but I am not sure this was necessary in this case since these are different upstream tarballs gtkwave_3.3.118.orig.tar.gz and gtkwave_3.3.104+really3.3.118.orig.tar.gz (The contents also differs since as mentioned one is the GTK 2+3 upstream tarball and the other one is the GTK 1+2 upstream tarball.) > Cheers, > Moritz cu Adrian
Re: Guidance for CVE triage and listing packages in dla-needed.txt
On Mon, Mar 18, 2024 at 09:40:45PM +0100, Moritz Muehlenhoff wrote: > Emilio Pozuelo Monfort wrote: > > Small nitpick: a CVE 'ignored' for (old)stable can still be fixed via point > > release. The sec-team could be contacted to update that triaging, but that's > > only ignored for (old)stable-security, not for (old)stable, where other > > criteria applies. The reason following the ignored triaging may give some > > more insight as to why it was ignored and why it may or may not make sense > > to fix in a point release. > > That's not in line with established practices, see > https://security-team.debian.org/triage.html > > | Some packages should rather not be fixed at all, e.g. because the possible > | benefit does not outweigh the risk/costs of an update, or because an update > | is not possible (e.g. as it would introduce behavioural changes not > appropriate > | for a stable release). In the Security Tracker these are tracked with the > | state. But there is a problem that many are not correct, or at least lack a valid justification: $ git grep " (Minor issue)" | grep bookworm | wc -l 29 $ git grep " (Minor issue)" | grep bullseye | wc -l 191 $ "Minor issue" is a good justification for no-dsa, but not for ignored. And when I look through some of these I see CVEs like CVE-2023-48958[1] where is likely outright wrong, or (unlikely) lacks an explanation that it causes a regression. > Cheers, > Moritz cu Adrian [1] https://security-tracker.debian.org/tracker/CVE-2023-48958
Re: Expanding the scope (slightly) of dla-needed.txt
On Thu, Mar 14, 2024 at 04:47:57PM -0400, Roberto C. Sánchez wrote: > Hello everyone, > > I have discussed with Santiago the idea of whether we need to somewhat > expand the scope of dla-needed.txt. > > In essence, we need to continue tracking packages as in-work in some > cases even after a DLA is released because we might be working with > secteam, (O)SRM, and/or the maintainer on an upload to (old)stable. > I think that in the past this has been handled somewhat informally > (e.g., someone prepared a DLA and then even after the package was done > from dla-needed.txt continued working on the (old)stable updates). > However, for the sake of transparency and clarity we should be keeping > track of this in some way. >... > - FD should be confirming that package removals from dla-needed.txt are > valid (i.e., that the package does not require any work towards an > upload to (old)stable) >... IMHO it would be a better approach if the coordinator would check this as part of the Weekly information, not different from other missing work like missing announcements or git tag. For every CVE fixed in LTS last week one of the following should be true: - package is not in stable, or - CVE is marked as fixed in stable, or - CVE is listed in data/next-point-update.txt, or - package is in data/dsa-needed.txt assigned or with an offer to help from the person who did the DLA, or - the CVE information in the security tracker gives a clear reason why no fix is required The last two checks would have to be done manually by the coordinator, but the first three could be automated. The same check can be done for oldstable, using data/next-oldstable-point-update.txt For fixes in ELTS, it could also be checked that a CVE is either fixed in LTS or the package in data/dla-needed.txt Salsa issues would then be opened for the rare cases of missing work, neither bloating dla-needed.txt nor duplicating information, and not different from a missing git tag. This would make the Weekly information even more the point (and deadline) where every contributor knows that some known checks will be run, which also has the positive effect that people will do the work in time. > Regards, > > -Roberto cu Adrian
(E)LTS report for February 2024
LTS: gsoap: - Released DLA-3745-1, fixing CVE-2020-13574, CVE-2020-13575, CVE-2020-13576, CVE-2020-13577 and CVE-2020-13578. wireshark: - Determined that CVE-2023-2906/wireshark does not affect <= buster. - Determined that CVE-2023-5371 does not affect <= bullseye. - Determined that CVE-2023-6174 does not affect buster. - Determined that CVE-2024-0207 does not affect <= bookworm. - Determined that CVE-2024-0210 does not affect <= bookworm. - Released DLA-3746-1, fixing CVE-2023-4511, CVE-2023-4513, CVE-2023-6175 and CVE-2024-0208. ELTS: ghostscript: - Determined that CVE-2020-36773 (sole non-ignored CVE) does not affect jessie or stretch. gsoap: - Released ELA-1051-1, fixing CVE-2020-13574, CVE-2020-13575, CVE-2020-13576, CVE-2020-13577 and CVE-2020-13578. wireshark: - Released ELA-1052-1, fixing CVE-2023-4511, CVE-2023-4513, CVE-2023-6175 and CVE-2024-0208.
(E)LTS report for December 2023
LTS: curl: - Determined that CVE-2022-32207 does not affect <= buster. - Found and documented a regression in CVE-2023-27534. - CVE-2022-32207 does not affect <= buster - Released DLA 3692-1, fixing CVE-2023-28322 and CVE-2023-46218, also including 2 non-security fixes from contributors. ELTS: ncurses: - Released ELA-1022-1, fixing CVE-2023-29491.
Re: curl: CVE-2023-28322 and CVE-2023-27534
On Sat, Dec 16, 2023 at 10:39:08PM -0300, Samuel Henrique wrote: >... > On Thu, 30 Nov 2023 at 06:36, Markus Koschany wrote: > > I have recently triaged CVE-2023-28322 and CVE-2023-27534 for curl as > > ignored > > for Buster because I believe those are minor issues. Since you expressed > > interest as the maintainer of curl to fix potential security > > vulnerabilities, I > > am asking you for your assessment. Are you (or someone else reading the > > list) > > interested in fixing those CVE? > > I have not had time to properly look at this yet, but I agree with not > backporting the dynbuf functions for CVE-2023-27534 (at least from what I've > seen so far). I'd agree with that assessment. For releases where it has been backported, I've added a link to a regression fix in the security tracker.[1] >... > To give you a rough timeline for changes, my current priorities for curl right > now are to get the fixes for CVE-2023-46218 and CVE-2023-46219 on all affected > releases, Regarding LTS, CVE-2023-46219 does not affect <= buster since CVE-2022-32207 was not present there. > fix the ldap issue (#1057855) on unstable, and then come back to > CVE-2023-27534 and CVE-2023-28322 (to be more confident on what to do). >... For buster LTS I have now CVE-2023-28322 and CVE-2023-46218 fixed with [2] and plan to upload that. Please let me know if anything looks wrong about that. cu Adrian [1] https://deb.freexian.com/extended-lts/tracker/CVE-2023-27534 [2] https://salsa.debian.org/debian/curl/-/commit/ab0405fcd6b2bf5fa5b3aa338da4689d0d6ca617
(E)LTS report for November 2023
LTS: trafficserver: - Released DLA-3645-1, fixing CVE-2023-41752 and CVE-2023-44487. galera-3: - Determined that CVE-2023-5157 in galera-4 does not affect galera-3. gimp: - Released DLA-3659-1, fixing CVE-2022-30067, CVE-2023-2 and CVE-2023-4. - Determined that CVE-2023-3 does not affect <= buster. - The plugin with CVE-2023-1 is in gimp-dds in <= buster, released DLA-3677-1 for gimp-dds with this fix. - Notified the security team to get rid of the stale gimp-dds package in bullseye+bookworm that is an older version of a plugin moved into gimp in >= bullseye. - Submitted gimp packages for bullseye-pu and bookworm-pu that add Breaks to remove the old and vulnerable gimp-dds version of the plugin. vlc: - Released DLA-3679-1, updating to the latest upstream version, which also fixes CVE-2023-47359 and CVE-2023-47360. ELTS: vim: - Released ELA-1002-1, fixing CVE-2023-4752, CVE-2023-4781 and CVE-2023-5344 in jessie and stretch. gimp: - Released ELA-1005-1, fixing CVE-2022-30067, CVE-2023-2 and CVE-2023-4 in stretch. vlc: - Released ELA-1016-1, updating to the latest upstream version in stretch, which also fixes CVE-2023-47359 and CVE-2023-47360.
(E)LTS report for October 2023
LTS: poppler: - Confirmed that CVE-2020-18839 is a duplicate of CVE-2020-27778 - Released DLA-3620-1, fixing CVE-2020-23804 CVE-2022-37050 CVE-2022-37051 - PoCs for all 3 CVEs were confirmed to be present in the unfixed version and fixed in the fixed version krb: - Released DLA-3626-1, fixing CVE-2023-36054. ELTS: zookeeper: - Checked and marked that CVE-2023-44981 (sole unfixed CVE) does not affect jessie or stretch. haproxy: - Checked and marked that CVE-2023-44487 (sole unfixed CVE) does not affect jessie or stretch. krb: - Released ELA-987-1 for jessie and stretch, fixing CVE-2023-36054.
(E)LTS report for September 2023
DLAs released: DLA-3593-1 gerbv CVE-2021-40393 CVE-2021-40394 CVE-2023-4508 DLA-3595-1 trafficserver CVE-2022-47185 CVE-2023-33934 ELAs released: ELA-942-2 qpdf (stretch) regression update ELA-972-1 exempi (stretch) CVE-2020-18651 CVE-2020-18652 ELA-974-1 ghostscript (jessie+stretch) CVE-2020-21710 CVE-2020-21890 CVE-2023-38559
binNMUs needed for new pandoc in *stable
On Tue, Jul 25, 2023 at 11:39:38PM +0200, Guilhem Moulin wrote:
>...
> The Security Team decided not to issue a DSA for that CVE, but it's now fixed
> in
> buster-security (2.2.1-3+deb10u1) as well as sid (2.17.1.1-2), so it makes
> sense
> to fix it via (o)s-pu too.
>...
In all 3 distributions this made libghc-{gitit,hakyll}-{dev,prof}
uninstallable due to changed libghc-pandoc-{dev,prof}-* provides, e.g.:
The following packages have unmet dependencies:
libghc-gitit-dev : Depends: libghc-pandoc-dev-2.17.1.1-35d44
For bullseye/bookworm this should be fixed with:
wb nmu gitit . ANY . bookworm . -m 'Rebuild against new pandoc'
wb nmu haskell-hakyll . ANY . bookworm . -m 'Rebuild against new pandoc'
wb nmu gitit . ANY . bullseye . -m 'Rebuild against new pandoc'
wb nmu haskell-hakyll . ANY . bullseye . -m 'Rebuild against new pandoc'
This might result in the Provides of libghc-{gitit,hakyll}-{dev,prof} changing,
but these are leaf packages.
cu
Adrian
Re: suricata
On Mon, Sep 25, 2023 at 09:26:10PM +0200, Tobias Frost wrote: > Hi Adrian, Hi Tobi, >... > This sounds it's almost ready, so I think the best thing is if you > complete the work, so if this is ok with you, please take oever and > complete the package! thanks, I've taken it back and will make a release in the next days. > Cheers, > tobi cu Adrian
Re: suricata
On Sun, Sep 24, 2023 at 11:34:55AM +0200, Tobias Frost wrote: > Hi Adrian, Hi Tobias, > I've just claimed "suricata" for LTS, and the log says that you've > already worked on the package. Unfortunatly I could not find any > repository for your LTS changes, if there are some already, can you > advice where to look? sorry for that, I worked on it but then embarrassingly dropped the ball. I can wrap it up during the next 2 days and either make a DLA or hand it over to you, whichever you prefer. > Cheers, > tobi cu Adrian
Re: (E)LTS report for August 2023
On Sun, Sep 10, 2023 at 09:22:03PM +0300, Adrian Bunk wrote: > DLAs released: >... > DLA-3552-1 gst-plugins-ugly1.0 > 2 vulnerabilities without CVE numbers assigned > > > ELAs released: >... > ELA-941-1 gst-plugins-ugly1.0 (stretch) > 2 vulnerabilities without CVE numbers assigned >... Correction, in the meantime numbers have been assigned: CVE-2023-38103 CVE-2023-38104 cu Adrian
(E)LTS report for August 2023
DLAs released: DLA-3517-1 pdfcrack CVE-2020-22336 DLA-3519-1 ghostscript CVE-2023-38559 DLA-3528-1 poppler CVE-2020-36023 CVE-2020-36024 DLA-3552-1 gst-plugins-ugly1.0 2 vulnerabilities without CVE numbers assigned ELAs released: ELA-928-1 poppler (jessie+stretch) CVE-2020-36023 CVE-2020-36024 ELA-941-1 gst-plugins-ugly1.0 (stretch) 2 vulnerabilities without CVE numbers assigned ELA-942-1 qpdf (stretch) CVE-2015-9252 CVE-2017-9208 CVE-2017-9209 CVE-2017-9210 CVE-2017-11624 CVE-2017-11625 CVE-2017-11626 CVE-2017-11627 CVE-2017-12595 CVE-2017-18183 CVE-2017-18186 CVE-2018-9918 CVE-2021-25786 CVE-2021-36978
(E)LTS report for July 2023
DLAs released: DLA-3497-1 pypdf2 CVE-2023-36810 DLA-3513-1 tiff CVE-2023-2908 CVE-2023-3316 CVE-2023-3618 CVE-2023-25433 CVE-2023-26965 CVE-2023-26966 CVE-2023-38288 CVE-2023-38289 ELAs released: ELA-893-1 pypdf2 (stretch) CVE-2023-36810 ELA-909-1 tiff (jessie+stretch) CVE-2023-2908 CVE-2023-3316 CVE-2023-3618 CVE-2023-25433 CVE-2023-26965 CVE-2023-26966 CVE-2023-38288 CVE-2023-38289 cu Adrian
Re: WebKit 2.40 update for buster
On Thu, Jul 06, 2023 at 01:19:51PM +, Alberto Garcia wrote: >... > Bear in mind that supporting older distros means refraining from using > newer versions of the libraries and build dependencies that Webkit > uses. This is already complicated, but there's a bigger problem than > that: it also means not using recent versions of the C++ language, > something that affects the WebKit project as a whole and that would > need to be agreed with Apple. >... A recent compiler is always already available: Debian *stable distributions (including LTS) already add a new LLVM major version annually since that is required for the latest Rust every new Firefox ESR branch needs. Since autumn 2022 unstable/stable/oldstable/oldoldstable all have the same version of LLVM 13 (released October 2021) due to that, if a recent C++ compiler was the only problem (it isn't) then everything would be fine. > Berto cu Adrian
(E)LTS report for June 2023
DLAs released: DLA-3443-1 wireshark CVE-2023-2856 CVE-2023-2858 CVE-2023-2879 CVE-2023-2952 DLA 3445-1 cpio CVE-2019-14866 CVE-2021-38185 DLA-3470-1 owslib CVE-2023-27476 DLA-3472-1 libx11 CVE-2023-3138 DLA-3474-1 systemd CVE-2022-3821 DLA-3475-1 trafficserver CVE-2022-47184 CVE-2023-30631 CVE-2023-33933 DLA-3477-1 python3.7 CVE-2015-20107 CVE-2020-10735 CVE-2021-3426 CVE-2021-3733 CVE-2021-3737 CVE-2021-4189 CVE-2022-45061 ELAs released: ELA-862-1 wireshark (stretch) CVE-2023-2856 CVE-2023-2858 CVE-2023-2879 CVE-2023-2952 ELA-863-1 cpio (jessie+stretch) CVE-2019-14866 CVE-2021-38185 ELA-878-1 libwebp (stretch) CVE-2023-1999 ELA-881-1 libx11 (jessie+stretch) CVE-2023-3138 ELA-884-1 python3.5 (stretch) CVE-2015-20107 CVE-2021-4189 CVE-2022-45061 ELA-885-1 python3.4 (jessie) CVE-2015-20107 CVE-2022-45061 ELA-886-1 ffmpeg (stretch) CVE-2022-3109 CVE-2022-3341
(E)LTS report for April 2023
DLAs released: DLA-3402-1 wireshark CVE-2023-1161 CVE-2023-1992 CVE-2023-1993 CVE-2023-1994 DLA-3407-1 jackson-databind CVE-2020-10650 DLA-3408-1 jruby CVE-2017-17742 CVE-2019-16201 CVE-2019-16254 CVE-2019-16255 CVE-2020-25613 CVE-2021-31810 CVE-2021-32066 CVE-2023-28755 CVE-2023-28756 DLA-3409-1 libapache2-mod-auth-openidc CVE-2019-20479 CVE-2021-32785 CVE-2021-32786 CVE-2021-32791 CVE-2021-32792 CVE-2023-28625 ELA released: ELA-839-1 wireshark/stretch CVE-2023-1161 CVE-2023-1992 CVE-2023-1993 CVE-2023-1994
LTS report for March 2023
DLA released: DLA-3377-1 systemd CVE-2023-26604 cu Adrian
(E)LTS report for February 2023
DLAs released: DLA-3332-1 apr-util CVE-2022-25147 DLA-3334-1 sofia-sip CVE-2022-47516 DLA-3339-1 binwalk CVE-2022-4510 DLA-3341-1 curl CVE-2023-23916 DLA-3343-1 mono CVE-2023-26314 A DLA for emacs was prepared, but is waiting for confirmation that a regression that was discovered in bullseye-security is actually fixed. ELTS: ELAs for emacs24 and emacs25 were prepared, but are waiting for confirmation that a regression that was discovered in bullseye-security is actually fixed.
LTS report for January 2023
DLAs released: DLA-3292-1 sofia-sip CVE-2023-22741 DLA-3304-1 fig2dev CVE-2020-21529 CVE-2020-21531 CVE-2020-21532 CVE-2020-21676 CVE-2021-32280 DLA-3305-1 libstb CVE-2018-16981 CVE-2019-13217 CVE-2019-13218 CVE-2019-13219 CVE-2019-13220 CVE-2019-13221 CVE-2019-13222 CVE-2019-13223 CVE-2021-28021 CVE-2021-37789 CVE-2021-42715 CVE-2022-28041 CVE-2022-28042
LTS report for December 2021
Hours worked: 70.75 hours DLAs released: DLA-2849-1 wireshark CVE-2021-22207 CVE-2021-22235 CVE-2021-39921 CVE-2021-39922 CVE-2021-39923 CVE-2021-39924 CVE-2021-39925 CVE-2021-39928 CVE-2021-39929 DLA-2850-1 libpcap CVE-2019-15165 DLA-2851-1 libextractor CVE-2019-15531 DLA-2855-1 monit CVE-2019-11454 CVE-2019-11455 DLA-2856-1 okular CVE-2020-9359 DLA-2857-1 postgis CVE-2017-18359 DLA-2861-1 rdflib CVE-2019-7653 DLA-2865-1 resiprocate CVE-2017-11521 CVE-2018-12584 DLA-2866-1 uw-imap CVE-2018-19518 DLA-2868-1 advancecomp CVE-2018-1056 CVE-2019-8379 CVE-2019-8383 CVE-2019-9210 DLA-2872-1 agg CVE-2019-6245 DLA-2873-1 aria2 CVE-2019-3500
Re: postgis 2.3.1+dfsg-2+deb9u1 update broken
On Wed, Dec 29, 2021 at 07:46:39PM +0200, Adrian Bunk wrote: > On Wed, Dec 29, 2021 at 05:04:29PM +0100, Peter De Wachter wrote: > > In postgis LTS update 2.3.1+dfsg-2+deb9u1, the package > > postgresql-9.6-postgis-2.3-scripts is empty (containing only > > /usr/share/doc files). The scripts are missing. Without the scripts, I > > believe it's not possible to create new postgis databases. > > > > To reproduce: > > > > $ sudo -u postgres createdb test > > $ sudo -u postgres psql test -c 'create extension postgis' > > ERROR: could not open extension control file > > "/usr/share/postgresql/9.6/extension/postgis.control": No such file or > > directory > > Thanks for the report and apologies for the breakage. > > The problem appears to happen when building binary-all separately as is > done on the buildds. > > The previous package in stretch was a an upload of all+amd64 binaries, > and the same was true for my local tests. > > This looks like #932833 which was reported and fixed when the uploads > changed to source-only in bullseye. > > I'm currently working on fixing this issue. This has now been fixed in 2.3.1+dfsg-2+deb9u2. cu Adrian
Re: postgis 2.3.1+dfsg-2+deb9u1 update broken
On Wed, Dec 29, 2021 at 05:04:29PM +0100, Peter De Wachter wrote: > In postgis LTS update 2.3.1+dfsg-2+deb9u1, the package > postgresql-9.6-postgis-2.3-scripts is empty (containing only > /usr/share/doc files). The scripts are missing. Without the scripts, I > believe it's not possible to create new postgis databases. > > To reproduce: > > $ sudo -u postgres createdb test > $ sudo -u postgres psql test -c 'create extension postgis' > ERROR: could not open extension control file > "/usr/share/postgresql/9.6/extension/postgis.control": No such file or > directory Thanks for the report and apologies for the breakage. The problem appears to happen when building binary-all separately as is done on the buildds. The previous package in stretch was a an upload of all+amd64 binaries, and the same was true for my local tests. This looks like #932833 which was reported and fixed when the uploads changed to source-only in bullseye. I'm currently working on fixing this issue. cu Adrian
LTS report for November 2021
Hours worked: 62 hours DLAs released: DLA-2828-1 libvorbis CVE-2017-14160 CVE-2018-10392 CVE-2018-10393 DLA-2829-1 libvpx CVE-2020-0034 DLA-2830-1 tar CVE-2018-20482 DLA-2831-1 libntlm CVE-2019-17455 DLA-2832-1 opensc CVE-2019-15945 CVE-2019-15946 CVE-2019-19479 CVE-2020-26570 CVE-2020-26571 CVE-2020-26572 DLA-2833-1 rsync CVE-2018-5764 DLA-2834-1 uriparser CVE-2018-20721 DLA-2835-1 rsyslog CVE-2019-17041 CVE-2019-17042
CVE-2021-38595 incorrectly marked as not affecting Qt 5?
On Tue, Aug 31, 2021 at 09:15:15AM +, Raphaël Hertzog (@hertzog) wrote:
>...
> Commits:
> 63957298 by Neil Williams at 2021-08-31T10:11:30+01:00
> CVE-2021-38593/qt vulnerable code introduced later
>...
> Changes:
>
> =
> data/CVE/list
> =
> @@ -3785,8 +3785,8 @@ CVE-2021-38595
> CVE-2021-38594
> RESERVED
> CVE-2021-38593 (Qt 5.0.0 through 6.1.2 has an out-of-bounds write in
> QOutlineMapper::c ...)
> - - qtbase-opensource-src
> - - qtbase-opensource-src-gles
> + - qtbase-opensource-src (Vulnerable code introduced
> later)
> + - qtbase-opensource-src-gles (Vulnerable code introduced
> later)
> NOTE: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35566
> NOTE:
> https://github.com/google/oss-fuzz-vulns/blob/main/vulns/qt/OSV-2021-903.yaml
> NOTE:
> https://github.com/qt/qtbase/commit/1ca02cf2879a5e1511a2f2109f0925cf4c892862
> (6.1)
>...
Hi Neil,
can you double-check that?
Upload [1] makes me wonder whether the not-affected is correct,
and "Qt 5.0.0 through 6.1.2" also implies all versions of
qtbase-opensource-src{,-gles} would be affected.
Thanks
Adrian
[1]
https://tracker.debian.org/news/1281817/accepted-qtbase-opensource-src-5152dfsg-14-source-into-unstable/
Re: Bug#994405: libgmp10:i386: buffer overflow due to integer overflow in mpz/inp_raw.c on 32-bit machines
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
LTS report for October 2021
Hours worked: 40.5 hours DLAs released: DLA 2795 gpsd CVE-2018-17937 DLA 2801 cron CVE-2017-9525 CVE-2019-9704 CVE-2019-9705 CVE-2019-9706 DLA 2802 elfutils CVE-2018-16062 CVE-2018-16402 CVE-2018-18310 CVE-2018-18520 CVE-2018-18521 CVE-2019-7150 CVE-2019-7665 DLA 2803 libsdl2 CVE-2017-2888 CVE-2019-7637 DLA 2804 libsdl1.2 CVE-2019-7572 CVE-2019-7573 CVE-2019-7574 CVE-2019-7575 CVE-2019-7576 CVE-2019-7577 CVE-2019-7578 CVE-2019-7635 CVE-2019-7636 CVE-2019-7637 CVE-2019-7638 CVE-2019-13616 DLA 2805 libmspack CVE-2019-1010305
Re: Change in libcrypt1 prevents upgrades from Buster to Bookworm
On Sat, Oct 09, 2021 at 07:41:03PM -0700, Otto Kekäläinen wrote: > Hello! Hello Otto! >... > This makes LTS kind of moot, as systems that want to stay on LTS and > "skip" at least one release can no longer do so. What is your take > here? If the issue is not fixed, then at least LTS should document it > well for LTS users? It's already documented in the release notes for bullseye, and I'm sure the same will be there for bookworm: https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgrade-to-debian-oldrelease It does not make LTS kind of moot, it only means that whenever you choose to upgrade skipping one or more releases you have to do several upgrades in a row. > - Otto >... cu Adrian
Re: Accepted krb5 1.15-1+deb9u3 (source) into oldoldstable
On Fri, Oct 01, 2021 at 11:58:17AM +0100, Dameon Wagner wrote: > > Hi, Hi Dameon, > Apologies if this isn't the correct list to flag this, but it appears > that the upload for this DLA was missing the two all-architecture > binary packages: krb5-doc and krb5-locales. > > Running `apt-cache policy krb5-doc` on various stretch machines shows > only 1.15-1+deb9u1, from the main apt repository, and 1.15-1+deb9u2 > from "/var/lib/dpkg/status". > > I'm happy to raise a bug if others confirm they're seeing the same. apologies for that. Due to a known problem [1] that should soon be fixed, the binary-all buildds have not yet built krb5. > Cheers. > > Dameon. cu Adrian [1] https://lists.debian.org/debian-lts/2021/10/msg1.html
(E)LTS report for September 2021
LTS Hours worked: 19.5 hours DLA 2770-1 weechat CVE-2020-8955 CVE-2020-9759 CVE-2020-9760 CVE-2021-40516 DLA 2771-1 krb5 CVE-2018-5729 CVE-2018-5730 CVE-2018-20217 CVE-2021-37750 DLA 2772-1 taglib CVE-2017-12678 CVE-2018-11439 ELTS hours worked: 3 hours ELA-489-1 weechat CVE-2021-40516
Re: stretch-security buildd builds are now broken (after 2021-10-01; le cert issue?)
On Fri, Oct 01, 2021 at 01:21:38AM -0400, Boyuan Yang wrote: > (Please cc me when needed) > > Dear LTS folks, > > I'd like to raise the issue that buildd stretch-security builds are now > completely broken after 2021-10-01. For example, see > https://buildd.debian.org/status/architecture.php?a=all&suite=stretch-security > and > https://buildd.debian.org/status/logs.php?pkg=krb5&ver=1.15-1%2Bdeb9u3&arch=all > . The root cause might be > https://lists.debian.org/debian-lts/2021/09/msg8.html : >... Thanks for bringing this up. Yes this is the LE cert issue, the root problem is that the buildd chroot contained stretch without stretch-security and therefore the gnutls28 3.5.8-5+deb9u6 fix is missing. DSA already fixed chroots on some buildds yesterday, and everything should be working fine again soon. > Thanks, > Boyuan Yang cu Adrian
Re: Lintian changes for LTS development?
On Mon, Sep 27, 2021 at 04:58:02PM -, Chris Lamb wrote: > Hi, > > Whilst I think of it, are there any changes to Lintian that folks > here might consider particularly useful when doing LTS development? To which lintian? Running stretch lintian tends to give more useful information for packages in stretch than running unstable lintian. > I've already implemented some changes to not emit some specific > warnings when doing security updates, particularly to do with version > numbering. The same problems exist with (old)stable-pu updates, and lintian knowing about differing versioning rules when uploading to anything other than unstable or experimental would be useful. > This is on the basis that if I automatically ignore some of > them, I might be inadvertently 'training' myself to ignore other, > more serious, ones. > > However, I'm sure there is more low-hanging fruit that might prevent > potential regressions. Thoughts welcome. A suppressions list in debian-lts git to be used with --suppress-tags-from-file would be useful. > Regards, cu Adrian
(E)LTS report for August 2021
LTS Hours worked: 11 hours DLA-2734-1 curl CVE-2021-22898 CVE-2021-22924 Non-DLA LTS work: - debugged ledger issue that caused non-zero leftover time in past months - fixed bin/give-back-hours when run in August/September ELTS hours worked: 3 hours ELA-470-1 curl CVE-2021-22898
Re: packages in *-lts newer than in subsequent releases
On Tue, Aug 03, 2021 at 09:37:57AM +0100, Chris Lamb wrote: > Sylvain Beucler wrote: > > > >> Will resolve these two. > > > > > > Um, I just uploaded libpam-tacplus. Maybe take care of pyxdg, > > > please? Thank you! > > > > How about you add these 6 packages to data/dla-needed.txt? > > Good idea — done. >... Please double-check what is actually for stretch LTS, and what is also/only for jessie ELTS. At least libkohana2-php and postgresql-9.1 are not in stretch at all, so shouldn't be uploaded there. On a more general note, we could try to become better at also fixing the same CVEs in packages in more recent distributions. This would avoid security regressions when upgrading from (E)LTS to more recent Debian releases, and en passant also fix this kind of problems. > Best wishes, cu Adrian
LTS report for January 2021
Hours worked: 14 hours DLA-2513 p11-kit CVE-2020-29361 CVE-2020-29362 DLA-2514 flac CVE-2017-6888 CVE-2020-0499 DLA-2538 mariadb-10.1 CVE-2020-14765 CVE-2020-14812 wireshark - will be released on 6.2.2021 after 2.6.20-0+deb10u1 with the same changes is in the buster point release CVE-2019-13619 CVE-2019-16319 CVE-2019-19553 CVE-2020-7045 CVE-2020-9428 CVE-2020-9430 CVE-2020-9431 CVE-2020-11647 CVE-2020-13164 CVE-2020-15466 CVE-2020-25862 CVE-2020-25863 CVE-2020-26418 CVE-2020-26421 CVE-2020-26575 CVE-2020-28030
LTS report for December 2020
Hours worked: 3 hours DLA-2502 postsrsd CVE-2020-35573
Re: Advice for DLA needed entry
On Tue, Jan 05, 2021 at 02:08:40PM +0100, Ola Lundqvist wrote: >... > Den tis 5 jan. 2021 13:45Adrian Bunk skrev: >... > >NOTE: 20201129: buster-pu in #975932, will backport when in buster (bunk) >... > > Before you've added your notes a month later this was the last note, > > and if you did not look at the bug before doing anything else that's > > something you should learn a lesson from. > > I did but it was still not clear to me whether the open cves were going to > be addressed by the update and whether the update was for the postponed or > the ones without. I did not realize that the planned update were for the > postponed until you added the note after my email. >... NOTE: 20201007: during last triage, I marked some CVEs as no-dsa, it'd be great to include NOTE: 20201007: those fixes as well! \o/ (utkarsh) NOTE: 20201108: 2.6.8-1.1 backported as first step NOTE: 20201108: will try to update wireshark in the next NOTE: 20201108: buster point release followed by another backport (bunk) NOTE: 20201123: NMU for unstable prepared as first step (bunk) NOTE: 20201129: buster-pu in #975932, will backport when in buster (bunk) This is the complete list of the notes as they were for a month before your email. #975932 says it fixes 14 CVEs, and when you click on the debdiff in the bug you see in debian/changelog what CVEs are fixed. If anything was still not clear to you, asking before doing anything would have been the correct action. Shit happens, and this was a rather harmless mistake. It was your choice to discuss this on a public mailing list, and I do not have a problem with stating publicly that this was your mistake. The most weird thing is that you sent me two emails, but instead of waiting for an answer started this discussion here less than 2 hours after your first email. cu Adrian
Re: Advice for DLA needed entry
On Sun, Jan 03, 2021 at 12:03:05AM +0100, Ola Lundqvist wrote: > Hi Adrian Hi Ola, >... > If we keep it in dla-needed we will constantly have people like me who > think that something should be done when it is not claimed. >... > Should we write your name on the claim (because you do in practice have it > claimed, but the problem here is that it will be a long claim, but that is > not an issue if you keep adding notes) or should we write a fake claim like > [semi-claimed pending buster backport] as claim name? NOTE: 20201129: buster-pu in #975932, will backport when in buster (bunk) This is my note from November, and this is a fake claim. Before you've added your notes a month later this was the last note, and if you did not look at the bug before doing anything else that's something you should learn a lesson from. Usually people ask when a note is unclear. To avoid duplicate work, usually people ask before working on a package someone else seems to have worked on before. > Cheers > > // Ola cu Adrian
Re: Advice for DLA needed entry
On Wed, Dec 30, 2020 at 11:33:12PM +0100, Ola Lundqvist wrote: > Hi > > Today I worked some on wireshark and concluded that all CVEs were postponed > for buster. So I did some research to check if they were applicable to > stretch as well and added quite a few notes about this in the tracker. The fixes for the 2 new CVEs are trivial to backport, I'll update my buster-pu request. > Now to my question. Should wireshark now be in dla-needed.txt? NOTE: 20201129: buster-pu in #975932, will backport when in buster (bunk) What alternative would you suggest to inform other LTS contributors that 14 CVEs were already fixed and why the upload to stretch is pending? >... > Or should we even be before in LTS? Shipping a higher versioned package in oldstable than what is in stable is problematic, versioning would have to be something like 2.6.8-1.1~really2.6.20 But there is no need to hurry when nothing is considered serious enough for a DSA. > Cheers > > // Ola cu Adrian
Re: pluxml issues are questionable, request for advice
On Wed, Dec 16, 2020 at 07:36:19AM +0100, Ola Lundqvist wrote: > Hi LTS team > > I have checked two of the pluxml issues > CVE-2020-18184 > This vulnerability is questioned upstream. >... > The question is how this should be marked: > - no-dsa minor issue? > - ignored? >... "not a vulnerability" or "no security impact" is usually marked "unimportant", see e.g. https://security-tracker.debian.org/tracker/source-package/python3.7 For pluxml the same CVEs are "vulnerable" in stable+unstable and with RC bug #973382 open, the security team should know best how to handle this based on your analysis. > Best regards > > // Ola cu Adrian
(E)LTS report for November 2020
LTS: Hours worked: 13 hours DLA 2452 libdatetime-timezone-perl Updated timezone data DLA 2462 cimg CVE-2020-25693 DLA 2472 mutt CVE-2020-28896 DLA 2473 vips CVE-2020-20739 ELTS: Hours worked: 2 hours libdatetime-timezone-perl Updated timezone data
Re: Bug#974899: libdatetime-timezone-perl: Inconsistent Olson versions within Timezone data
Version: 1:2.09-1+2020d+1 On Mon, Nov 16, 2020 at 09:35:02AM +, Ben Smithurst wrote: >... > Loaded DateTime::TimeZone::Europe::London, which is from a different version > (2020d) of the Olson database than this installation of DateTime::TimeZone > (2019c). >... Apologies for the breakage, I've just uploaded 1:2.09-1+2020d+1 to fix it. cu Adrian
Re: Fwd: Bug#974899: libdatetime-timezone-perl: Inconsistent Olson versions within Timezone data
On Mon, Nov 16, 2020 at 04:29:05PM +0100, Florian Schlichting wrote: > Hi Adrian, > > are you aware of this regression in stretch-security, can you fix this > soonish (it leaves several hundred lines in my log every hour) and/or > leave a comment in the bug? Yes, I've seen the bug and already looking into it. > thanks, > Florian cu Adrian
LTS report for October 2020
Hours worked: 7 hours DLAs released: DLA-2422-1 qtsvg-opensource-src CVE-2018-19869 DLA-2423-1 wireshark CVE-2019-10894 CVE-2019-10895 CVE-2019-10896 CVE-2019-10899 CVE-2019-10901 CVE-2019-10903 CVE-2019-12295 DLA-2424-1 tzdata new upstream version for DST changes
Re: golang-go.crypto / CVE-2019-11841
On Fri, Oct 09, 2020 at 12:17:26PM +0200, Emilio Pozuelo Monfort wrote: > On 09/10/2020 00:23, Brian May wrote: > > We probably need someway of keeping track of what packages have already > > been looked at and their status with respect to this rebuild. Not really > > convinced data/dla-needed.txt is up to this task. > > I would look for an automated way to do this. E.g. by downloading and > inspecting the binaries to see if they have the affected code. > > I think Adrian handled a go update and its rdeps in the past. Adding him to > Cc in case he has any ideas. >... I went manually through the rdeps, and claimed only Go packages with few redps needing rebuilding. So sorry, no easy ideas from me. > Cheers, > Emilio cu Adrian
LTS report for September 2020
Hours worked: 14 hours DLAs released: DLA-2376-1 qtbase-opensource-src CVE-2018-19872 CVE-2020-17507 DLA-2377-1 qt4-x11 CVE-2018-15518 CVE-2018-19869 CVE-2018-19870 CVE-2018-19871 CVE-2018-19872 CVE-2018-19873 CVE-2020-17507 DLA-2388-1 nss CVE-2018-12404 CVE-2018-18508 CVE-2019-11719 CVE-2019-11729 CVE-2019-11745 CVE-2019-17006 CVE-2019-17007 CVE-2020-6829 CVE-2020-12399 CVE-2020-12400 CVE-2020-12401 CVE-2020-12402 CVE-2020-12403
LTS report for August 2020
Hours worked: 31 hours DLAs released: DLA-2309-1 evolution-data-server CVE-2020-16117 DLA-2320-1 golang-github-seccomp-libseccomp-golang CVE-2017-18367 DLA-2326-1 htmlunit CVE-2020-5529 DLA-2329-1 libetpan CVE-2020-15953 DLA-2330-1 jruby CVE-2017-17742 CVE-2019-8320 CVE-2019-8321 CVE-2019-8322 CVE-2019-8323 CVE-2019-8324 CVE-2019-8325 CVE-2019-16201 CVE-2019-16254 CVE-2019-16255 DLA-2341-1 inetutils CVE-2020-10188 DLA-2342-1 libjackson-json-java CVE-2017-7525 CVE-2019-10172 DLA-2357-1 ros-actionlib CVE-2020-10289 DLA-2358-1 openexr CVE-2017-9110 CVE-2017-9111 CVE-2017-9112 CVE-2017-9113 CVE-2017-9114 CVE-2017-9115 CVE-2017-9116 CVE-2017-12596 CVE-2020-11758 CVE-2020-11759 CVE-2020-11760 CVE-2020-11761 CVE-2020-11762 CVE-2020-11763 CVE-2020-11764 CVE-2020-11765 CVE-2020-15305 CVE-2020-15306
Re: gb: ghostscript_9.26a~dfsg-0+deb9u7
On Mon, Aug 24, 2020 at 10:52:12AM +0200, Sylvain Beucler wrote: >... > On 24/08/2020 07:42, Adrian Bunk wrote: > > On Fri, Aug 21, 2020 at 02:08:44PM +0200, Sylvain Beucler wrote: >... > >> I cannot find an explanation for this error, and the package builds > >> fine on porterbox abel.debian.org (see > >> ~beuc/ghostscript_9.26a~dfsg-0+deb9u7_armhf.build), so I suppose a > >> transient buildd failure occurred. > >> ... > > Race conditions are rarely always reproducible. > > This statement sounds condescending and somewhat ruins what was a nice > e-mail so far :/ It was not intended this way. The difference between "condescending" and "useful information" is what level of knowledge you already have. Unless one knows the skills of the other person well, one always ends up explaining either too few or too much. And yes, I have gotten "but it did work when I tried" replies from DDs when discussing these kind of issues. > Cheers! > Sylvain cu Adrian
Re: gb: ghostscript_9.26a~dfsg-0+deb9u7
On Fri, Aug 21, 2020 at 02:08:44PM +0200, Sylvain Beucler wrote: > Hello, > > ghostscript failed to build on armhf for stretch-security: > https://buildd.debian.org/status/fetch.php?pkg=ghostscript&arch=armhf&ver=9.26a%7Edfsg-0%2Bdeb9u7&stamp=1597941103&raw=0 > "./soobj/dxmainc.o: file not recognized: File truncated" This is a typical parallel building bug, something is reading dxmainc.o while something else hasn't yet finished writing it. There is a dependency between these two missing somewhere in some Makefile. In buster this is workarounded with https://sources.debian.org/src/ghostscript/9.52.1%7Edfsg-1/debian/rules/#L33-L36 > I cannot find an explanation for this error, and the package builds > fine on porterbox abel.debian.org (see > ~beuc/ghostscript_9.26a~dfsg-0+deb9u7_armhf.build), so I suppose a > transient buildd failure occurred. >... Race conditions are rarely always reproducible. > Cheers! > Sylvain cu Adrian
LTS report for July 2020
Hours worked: 16 hours DLAs released: DLA-2291 ffmpeg CVE-2019-13390 CVE-2019-17542 CVE-2020-13904 DLA-2292 milkytracker CVE-2019-14464 CVE-2019-14496 CVE-2019-14497 CVE-2020-15569 DLA-2302 libjpeg-turbo CVE-2018-1152 CVE-2018-14498 CVE-2020-13790 CVE-2020-14152
Re: [Git][security-tracker-team/security-tracker][master] data/dla-needed.txt: Claim gosa.
On Thu, Jul 09, 2020 at 11:59:19AM +0200, Emilio Pozuelo Monfort wrote: >... > Please note that there's a gosa package in opu for the upcoming point release. > So it'd be good to wait with this until after the point release to avoid any > conflicts. I've just added notes about pending stretch-pu updates for the following packages to dla-needed.txt: - gosa (Chris Lamb) - nginx (Sylvain Beucler) - rails (Sylvain Beucler) - wpa (Abhijith PA) I would recommend anyone adding packages to dla-needed.txt this or next week searches for the package name at [1] and adds a note if there is a pending update for stretch. > Cheers, > Emilio cu Adrian [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org;dist=unstable
LTS report for June 2020
Hours worked: 17 hours DLAs released: DLA 2262 qemu CVE-2020-1983 CVE-2020-13361 CVE-2020-13362 CVE-2020-13765 DLA 2266 nss CVE-2020-12399 CVE-2020-12402 DLA 2267 libmatio CVE-2019-17533
LTS report for May 2020
Hours worked: 5 hours DLAs published: DLA 2231-1 sane-backends CVE-2020-12867
Re: How to handle back-to-back firefox-esr uploads
On Mon, Jun 08, 2020 at 09:22:22AM -0400, Roberto C. Sánchez wrote: >... > My intent is to upload firefox-esr_68.9.0esr-1~deb8u2 once the build is > complete and then go through the normal DLA reservation/publication > process with a version number of 68.9.0esr-1~deb8u2 (once the amd64 > buildd completes its job successfully). I will use the advisory text > from DSA 4695-1 (the corresponding DSA for firefox-esr in stable and > oldstable) and add a note that 68.9.0esr-1~deb8u1 was the first version > to actually contain the referenced fixes. Should I include in the note > anything about the reason for the ~deb8u2 revision relating to the > build? Any other suggestions on what I should include/not include? I would include the high-level information to avoid confusion: 68.9.0esr-1~deb8u2 fixes an i386 build error in the otherwise identical 68.9.0esr-1~deb8u1 that was uploaded but not announced. > Regards, > > -Roberto >... cu Adrian
Re: Request to delay Jessie end date due to current conditions
On Fri, Apr 03, 2020 at 06:25:27PM -0400, Ariel Shkedi wrote: > > (I apologize if this was already discussed before.) > > I would like to request that the end date of Jessie LTS support be delayed > by 3 months due to current conditions. > > I know this means additional work on the volunteers, Debian LTS is not a volunteer project, it is done by people paid with money from sponsoring companies.[1] > but because of current > conditions many company teams are not able to schedule the necessary time to > perform this upgrade (and obviously we waited until the last minute...). Your company has the opportunity to participate in funding security support for jessie after June 2020, see [2] for details. > Thank you for considering this, > -Ariel Shkedi Yours Adrian Bunk [1] https://www.freexian.com/en/services/debian-lts.html [2] https://deb.freexian.com/extended-lts/
Re: amd64-microcode, version number, no-dsa
On Sat, Mar 14, 2020 at 10:16:30PM +0100, Anton Gladky wrote: >... > * Package is non-free, should the amd64 and i386 binary packages both > be uploaded? >... No, the buildds can build packages in non-free. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable https://sources.debian.org/src/amd64-microcode/3.20191218.1/debian/control/#L10 https://buildd.debian.org/status/logs.php?pkg=amd64-microcode&arch=i386 > Thank you > > Anton cu Adrian
LTS report for January 2020
Hours worked: 3 hours Work done: DLA 2091-1 libjackson-json-java CVE-2017-7525 CVE-2017-15095 CVE-2019-10172
LTS report for December 2019
Hours worked: 4.5 hours Work done: DLA 2054-1 jhead CVE-2018-16554 CVE-2018-17088 CVE-2019-1010301 CVE-2019-1010302
LTS report for November 2019
Hours worked: 18 hours Work done: DLA 1698-2 file regression update DLA 2017-1 asterisk CVE-2019-18610 CVE-2019-18790 DLA 2018-1 proftpd-dfsg CVE-2019-19269
Re: Issue with latest asterisk's security update in jessie
On Sun, Dec 01, 2019 at 09:14:24AM +0100, Bernhard Schmidt wrote: > Hi Jose, Hi Jose, > Thanks. This update was handled by the Debian LTS team. I will try to find > some time later tonight to check it out. thanks for the report and apologies for the breakage, there is now an +deb8u8 with the broken change reverted. > Best regards, > Bernhard cu Adrian
Re: Asterisk update breaks chan_sip loading
On Sun, Dec 01, 2019 at 09:04:07AM +0100, Marc SCHAEFER wrote: > Hello, > > the latest asterisk updates, with some documented changes in chan_sip, > has an issue for me (i386): > Version: 1:11.13.1~dfsg-2+deb8u7 >... Apologies for this, there is now an +deb8u8 with the broken change reverted. cu Adrian
Re: Issue with latest asterisk's security update in jessie
On Sun, Dec 01, 2019 at 02:08:13PM +0100, Bernhard Schmidt wrote: > Am 01.12.19 um 10:37 schrieb Adrian Bunk: > > Hi Adrian, Hi Bernhard, > >> Thanks. This update was handled by the Debian LTS team. I will try to find > >> some time later tonight to check it out. > > Thanks for the report. > > This was my update, and I am currently looking into this. > > Thanks. I see that you uploaded +deb8u8, which works fine for me. yes, I reverted the change that broke. Why it was broken was easy to understand, more embarrassing was understanding how my testing was botched. > You you have a git repo to push to > https://salsa.debian.org/pkg-voip-team/asterisk/tree/jessie ? Otherwise > I'll just import the dscs. Please import the dscs. > Bernhard Thanks Adrian
Re: Issue with latest asterisk's security update in jessie
On Sun, Dec 01, 2019 at 09:14:24AM +0100, Bernhard Schmidt wrote: > Hi Jose, > > Thanks. This update was handled by the Debian LTS team. I will try to find > some time later tonight to check it out. Thanks for the report. This was my update, and I am currently looking into this. > Best regards, > Bernhard cu Adrian
LTS report for June 2019
Hours worked: 6 hours Work done: DLA 1840-1 golang-go.crypto CVE-2019-11840 cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Triaging request for golang-go.crypto
On Wed, May 29, 2019 at 10:33:59AM +, Mike Gabriel wrote: > Hi Adrian, hi all other LTS contributors with Go knowledge, Hi Mike, > can anyone of you possibly take a closer look at golang-go.crypto [1] and > triage CVE-2019-11840. The only actual code change is in the assembler in https://go.googlesource.com/crypto/+/b7391e95e576cacdcdd422573063bc057239113d%5E!/#F1 It looks affected, I've added it to dla-needed.txt assigned to myself. > Thanks, > Mike (with LTS frontdesk hat on these days) >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
LTS report for April 2019
Hours worked: 8 hours Work done: DLA-1768-1 checkstyle CVE-2019-9658 Work on an update of libmatio is still ongoing. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: debhelper and friends for LTS
On Tue, Apr 23, 2019 at 12:46:54PM +0200, Ondřej Surý wrote: > Hey, > > the jessie-backports removal itself is a logical step and it’s good that it > was done. > > That said, it complicates things a lot when backporting packages to Jessie. > Usually, it’s fine to just pull $random extra library to the extra > repository, but debhelper and friends is a different beast, as it often > requires upgrades in steps, or pulling some extra packages or dropping them, > etc. The packages are still available after the removal: deb [check-valid-until=no] http://archive.debian.org/debian jessie-backports main > This is now especially painful with the differences between debhelper compact > 9/10 and 11/12 as those changes require reverting lots of tiny bits in the > source packages as more and more gets converted to v12. > > I don’t have a good solution for this, but keeping the debhelper and friends > (dpkg-dev, dh_) in an extra suite would be very much helpful for people > like me backporting bigger stacks to Jessie. I provide PHP (5.6, 7.0 and up), > apache2, nginx, ... and it’s very painful from time to time. >... AFAIK debhelper >= 11 was never in jessie-backports-sloppy. And the requirement to backport packages like cmake or meson from buster would make it *very* painful for anyone trying to backport debhelper 12 to jessie. > Cheers, > Ondrej cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
LTS report for March 2019
Hours worked: 8 hours Work was started on updates for checkstyle and libmatio. Work on them will be continued in the next days. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
LTS report for February 2019
Hours worked: 8 hours Work done: DLA-1687-1 sox CVE-2014-8145 DLA-1698-1 file CVE-2019-8905 CVE-2019-8907 As part of this also marked that the vulnerable code for CVE-2019-8904 and CVE-2019-8906 was added after the versions in jessie and stretch. DLA-1699-1 ldb CVE-2019-3824 cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bug#921663: Please add python-certbot update to jessie-backports
On Sat, Feb 09, 2019 at 08:37:09AM +, Ian Campbell wrote: >... > There is no need for an exception, jessie-backports is not the right > place to be fixing this issue even if it were still open. It should be > fixed by an update to either Jessie itself of the security suite. >... certbot is not in jessie, so nothing to fix/update there. jessie-backports is no longer supported and closed since the non-LTS EOL of jessie in June 2018. It might in theory be possible that the LTS team maintains backports until the LTS EOL of a release, but right now this is not being done. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: armel/armhf in stretch LTS
On Wed, Aug 29, 2018 at 09:43:41PM +0100, Steve McIntyre wrote: > On Wed, Aug 29, 2018 at 11:29:51PM +0300, Adrian Bunk wrote: > >On Wed, Aug 29, 2018 at 09:07:45PM +0100, Steve McIntyre wrote: > >> > >> This is utterly premature and unwarranted. Don't be ridiculous. > > > >Personal attacks don't change the facts. > > You *are* being ridiculous. You're claiming to know ~2 years early > what we'll end up with. stretch LTS and buster have the same EOL, and for armel/armhf they have the same buildd problem. > >> So long as there are people interested enough in LTS for those > >> architectures to cover the work and costs, there's no reason to stop. > > > >"work" would include that there have to be buildds running and > >maintained outside the Debian infrastructure. > > > >"work" would also include that every package built by these buildds will > >have to be manually signed by a DD before it can enter stretch-security, > >similar to what is currently done for kfreebsd-*. > > > >This would not be completely imposible, but an order of magnitude > >more "work and costs" than for an architecture that has normal > >DSA-maintained buildds. > > Enjoy your preconceptions. *Nothing* of what you're writing here might > actually be necessary. How about waiting a little to see how things > develop? How much exactly is "waiting a little"? Building armel for buster is an urgent issue on my plate, if you have a solution for that please share it. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: armel/armhf in stretch LTS
On Wed, Aug 29, 2018 at 09:07:45PM +0100, Steve McIntyre wrote: > On Wed, Aug 29, 2018 at 11:02:59PM +0300, Adrian Bunk wrote: > >On Fri, Aug 17, 2018 at 09:40:53AM +, Holger Levsen wrote: > >>... > >> also, https://wiki.debian.org/LTS/ since more than a year explained that > >> jessie LTS would not support arm64, so again, plenty of warning. > >>... > > > >Speaking about advance-warning, please remove armel and armhf from the > >list of architectures planned for stretch LTS. > > > >Building armel or armhf in stretch on armv8 hardware is untested, > >and for armhf there are known problems in unstable. > > > >The current 32bit armv7 builders are scheduld to be decommissioned > >by DSA after the non-LTS lifetime of stretch, there won't be any > >buildds suitable for building armel/armhf for stretch LTS. > > This is utterly premature and unwarranted. Don't be ridiculous. Personal attacks don't change the facts. > So long as there are people interested enough in LTS for those > architectures to cover the work and costs, there's no reason to stop. "work" would include that there have to be buildds running and maintained outside the Debian infrastructure. "work" would also include that every package built by these buildds will have to be manually signed by a DD before it can enter stretch-security, similar to what is currently done for kfreebsd-*. This would not be completely imposible, but an order of magnitude more "work and costs" than for an architecture that has normal DSA-maintained buildds. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
armel/armhf in stretch LTS
On Fri, Aug 17, 2018 at 09:40:53AM +, Holger Levsen wrote: >... > also, https://wiki.debian.org/LTS/ since more than a year explained that > jessie LTS would not support arm64, so again, plenty of warning. >... Speaking about advance-warning, please remove armel and armhf from the list of architectures planned for stretch LTS. Building armel or armhf in stretch on armv8 hardware is untested, and for armhf there are known problems in unstable. The current 32bit armv7 builders are scheduld to be decommissioned by DSA after the non-LTS lifetime of stretch, there won't be any buildds suitable for building armel/armhf for stretch LTS. > cheers, > Holger cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Wheezy update of ming?
On Thu, Nov 10, 2016 at 07:42:40PM +, Chris Lamb wrote: > Hello dear maintainer(s), > > the Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of ming: > https://security-tracker.debian.org/tracker/source-package/ming > > Would you like to take care of this yourself? >... ming is orphaned and noone intends to adopt it (see #838773), so please go ahead. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Wheezy update of sendmail?
On Sun, Oct 23, 2016 at 08:59:47AM +0100, Chris Lamb wrote: > Hello dear maintainer(s), > > the Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of sendmail: > https://security-tracker.debian.org/tracker/source-package/sendmail > > Would you like to take care of this yourself? >... sendmail is orphaned, so there is no maintainer. Andreas (Cc'ed) did some basic maintainance on sendmail recently, but I doubt he would opposed to the LTS team taking care of this issue. > Regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On Sat, Oct 22, 2016 at 01:02:53PM +0200, Guido Günther wrote: > On Fri, Oct 21, 2016 at 11:30:04AM +0100, Chris Lamb wrote: > > Guido Günther wrote: > > > > > I'd just use bin/report-vuln ? > > > > … one of these days I'm going to look at everything in bin/* and actually > > remember what it does :) > > > > (Yay, for saving myself writing such a thing!) > > > > > I'd say unstable and then "found". > > > > How come, out of interest? AIUI the tradeoff here is that if the "found" > > step > > gets skipped, the BTS does not believe it is vulnerable and thus it won't > > get > > (correctly) kicked out of testing, etc. etc. > > IIRC if we file against wheezy not all newer versions get marked as > affected (but I might be wrong) so there is a found/notfound step > involved in either case atm. This depends on whether the version in wheezy is an ancestor of the versions in stable/testing/unstable. As an example, consider the following versions in the changelog of a 1.0-3 package in unstable: 1.0-3 1.0-2 1.0-1 You report a bug against the version in wheezy. If 1.0-1 is in wheezy, version tracking knows that this is an ancestor of 1.0-3 and will consider the version in unstable affected. If 1.0-1+deb7u1 is in wheezy, this is not an ancestor listed in the changelog in unstable, and therefore version tracking will not consider the version in unstable as affected. Marking it as found in either 1.0-1 or 1.0-3 [1] will mark 1.0-3 as affected. Easiest in practice would be to report against wheezy, and then check the version tree of the bug in the BTS. > Cheers, > -- Guido cu Adrian [1] 1.0-2 would also work -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: version number when packaging a new upstream release
On Fri, Oct 07, 2016 at 09:11:15AM +0200, Raphael Hertzog wrote: > Hi, > > On Thu, 06 Oct 2016, Adrian Bunk wrote: > > On Thu, Oct 06, 2016 at 06:16:37PM +0200, Raphael Hertzog wrote: > > > On Thu, 06 Oct 2016, Adrian Bunk wrote: > > >... > > > > Do you have any rationale why you think -1~deb7u1 would be better > > > > than -0+deb7u1? > > > > > > My preference goes for the former because it matches the logic of > > > backported packages and thus does not introduce a new concept while > > > -0+deb7u1 is not something we use in another context. > > > > -0+deb7u1 is a concept already used in DSAs for exactly this purpose. > > It's not always the case. Check out all the OpenJDK DSA, just like > MySQL we import newer upstream releases: > https://lists.debian.org/debian-security-announce/2016/msg00028.html > https://tracker.debian.org/pkg/openjdk-7 > > So while it has been used it's not the only one in use in the context > of the security team. >... It is a different version numbering than the MySQL 5.5 case because it is a different situation. This OpenJDK DSA is not a packaging of a new version for the DSA only like MySQL 5.5, it is a backport (in this case from experimental): https://tracker.debian.org/media/packages/o/openjdk-7/changelog-7u111-2.6.7-1~deb7u1 cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: version number when packaging a new upstream release
On Thu, Oct 06, 2016 at 06:16:37PM +0200, Raphael Hertzog wrote: > On Thu, 06 Oct 2016, Adrian Bunk wrote: >... > > Do you have any rationale why you think -1~deb7u1 would be better > > than -0+deb7u1? > > My preference goes for the former because it matches the logic of > backported packages and thus does not introduce a new concept while > -0+deb7u1 is not something we use in another context. -0+deb7u1 is a concept already used in DSAs for exactly this purpose. I just found a good example how the versioning you are suggesting could cause real problems: https://lists.debian.org/debian-lts-announce/2016/09/msg00017.html https://www.debian.org/security/2016/dsa-3666 If LTS would switch to your suggested -1~deb7u1, then a wheezy user who got your LTS package might not get future security fixes like -0+deb8u2 or -0+deb8u9 after upgrading to jessie. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
