Re: How to handle freeimage package
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. Cheers, Moritz
Re: gtkwave update for {bookworm,bullseye,buster}-security
Hi Adrian, > >... > > > debdiffs contain only changes to debian/ > > > > The bookworm/bullseye debdiffs looks good, please upload to > > security-master, thanks! > > both are now uploaded. DSA has been released, thanks! > > 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.) You're correct indeed. Cheers, Moritz
Re: Security releases for ecosystems that use static linking
Thorsten Alteholz wrote: [ Adding DSA to the CC list ] > On Mon, 18 Mar 2024, Emilio Pozuelo Monfort wrote: > > > One solution which has been discussed in the past is to import a full copy > > > of stable towards stable-security at the beginning of each release cycle, > > > but that is currently not possible since security-master is a Ganeti VM > > > and the disk requirements for a full archive copy would rather require > > > a baremetal host. > > > (... suggestion of Emilio ...) > > > > Thoughts? > > The idea is nice, but needs someone to implement it. > > Anyway, the problem is not really new. Since many years, not to say decades, > I hear that there is not enough space on security-master. > I also hear that Debian has so much money and problems to spend it. > So why not solve this problem by buying new hardware? This can not be that > difficult. Is there any reason why security-master needs to be a Ganeti VM? The obvious reason is to avoid hardware refreshes and better redundancy, but I agree it would be really great to move forward with a solution for security-master. The current setup where security.d.o only holds a subset of the archive has long-standing issues which cause a lot of toil for FTP masters and people making security uploads: - Every initial upload of a package using Built-Using needs manual FTP master interaction - The need to inclucde full source into the initial upload leads to unneeded roundtrips when people forget it (and there's also even crazier cornercases like a new foo.tar.gz for oldstable-security and stable-security at the same time) - No possibility for binNMUs, leading to a need for sourceful uploads if needed Cheers, Moritz
Re: Guidance for CVE triage and listing packages in dla-needed.txt
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. Cheers, Moritz
Re: Security releases for ecosystems that use static linking
On Mon, Mar 18, 2024 at 01:13:15PM +0100, Emilio Pozuelo Monfort wrote: > [ Adding debian-dak@ to Cc ] > > One solution which has been discussed in the past is to import a full copy > > of stable towards stable-security at the beginning of each release cycle, > > but that is currently not possible since security-master is a Ganeti VM > > and the disk requirements for a full archive copy would rather require > > a baremetal host. > > What if the overrides list was updated regularly but the sources were only > imported on-demand? e.g. upon a new upload > - trigger override update from ftp-master > - if upload is sourceless and source is not present: > - try to import source from ftp-master > > This would also solve the current problem that an update on security-master > may have the same version but different orig tarball than the one on > ftp-master. We'd need an estimate which percentage of a given release sees an update via foo-security over the five year period (plus some wiggle room for a potentially increased rate of updates for rust/go) to make sure that disk space on security-master supports such a setup. But the approach per se seems solid to me. Cheers, Moritz
Re: libssh CVE-2023-6004, CVE-2023-6918, CVE-2023-48795
[ You missed the correct mailing list. debian-security is _not_ the correct way to reach the security team, fixing ] On Sun, Dec 24, 2023 at 09:12:04AM +, Sean Whitton wrote: > Hello, > > I have taken responsibility for fixing these CVEs in libssh in buster, > as part of Freexian-funded LTS work. I would like to see if I can help > get them fixed in bullseye & bookworm in parallel, to avoid a situation > where they're fixed in buster but not fixed in releases to which LTS > users might soon upgrade their machines. > > I see the fixes are all in sid. Are you expecting to issue DSAs for > bullseye and bookworm? I would be grateful for some information on the > sec team's plans for these fixes. There will be updates via s.d.i, but with some intentional delay to first spot regressions based on the upload to sid. Cheers, Moritz
Re: Security releases for ecosystems that use static linking
On Fri, Dec 22, 2023 at 10:19:15AM -0300, Santiago Ruano Rincón wrote: > El 22/12/23 a las 09:54, Moritz Muehlenhoff escribió: > > On Thu, Dec 21, 2023 at 07:30:51PM -0300, Santiago Ruano Rincón wrote: > > > So let me ask you: are you interested in addressing the infrastructure > > > limitations to handle those kind of packages? and having some help for > > > that? > > > > Foremost this is an infrastructure limitation that needs to be resolved: > > security-master and ftp-master use separate dak installations, which makes > > binNMUs in the current form untenable since every package would need a > > source-fule upload first (the same reason why currently the first upload > > of a package to foo-security needs a sourceful upload). > > > > One solution which has been discussed in the past is to import a full copy > > of stable towards stable-security at the beginning of each release cycle, > > but that is currently not possible since security-master is a Ganeti VM > > and the disk requirements for a full archive copy would rather require > > a baremetal host. > > If a baremetal host would be the first requirement, may I volunteer to > try to find one? If yes, do you have any idea of the required space and > HDD setup? These hosts are managed by the DSA team, this all needs to be discussed/sorted out with them. Cheers, Moritz
Re: Security releases for ecosystems that use static linking
On Thu, Dec 21, 2023 at 07:30:51PM -0300, Santiago Ruano Rincón wrote: > So let me ask you: are you interested in addressing the infrastructure > limitations to handle those kind of packages? and having some help for > that? Foremost this is an infrastructure limitation that needs to be resolved: security-master and ftp-master use separate dak installations, which makes binNMUs in the current form untenable since every package would need a source-fule upload first (the same reason why currently the first upload of a package to foo-security needs a sourceful upload). One solution which has been discussed in the past is to import a full copy of stable towards stable-security at the beginning of each release cycle, but that is currently not possible since security-master is a Ganeti VM and the disk requirements for a full archive copy would rather require a baremetal host. Cheers, Moritz
Re: Build missing for buster-security/non-free - intel-microcode
On Sat, Aug 19, 2023 at 09:22:14PM +0530, Utkarsh Gupta wrote: > Hey, > > On Sat, Aug 19, 2023 at 9:12 PM Vincent wrote: > > It would be very appreciated if someone complete the > > build of intel-microcode for the buster-security/non-free. > > Yep, I've uploaded the source but will upload the amd64 and i386 binaries now. Did you upload anything? There have been no accept or rejects for these, FWIW. Cheers, Moritz
Re: Possibility of LTS fix for Samba?
On Thu, Jul 20, 2023 at 01:30:32PM +0300, Michael Tokarev wrote: > Hi! > > It come to my attention that a discussion is happening about samba > and LTS (and the same applies to oldstable too). It's also worth noting that support for running Samba as an AD domain controller was already EOLed two years ago in https://lists.debian.org/debian-security-announce/2021/msg00201.html Cheers, Moritz
Re: c-ares, CVE-2023-31147, CVE-2023-31124
On Fri, Jun 23, 2023 at 06:48:23AM +0200, Anton Gladky wrote: > Hi, > > two CVEs might be irrelevant for Debian systems. Can they be > tagged as "unaffected"? Or we have some systems, where > /dev/urandom is not existing? They are already marked as non-issues: CVE-2023-31124 (c-ares is an asynchronous resolver library. When cross-compiling c-are ...) - c-ares (unimportant) NOTE: No impact on binaries shipped by Debian CVE-2023-31147 (c-ares is an asynchronous resolver library. When /dev/urandom or RtlGe ...) - c-ares (unimportant) NOTE: Any Debian system/port provides /dev/urandom But in fact the view in the Debian security is a little misleading, given that it displays "vulnerable" all over the place, e.g. https://security-tracker.debian.org/tracker/CVE-2023-31147 It would be nice if that "unimportant" issues it would instead display "non issue/no impact" instead of "vulnerable. Cheers, Moritz
Re: [buster] CVE-2022-46871: libusrsctp maybe backporting a new version ?
On Mon, Jun 19, 2023 at 07:40:30PM +0200, Ben Hutchings wrote: > On Mon, 2023-06-19 at 11:02 +, roucaries bastien wrote: > > Le dim. 18 juin 2023 à 19:16, Ola Lundqvist a écrit : > > [adding security team] > [...] > > > > > You mention rebuild all reverse dependencies. Well I do not find any > > > within Debian. > > > This makes it even less important to fix it. > > > > Yes, but for firefox it is embeded (code duplication not nice). May be > > (so copy security team) deemded it and link to the lib. Less work > > So we can expect Firefox upstream to update their copy. Firefox has updated their copy about half year ago, this is how this issue become publicly known in the first place. Cheers, Moritz
Re: Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
On Wed, Jun 07, 2023 at 01:43:26PM +0530, Utkarsh Gupta wrote: > Hi Chris, > > On Wed, Jun 7, 2023 at 12:56 PM Salvatore Bonaccorso > wrote: > > Can you please have a look, as this seems to be caused by the DLA > > issued as DLA-3447-1. > > This has been caused by the ruby2.5 update. It's definitely related to the fix for CVE-2023-28755, reverting that patch unbreaks Puppet. I'd recommend to go ahead with a revert for now. > Can you please TAL? This > is perhaps because of the URI version in buster v/s URI version > upstream. The upstream patch was supposed to be for 3.2 and was not > 2.5 compliant. Let me know if you'd like me to help. Specifically https://www.ruby-lang.org/en/news/2023/03/28/redos-in-uri-cve-2023-28755/ states: | For Ruby 2.7: Update to uri 0.10.0.1 | For Ruby 3.0: Update to uri 0.10.2 | For Ruby 3.1: Update to uri 0.11.1 | For Ruby 3.2: Update to uri 0.12.1 And the 0.10 change (https://github.com/ruby/uri/commit/17861a53e499a2eabf7ba83d63914d0f01921d70) is different from the 0.12 one (https://github.com/ruby/uri/commit/eaf89cc31619d49e67c64d0b58ea9dc38892d175) There might be other changes needed for 2.5, not sure. Cheers, Moritz
Re: Triage status for a few old packages
On Sat, Apr 22, 2023 at 04:12:53PM +0200, Salvatore Bonaccorso wrote: > This is more a personal view: I do not see much benefit in keeping > sqlite supported. Agreed, while you're free to add entries for sqlite, it feels without practical benefit. Cheers, Moritz
Re: Triage status for a few old packages
On Wed, Apr 12, 2023 at 10:58:15PM +0200, Salvatore Bonaccorso wrote: > > - For python2.7, AFAIU you would be inclined to associate CVEs to that > > package more often, for the duration of buster-lts, which would help a lot. > > On the LTS side we'd like to associate all the past python3.x CVEs to > > python2.7 (13 CVEs) and triage them accordingly (so we can easily compare > > python2 and python3 status). > > Would that be OK? > > >From my side no objection on that. If you do not hear a NACK, go ahead > with it. Yeah, that sounds fine. > > - For gnupg1, we'd like to reference it in > > debian-security-support/security-support-limited (or > > security-support-endedXX). > > Would that be OK? > > Inclided to say to add it to security-support-limited. The reference > to the release notes might suffice as explanation, or you can be more > verbose and reference #982258. It lists reasons for still keeping > src:gnupg1 to handle specific usecases. Ack. Cheers, Moritz
Re: [Pkg-clamav-devel] Bug#1031509: ETA on Patch for Buster
Version: 0.103.8+dfsg-0+deb10u1 On Tue, Feb 21, 2023 at 08:12:54PM +0100, Sebastian Andrzej Siewior wrote: > +LTS > > On 2023-02-20 12:22:48 [+0200], Andries Malan wrote: > > Hi There > Hi, > > > Would you be so kind as to provide an ETA for the above mentioned bug that > > was reported. > > This would be greatly appreciated. > > I Cced the LTS team because Buster is LTS territory. An update for Buster has already been released yesterday: https://lists.debian.org/debian-lts-announce/2023/02/msg00022.html Cheers, Moritz
Re: Upgrades from Stretch to Bullseye and from Buster to Bookworm broken
On Sun, Oct 23, 2022 at 08:23:20PM -0700, Otto Kekäläinen wrote: > Hello LTS team! > > Users of Debian LTS are currently affected by a bug that prevents > skipping Debian releases. If skipping a release is not possible in an > upgrade, it makes using LTS kind of moot. Skipping a release has never been supported, plenty of maintainer scripts and lower level tooling only handle migration steps for the subsequent release. It also doesn't make LTS releases moot, since it's they among other things they enable to deploy a setup to a baremetal server through the typical 4-5 years lifetime. Cheers, Moritz
Re: What do do with bullseye minor issues?
On Thu, Sep 29, 2022 at 09:09:29AM +0200, Emilio Pozuelo Monfort wrote: > On 28/09/2022 23:54, Ola Lundqvist wrote: > > Hi Sylvain > > > > Took me a month to get down here in the email backlog. I think your > > reasoning makes sense. > > I have added the following to the LTS/Development page. > > > > "If a CVE has been fixed in Debian Stable it should, in general, be fixed > > in LTS as well, or marked as ignored. It does not make sense to have such > > CVEs marked as postponed or no-dsa since either the Debian Security team or > > the maintainer have decided that it was worth fixing." > > Please update that page if you think I was unclear or wrong. > > I don't think that's correct. Say for example: FWIW, I'm planning to add a proposal to https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/23 but haven't found the time yet, maybe this week not sure. Cheers, Moritz
Re: [SECURITY] [DLA 3107-1] sqlite3 security update
On Wed, Sep 14, 2022 at 11:34:57AM +0200, Santiago Ruano Rincón wrote: > If I am not wrong, DLAs should be claimed/announced once the upload has > been completed and accepted. I think this is documented here: > > https://wiki.debian.org/LTS/Development#Announce_the_update > > "Only when you have confirmed that the package was processed after > upload (once you get the accept email) should you send the DLA to the > mailing list. " In the case of DLA uploads you should rather even wait a little longer; since there's no queue and if you've made a source upload for a large package it might take some time until it's built. If you send the DLA mail too early (at least wait until amd64 is uploaded by the buildds for an arch:any package), people will get confused that no update is available. Cheers, Moritz
Re: Closing of buster-backports?
On Wed, Sep 07, 2022 at 09:32:15AM -0700, Noah Meyerhans wrote: > The cloud team publishes images for various cloud environments > (OpenStack, Amazon EC2, etc). The primary (and most popular, from the > data I have) images use the main kernel, but we publish alternative > images that boot the backports kernel by default. > > Is there a plan to continue offering new kernels for buster LTS? Yes, the 5.10.x kernels as shipped in Bullseye are provided for Buster LTS as src:5.10: https://packages.qa.debian.org/l/linux-5.10.html Cheers, Moritz
Re: Bug#1010671: libsdl2-ttf-dev: CVE-2022-27470 - Arbitrary memory overwrite loading glyphs and rendering text
On Wed, Jul 20, 2022 at 10:52:48AM +0100, Simon McVittie wrote: > Control: unarchive -1 > Control: tags -1 + bookworm sid > > On Fri, 06 May 2022 at 15:25:00 +0100, Neil Williams wrote: > > CVE-2022-27470[0]: > > | SDL_ttf v2.0.18 and below was discovered to contain an arbitrary > > | memory write via the function TTF_RenderText_Solid(). This > > | vulnerability is triggered via a crafted TTF file. > > buster and bullseye (which happen to have an identical libsdl2-ttf > version) do not appear to be vulnerable to this. The code that has > the overflow seems to have been introduced in commit 31589bd "Wrapped > functions, Optimized routines, Lsb/Rsb positioning, Subpixel Hinting" > shortly after 2.0.15, so it isn't in buster or bullseye. Thanks, I've updated the Debian Security Tracker accordingly. Cheers, Moritz
Re: What to do with sox
On Mon, Jun 27, 2022 at 04:01:46PM +0200, Enrico Zini wrote: > Hello, > > every once in a while I have a look at sox, which has many CVEs open and > no updates since 3 months, wondering what could be done about it. > > It seems that all the CVEs have reproducers but not patches. Should I > try to work on patches for some of them? I don't mind doing it but it > may be nontrivial work, as it may require reading up on the specific > audio formats involved. > > Otherwise, should the issues that have been without patches for months > now be tagged with no-dsa for the time being, as most of them are for > buster and bullseye? The only relevant open CVE ID for sox is CVE-2021-40426, the other ones are completely negligible. But it's unclear to which extent CVE-2021-40426 was reported upstream, https://talosintelligence.com/vulnerability_reports/TALOS-2021-1434 mentions "2022-01-14 - Follow up with vendor; vendor acknowledged", but it's e.g. not found in the existing bug tracker, so I think reporting it in their tracker with a question of the status of a patch is a sensible first step. If they state they are too busy, work could resume on writing one. Cheers, Moritz
Re: Support for ckeditor3 in Debian
On Tue, May 31, 2022 at 05:42:00AM +, Mike Gabriel wrote: > Hi Moritz, Salvatore, Sylvain, > > On Mo 30 Mai 2022 20:04:14 CEST, Moritz Mühlenhoff wrote: > > > Am Sun, May 29, 2022 at 09:36:43AM +0200 schrieb Salvatore Bonaccorso: > > > While this is discouraged in general, we could opt here for this, to > > > avoid that ckeditor3 might get additional users outside of > > > php-horde-editor. > > > > This would also mean that only those bits of ckeditor3 which are actually > > used by Horde need to be updated. > > > > Cheers, > > Moritz > > I read that embedding is ok with the security team for the exceptional case > php-horde-editor. I will put this on my todo list for the next Horde update > round (which is already overdue). Great! And let's make sure to remove ckeditor3 when that is complete, ofc :-) Cheers, Moritz
Re: Urgency for uploads
Hi Enrico, > in the Developers's reference[1] it says, in boldface, that security > updates should be built with "urgency=high". This is incorrect advice and I have idea where it came from. The urgency is completely irrelevant for any security upload to LTS/oldstable/stable, only for testing-security uploads when these were still a thing (maybe that's how this trickled in). Cheers, Moritz
[SECURITY] [DLA 2847-1] mediawiki security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian LTS Advisory DLA-2847-1debian-...@lists.debian.org https://www.debian.org/lts/security/ Moritz Muehlenhoff December 15, 2021 https://wiki.debian.org/LTS - - Package: mediawiki Version: 1:1.27.7-1+deb9u11 CVE ID : CVE-2021-44858 A security issue was discovered in MediaWiki, a website engine for collaborative work: Missing validation in the mcrundo action may allow allow an attacker to leak page content from private wikis or to bypass edit restrictions. For additional information please refer to https://www.mediawiki.org/wiki/2021-12_security_release/FAQ For Debian 9 stretch, this problem has been fixed in version 1:1.27.7-1+deb9u11. We recommend that you upgrade your mediawiki packages. For the detailed security status of mediawiki please refer to its security tracker page at: https://security-tracker.debian.org/tracker/mediawiki 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- iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAmG6SM4ACgkQEMKTtsN8 TjY+WA/7Bmk+zIS5SDNFiz3WhZe8AVe0zf4e89y4MoGD1mnPfUNjSQrnc6u7v/5y 6JE5Pz+hj0XVyp7SxB3+aVMKv2REt+DlGXVXckhESm2MTHnYcPOnmVBrVnBLQZtj hAM+tyFwMn0s6mEFblI38c0z4G6p38TIl5bLSBdCVTpOz80mgMekoIt10m51BOEW FWsOYWGPjzgZIU2/FmMjZpdIOFft7EHxuMZv5lQ7wmFX3JifhjU2hYlShgZNpVwW cxLYZ/RhXF4ptnlRvQOhk+wcFcmw/W9HfoCHB9Asijn0Fuxl8RPpx7LBSRY3Ao+J 07W2m0LbhVIvnbT83YyB2YNtddY/CkPH0aS574xHEfJ3Q4xjLdNC/LK7S9oKXoYI wQaWnMEUhMIk6JsWJ4tTFWkGg22T2lbEJCqwdYvQoqiq+LdfUpFa9FN3PLeVl/lC qTi1nrMI0PuyBGKr5UUWltQpaP14dJrGXgvvqZqvefnSqy9j8f64Uy/iAPRRWjoL IeD8lLtgYY83X1bakjEK5EL3ACFHK+dxuRtES48fkMXw7QzutyKQwqeo0BxYyL6G 2et34200NU+yMQld+QARWIg9m5fhZFUYWj160LdiN9XA84XuFgJ8WHtvkaRWS7Ri 8HLUZdWR8bYwl7iUk4Z6180+PO9/2HTxerkAHKklvMvCg3WKx6Y= =GNb2 -END PGP SIGNATURE-
Re: Firmware-nonfree update for buster?
On Wed, May 19, 2021 at 08:59:16PM +0200, Ola Lundqvist wrote: > In any case, thank you for your help. Now I know that there are no such > plans and you would not object to the LTS team doing an update on > stable/buster. This was exactly what I wanted to know. *sigh*, ofc you should _not_ look into an update for Buster without really understanding the problem. For that you'd need to backport the patch which allows to use the new firmware to 4.19 and get it accepted into the 4.19.x LTS series.
Re: Firmware-nonfree update for buster?
Ola Lundqvist wrote: > I only briefly looked at the CVEs. If you haven't even looked the issues properly don't waste other people's time.
Re: Firmware-nonfree update for buster?
On Mon, May 17, 2021 at 11:54:05AM +0200, Ola Lundqvist wrote: > Hi firmware-nonfree maintainers > > I have a question from an LTS perspective about the possible security > updates we have for the firmware-nonfree package. > > You can find them here: > https://security-tracker.debian.org/tracker/source-package/firmware-nonfree Did you even look at the CVEs in question? CVE-2020-1236[2,3,4] need a kernel patch to actually allow to use the new firmware and that patch isn't present in 4.19 (and ofc also not in 4.9) Cheers, Moritz
Re: buster update for jackson-databind
On Mon, Apr 19, 2021 at 02:40:56PM +0200, Markus Koschany wrote: > Hi, > > Am Montag, den 19.04.2021, 13:15 +0530 schrieb Utkarsh Gupta: > > Hello, > > > > There are 18 no-dsa marked entries for jackson-databind for buster, > > the same ones I fixed for jessie and also the same ones that I intend > > to work on for stretch. It'd be thus unfair if those are pending in > > buster and so I ask if it'd be OK for me to prepare a corresponding > > update for buster (-pu)? > > > > If you agree, I could send a debdiff in the next couple of days and > > upload after your ack? Let me know what you think? > > Fine with me. A buster-pu should be sufficient unless the security team thinks > differently. Ack, agreed. Cheers, Moritz
Re: Regression in lxml in buster/stretch
On Thu, Dec 17, 2020 at 09:10:44PM +0100, Emilio Pozuelo Monfort wrote: > Hi, > > There's a regression in both buster and stretch in the last update of lxml > when running under Python 2: > > >>> import lxml.html.clean > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python2.7/dist-packages/lxml/html/clean.py", line 73, in > > r' AttributeError: 'module' object has no attribute 'ASCII' > >>> > > The fix is [1]. > > I recently added support to run the tests to lxml (see #976148). When > enabling the test suite, this bug is exposed (tested in stretch, should be > similar in buster): > > python2.7 test.py -vv > Traceback (most recent call last): > File "test.py", line 625, in > exitcode = main(sys.argv) > File "test.py", line 562, in main > test_cases = get_test_cases(test_files, cfg, cov=cov) > File "test.py", line 268, in get_test_cases > module = import_module(file, cfg, cov=cov) > File "test.py", line 209, in import_module > mod = __import__(modname) > File "/build/lxml-3.7.1/src/lxml/html/tests/test_clean.py", line 6, in > > from lxml.html.clean import Cleaner, clean_html > File "/build/lxml-3.7.1/src/lxml/html/clean.py", line 73, in > r' AttributeError: 'module' object has no attribute 'ASCII' > > And with the patch applied, the tests run, although some of the clean tests > are failing, probably because the last patch didn't backport the test suite > changes (which was not a problem as the tests weren't being run). > > Roberto, my changes for stretch are in [3]. Would you like to take a look at > this and finish it (probably backporting the test changes from [2]) or > should I? > > Moritz, if you want I can look at buster too. Ack, please do. The code is all quite similar across older distros from what I remember. Cheers, Moritz
Incomplete fix for CVE-2019-20218/sqlite3
Hi, CVE-2019-20218 isn't fixed in Stretch/LTS. Running the reproducer: CREATE TABLE v0 (a); CREATE VIEW v2 (v3) AS WITH x1 AS (SELECT * FROM v2) SELECT v3 AS x, v3 AS y FROM v2; SELECT * FROM v2; still trigger an infinite loop. On Buster it correctly bails out: sqlite> CREATE TABLE v0 (a); sqlite> CREATE VIEW v2 (v3) AS WITH x1 AS (SELECT * FROM v2) SELECT v3 AS x, v3 AS y FROM v2; sqlite> SELECT * FROM v2; Error: view v2 is circularly defined For the Buster update I also backported >From 46a31cdf6b7c1197e01627f91af601479cd99940 Mon Sep 17 00:00:00 2001 From: drh Date: Sat, 9 Nov 2019 14:38:58 + Subject: [PATCH] Make sure the WITH stack in the Parse object is disabled following an error. which seems missing in Stretch. Not sure if that's all or if 3.16 needs other changes as well, though. Cheers, Moritz
Re: MongoDB license change and security support
On Wed, Nov 25, 2020 at 07:25:57PM +0530, Utkarsh Gupta wrote: > Hello, > > On Wed, Nov 25, 2020 at 2:57 PM Sylvain Beucler wrote: > > Consequently I believe we're not in a position to offer MongoDB security > > support in LTS nor ELTS, and we need to drop it from our supported packages. > > > > What do you think? > > This does make sense. And I suppose the same applies for buster? > I've CCed the Security team to take their opinion as well! What Sylvain describes is correct, that's exactly why mongodb was dropped from buster. Cheers, Moritz
Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
On Wed, Sep 02, 2020 at 05:25:28AM +0900, Mike Hommey wrote: > Note Firefox doesn't need wasi-libc at the moment. Neither does > thunderbird AFAICT. Not Firefox/Thunderbird itself, but rustc in the versions needed by ESR 78 build depends on it. Cheers, Moritz
Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
On Tue, Sep 01, 2020 at 04:35:42PM +0200, Emilio Pozuelo Monfort wrote: > On 01/09/2020 14:05, Christoph Martin wrote: > > Hi, > > > > I am not shure if I can help, but I can try and have a look at it. > > > > Yes please upload your LLVM9 and wasi-libc backports. > > fwiw I started to look at this and have an LLVM 10 backport ready. Should we > go > with that instead? I'm fine either way. > It may be more future-proof, in case we need it for a future > rustc for the next ESR bump. My gut feeling is the next ESR thing will need LLVM 11 or so, but happy to be proven wrong :-) So maybe let's directly move to 10 directly. Once uploaded and acked threw NEW, I'll upload wasi-lib rebuilt against LLVM, then. Cheers, Moritz
Re: DLA template and user signatures
On Mon, Jul 13, 2020 at 08:16:03PM +1000, Brian May wrote: > Sylvain Beucler writes: > > > On 07/07/2020 12:01, Emilio Pozuelo Monfort wrote: > >> - it was brought up that some DLAs include personal signatures at the end > > > > In what context did you receive this feedback? > > I have found that I have to delete any personal signatures or the GPG > check will fail, and the email will (silently) never get published. The moderation script for debian-security-announce (and most definitely also debian-lts-announce) does a few sanity checks in addition to the PGP key validation. One of them is about the footer ending in "Mailing list: debian-security-annou...@lists.debian.org" and with your MUA appending a signature that breaks. Cheers, Moritz
Re: rails update
On Fri, Jul 10, 2020 at 11:55:37AM +0200, Sylvain Beucler wrote: > Hi, > > On 10/07/2020 10:28, Moritz Mühlenhoff wrote: > > On Wed, Jul 08, 2020 at 12:45:08PM +0200, Sylvain Beucler wrote: > >> Hi, > >> > >> - buster update > >> > >> I now "up-ported" my stretch work at: > >> https://www.beuc.net/tmp/debian-lts/rails-buster/ > >> + added the redis side of CVE-2020-8165 > > > > What do you mean with up-ported? Applying a patch made for an older release > > to a more recent release will miss all code which wasn't present in > > the older suite. > > To phrase it more precisely, I went back to the upstream patches for > 5.2, applied them and unit-tested them. Ah, ok! I'll have a look at this over the weekend. Cheers, Moritz
Re: fwupd_0.7.4-2+deb9u1 (was: "Re: Debian 9 (Stretch) LTS: archive side should be done")
On Thu, Jul 09, 2020 at 10:52:18AM +0100, Chris Lamb wrote: > However, as I understand it, this pu bug has not been confirmed yet > and this would actually update the version in oldstable to the > 0.8.x branch anyway, i.e. larger than my 0.7.4-2+deb9u1. I therefore > conclude that this is fine *this* time. Yeah, the 0.8 update will shortly supersede your 0.7.4-2+deb9u1 update. Cheers, Moritz
Re: Draft: Debian 8 Long Term Support reaching end-of-life
> Security support for Stretch LTS will be handed over on July 18, 2020, > after the last point release. What's that supposed to mean? Support for oldstable ends on the 6th And why was this not send to team@s.d.o? Cheers, Moritz
Re: Possible clashing of work
On Wed, Jul 01, 2020 at 09:20:51PM +0530, Utkarsh Gupta wrote: > 1. imagemagick/oldstable > > Right now, this package has been claimed in dla-needed.txt by Markus > and in dsa-needed.txt by jmm. Yeah, this is currently WIP and should be released soon. The buster-security update is already released and stretch-security will be a separate DSA since the set of fixed issues is very different. Cheers, Moritz
Re: Steps for Debian Jessie LTS end-of-life
On Wed, Jul 01, 2020 at 11:27:38AM +0200, Ansgar wrote: > Hi, > > since LTS for Jessie has ended according to [1], can we disable uploads > and prepare for archiving the release? > > I want to: > > 1. Stop accepting anything. > 2. Have one Release with no Valid-Until for archive.d.o (to try to >make some people happy...). > 3. Have w-b/buildds no longer look at jessie. > 4. Revoke Jessie signing key (no effect for existing installations >as they won't get the revocation anyway). Same as other keys >listed on [2]. > 5. Import to archive.d.o > 6. Remove from security.d.o > > I can do (1), (2), (4) fairly quickly; the buildd team would need to > look at (3). Not sure when (5) and (6) happen, but it's never wrong to > free up some space. > > Will there be an announcement that LTS support has ended? Once jessie is archived it would be fantastic if the workaround for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184 could be re-enabled (as I recall correctly it was reverted due to compat issues with jessie still being around) Cheers, Moritz
Re: unbound not supported
On Tue, Jun 16, 2020 at 07:25:42AM +1000, Brian May wrote: > Holger Levsen writes: > > > for d-s-s in jessie i'm still unsure, which version number to use > > (see https://lists.debian.org/debian-release/2020/06/msg00136.html > > for a summary of the problem). allocating and issuing the DLA will > > be easy once I'm clear about that version number... > > I have wondered if it even makes sense list of supported packages (which > is somewhat dynamic) in a package in the distribution itself The ideal way to handle this is in package meta data, which then allows tools like apt to act on it (e.g. by alerting on installed/incomplete packages). But that needs - a proper spec for the format - support in dak - support in the package tools so the approach of a self-contained tool was the more realistic choice to enable a working solution for the start of squeeze LTS and like all ad hoc solutions it sticks around... > Wouldn't it be better to have, maybe a wiki page somewhere that lists > unsupported packages? Noone will notice, read or care :-) Cheers, Moritz
Re: Refreshing mysql-connector-java
On Tue, Jun 09, 2020 at 12:05:33PM +0200, Sylvain Beucler wrote: > Do you plan to send a DSA? Yeah, should go out tomorrow. Cheers, Moritz
Re: Bug#953950: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie (security) is broken
On Thu, Mar 19, 2020 at 08:29:19PM +0100, Miroslav Skoric wrote: > On 3/19/20 1:01 PM, Simon McVittie wrote: > > > > > If you do not have a specific reason to stay on Debian 8 'jessie', > > also consider upgrading to Debian 9 'stretch', and then from there to > > Debian 10 'buster', which is the current stable release. > > > > Hi, > > One 'specific reason' to stay with an older release is that almost any new > release requires newer hardware (i.e. stops supporting some hardware that > was supported by the older release). Linux upstream is super conservative with dropping support for hardware, can you name a specific driver/component in Linux mainline which suddenly went unsupported as part of a Debian kernel update? Cheers, Moritz
Re: Revert "CVE-2019-15690/libvncserver: reference embedded copies in italc/ssvnc/tightvnc/veyon/vncsnapshot"
[debian-security@ is totally unrelated here, if you want to reach the Security team the correct address is t...@security.debian.org] On Wed, Mar 18, 2020 at 06:14:36PM +0100, Sylvain Beucler wrote: > I excluded 3 out of 8 packages. I only added packages that actually > contain the impacted code (VNC client connection, using original RealVNC > codebase). "Contains the impacted code" is not the relevant criterion here, it's "contains the impacted code and the respective library function can be triggered in a security-relevant scenario/trust boundaries are crossed". Cheers, Moritz
Re: on updating debian-security-support in stable and oldstable (due to DSA-4562-1)
On Thu, Nov 28, 2019 at 12:03:25PM +, Holger Levsen wrote: > - for stretch, I will upload to stretch-security and that's it. Sounds good, I'll take care of releasing that. Cheers, Moritz
Re: clamav triage (updated via -updates)
On Sat, Aug 10, 2019 at 10:03:38AM +0200, Hugo Lefeuvre wrote: > Hi, > > I am taking a look at clamav's zip bomb issue[0] in jessie. This issue is > no-dsa in buster/stretch: "ClamAV is updated via -updates". > > What is this -updates mechanism? I might have missed something, does clamav > have an auto-update mechanism? It's what used to be volatile some years ago. ClamAV is only getting updated via -updates as it can't reasonably be part of a regular stable release; new malware signatures provided via FreshClam sometimes require new engine features so it needs to be kept up with current upstream. It's still present on the install media, but the idea is that by means of -updates it's ensured that always the latest version is present without waiting for the next point release. Cheers, Moritz
Re: Availability of SACKS fix for Linux 4.9.x in Jessie
On Tue, Jun 25, 2019 at 01:33:48PM +0200, Thomas Goirand wrote: > Hi Ben and everyone else, > > Is $subject plan, and what's the ETA? ETA: -7 days: https://lists.debian.org/debian-lts-announce/2019/06/msg00011.html Cheers, Moritz
Re: Jessie update of simplesamlphp?
On Wed, May 29, 2019 at 10:16:56AM +, Mike Gabriel wrote: > HI Thijs, > > On Di 28 Mai 2019 18:17:39 CEST, Thijs Kinkhorst wrote: > > > On Tue, May 28, 2019 16:01, Chris Lamb wrote: > > > Mike Gabriel wrote: > > > > > > > The Debian LTS team would like to fix the security issues which are > > > > currently open in the Jessie version of simplesamlphp: > > > > > > Which CVE is/was this for? I am just looking at: > > > > > > https://security-tracker.debian.org/tracker/source-package/simplesamlphp > > > > > > ... and not seeing anything relevant. Is it still vulnerable? If so, we > > > should remove it from dla-needed.txt, naturally. > > > > As the maintainer I have triaged all open issues and see no reason for > > releasing a jessie update at this point. > > There are some no-dsa issues that should be easy to fix (CVE-2018-7711, > CVE-2016-9955, CVE-2016-9814). > > In the LTS team, we sometimes--when time allows it--work on those, too. From > your message above, I get that you take care of simplesamlphp in jessie > yourself and rather would not want to have us work on the above CVEs, right? If for a given CVE the desired outcome is to not fix oldstable/stable (which is often the right outcome if the risk of regressions and work burdened on the people deploying the updates doesn't outweigh the security fix), then those CVEs should be tagged in the Security Tracker. Cheers, Moritz
Re: Having a test repository for (kernel?) updates
On Mon, Apr 01, 2019 at 09:30:20PM +0200, Bernhard Schmidt wrote: > As long as we have Jessie systems (and also for Stretch once it is in > LTS) we would be willing to run some staging systems and even parts of > the production systems on some sort of -proposed repository. If there > are more users doing that we could catch regressions earlier on. > > I don't exactly know how this could be done technically, There's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817286 which has all the requirements and there's even funding available to get that implemented, but we haven't heard anything back from the person who we were told would implement that. Cheers, Moritz
Re: rssh security update breaks rsync via Synology's "hyper backup"
On Thu, Feb 14, 2019 at 10:08:40AM -0800, Russ Allbery wrote: > Unfortunately, so far as I can tell, --server --daemon is not > even documented in the rsync man page as something you can do (I certainly > didn't know about its existence before this string of CVEs), so it's > pretty hard to figure out what its intended behavior is without doing a > deep dive into source code. The rsync manpage states "The options --server and --sender are used internally by rsync, and should never be typed by a user under normal circumstances.", we should not add additional complexity on top of the existing patches for the use case at hand. Cheers, Moritz
Re: about 500 DLAs missing from the website
On Sun, Feb 03, 2019 at 02:08:06PM +0100, Salvatore Bonaccorso wrote: > IMHO they should not be mixed into the same namespace as the DSAs. > https://www.debian.org/security/ is very specific to the > debian-security-announce list and contains items for e.g. contacting > the Debian security team or referecing the respective FAQ. +1 Cheers, Moritz
Re: tmpreaper jessie update
On Thu, Jan 24, 2019 at 09:16:37AM +0100, Hugo Lefeuvre wrote: > Dear security team, > > I'm currently preparing a jessie security update addressing CVE-2019-3461, > based on 1.6.13+nmu1+deb9u1 (stretch version). > > I see that the diff is quite huge (same code as buster 1.6.14 right?) and > adds a new libmount-dev dependency. I've had a look at the diff, tested it > in jessie and so far I'm fine with that (especially because it was already > uploaded to stretch). The new libmount dependency is necessary for the new check used by the security fix. Most of the additional autoconf noise is related to that new dependency and to the fact that the last upload to unstable before the 1.6.14 one was in 2010. If the debdiff for jessie is identical to the one in stretch (the base versions are identical after all), do a few functionality tests and you should be good. If you strip the autoconf bits, the debdiff is also pretty small. Cheers, Moritz
Re: proposed removal of Enigmail from jessie/LTS
On Tue, Jan 22, 2019 at 02:44:50PM -0500, Antoine Beaupré wrote: > > I'm not sure we should remove *both* enigmail and thunderbird from > jessie. I understand there are problems with the a.m.o version, but then [..] > Right now I'm leaning towards completely dropping support from Enigmail > in jessie, since the changes required are too far ranging to be > comfortable. +1, there's certainly enough uses cases where Thunderbird is used without PGP. Cheers, Moritz
Re: [SECURITY] [DSA 4371-1] apt security update
On Tue, Jan 22, 2019 at 01:44:12PM +, Ben Hutchings wrote: > On Tue, 2019-01-22 at 13:17 +0100, Yves-Alexis Perez wrote: > > - > > Debian Security Advisory DSA-4371-1 secur...@debian.org > > https://www.debian.org/security/Yves-Alexis Perez > > January 22, 2019 https://www.debian.org/security/faq > > - > > > > Package: apt > > CVE ID : CVE-2019-3462 > > > > Max Justicz discovered a vulnerability in APT, the high level package > > manager. > > The code handling HTTP redirects in the HTTP transport method doesn't > > properly > > sanitize fields transmitted over the wire. This vulnerability could be used > > by > > an attacker located as a man-in-the-middle between APT and a mirror to > > inject > > malicous content in the HTTP connection. This content could then be > > recognized > > as a valid package by APT and used later for code execution with root > > privileges on the target machine. > [...] > > This presumably needs to be fixed for jessie LTS as well, and I see > Chris Lamb has claimed it. Julian has already uploaded a fixed package, this only needs the DLA mail at this point. Cheers, Moritz
Re: policykit-1 CVE-2018-19788 in jessie
On Thu, Dec 20, 2018 at 03:11:49PM +0530, Abhijith PA wrote: > Hi Santiago, > > On Thursday 20 December 2018 01:00 AM, Santiago Ruano Rincón wrote: > > Dear Maintainers, > > > > (It seems my first attempt to send this mail failed. Sorry if you > > received it twice) > > > > As opposed to stretch, I have been unable to reproduce CVE-2018-19788 in > > jessie. i.e. systemctl correctly doesn't allow me to stop services, and > > pkexec blocks me from executing applications that need privileges. > > I couldn't reproduce in my jessie machine either. > > > Do you think is it safe to consider jessie as not-affected? Or is it > > still worth to apply the patch? > > I think its okay to mark as not-affected. Don't mark issues as not-affected just because some specific reproducer doesn't trigger. This should only be done if source code analysis has shown it to be not affected. Cheers, MOritz
Don't use temporary identifiers from the Security Tracker in advisories
Wrt https://lists.debian.org/debian-lts-announce/2018/12/msg0.html The internal IDs from the tracker _not_ meant for external publication, this will only lead to stupid chain reactions where external parties pick them up and then they perpetuate. Either simply write "no CVE allocated" or rather do the right thing and request an ID via https://cveform.mitre.org Cheers, Moritz
Re: Xen 4.4 updates vs. Xen Stretch backport
On Wed, Nov 28, 2018 at 12:59:11PM +0100, Peter Dreuw wrote: > Hi out there, > Another option would be backporting the Xen > 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10 (and following) package from > Stretch to Jessie. What would be the point? If you migrate to a complete new Xen release, then you can just as well migrate to stretch (which will also have proven, compatible matching versions of libvirt/Linux/qemu/ etc. If some of the Spectre mitigations can't be backported, make a detailed writeup of what people are missing in 4.4 and let them handle it based on that data (update to stretch or stick with 4.4/jessie); there's still plenty of legitimate use cases which can be run in a secure manner with 4.4 (internal VMs with trusted users etc). Cheers, Moritz
Re: the way to enigmail: gnupg 2.1 backport considerations
On Mon, Nov 19, 2018 at 03:43:59PM -0500, Antoine Beaupré wrote: > and I haven't > heard any negative (or positive) feedback on the build, so I'm going > under the assertion that it doesn't cause too much trouble. Realistically that means that noone tested them. Cheers, Moritz
Re: Removing no-dsa entries when releasing a DLA
On Thu, Nov 08, 2018 at 10:05:39AM +0100, Raphael Hertzog wrote: > On Tue, 06 Nov 2018, Moritz Muehlenhoff wrote: > > On Tue, Nov 06, 2018 at 08:16:21PM +0100, Markus Koschany wrote: > > > Am 06.11.18 um 20:09 schrieb Moritz Muehlenhoff: > > > > Hi, > > > > if you fix any issues which were formerly tagged in a DLA, > > > > make sure > > > > to remove the no-dsa in CVE/list as well, e.g. in the DLA-1568-1 for > > > > curl. > > > > > > I was about to do that, as usual, but when someone else does it four > > > minutes after I requested a DLA number and I still work on the commit, > > > then there is not really anything what can be done about it. I suggest > > > being a bit more patient in such cases. > > > > Your's is just an arbitrary example, there's plenty of other cases where > > that > > did not happen at all until Salvatore cleaned it up. > > Why is that even needed? Otherwise they're still listed as no-dsa in the tracker. > Can't we improve the security tracker to ignore > those no-dsa tag when the CVE has been fixed? Or have some script to > remove them automatically? You could add code to bin/gen-D?A to strip existing no-dsa tags for CVE ID passed to the script. Until that exists, make sure to strip this manually. Cheers, Moritz
Re: libdatetime-timezone-perl
On Wed, Nov 07, 2018 at 04:59:05PM +1100, Brian May wrote: > I see libdatetime-timezone-perl is in dla-needed.txt, but I can't see > *any* security vulnerabilies in > https://security-tracker.debian.org/tracker/source-package/libdatetime-timezone-perl There's no security issue in libdatetime-timezone-perl, but it embeds a copy of tzdata and gets updated similar to the SUA updates for stable. Cheers, Moritz
Re: Removing no-dsa entries when releasing a DLA
On Tue, Nov 06, 2018 at 08:16:21PM +0100, Markus Koschany wrote: > Am 06.11.18 um 20:09 schrieb Moritz Muehlenhoff: > > Hi, > > if you fix any issues which were formerly tagged in a DLA, make > > sure > > to remove the no-dsa in CVE/list as well, e.g. in the DLA-1568-1 for curl. > > I was about to do that, as usual, but when someone else does it four > minutes after I requested a DLA number and I still work on the commit, > then there is not really anything what can be done about it. I suggest > being a bit more patient in such cases. Your's is just an arbitrary example, there's plenty of other cases where that did not happen at all until Salvatore cleaned it up. Cheers, Moritz
Removing no-dsa entries when releasing a DLA
Hi, if you fix any issues which were formerly tagged in a DLA, make sure to remove the no-dsa in CVE/list as well, e.g. in the DLA-1568-1 for curl. Cheers, Moritz
Re: Wheezy update of spamassassin?
On Sun, Oct 28, 2018 at 10:19:34PM -0700, Noah Meyerhans wrote: > On Mon, Oct 22, 2018 at 11:23:50AM -0400, Antoine Beaupré wrote: > > Ping! Any update here? Do you want us to help with the jessie or stretch > > update? > > I'll be posting a message about the stretch update to debian-release > shortly. If you want to work on further backporting its update to > jessie, that is fine with me. The packaging changes for stretch are at > https://salsa.debian.org/debian/spamassassin/tree/3.4.2-stretch Make sure to only release anything after stretch 9.6 has been released, though. Otherwise having a higher version in oldstable will cause update problems to stretch. Cheers, Moritz
Re: Disabling ghostscript handled formats in imagemagick and graphicsmagick
On Mon, Oct 22, 2018 at 01:23:21PM +0200, Markus Koschany wrote: > Hi, > > Several security vulnerabilities were discovered in Ghostscript in > recent weeks. Although all known issues were fixed, there is still a > chance that there are more of them, yet undiscovered. The security > researcher who found those issues recommends to disable Ghostscript > handled formats by default in Imagemagick. [1] I think this should be > extended to Graphicsmagick too. > > Thorsten, you are currently working on Imagemagick. Could you apply this > patch [2] from Ubuntu to our package as well? Better wait until that change has been made in unstable first: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907336 Cheers, Moritz
Re: Jessie update of libssh?
On Wed, Oct 17, 2018 at 03:57:50AM +0100, Ben Hutchings wrote: > On Wed, 2018-10-17 at 03:18 +0100, Ben Hutchings wrote: > > I've pushed backported fixes to a jessie-security branch at < > > https://salsa.debian.org/debian/libssh>; and uploaded packages to < > > https://people.debian.org/~benh/packages/jessie-security/>;. > > > > The fixes come from the upstream web site, but their version left the > > test suite broken. I got the test suite to build and pass, but I don't > > have a great deal of confidence in it. So I would appreciate any > > suggestions for how to test that the library still works for real > > applications. (Or, if you prefer, you could test and upload > > yourselves.) > > I also pushed a stretch-security branch with fixes taken from the > upstream v0-7 branch. Again, the test suite passes but I didn't know > how to test with real applications. I do *not* intend to upload to > stretch-security, but can do if you are short of time. JFTR, Salvatore has already uploaded a stretch build to security-master. Cheers, Moritz
Re: Apache2 CVE-2016-4975
On Thu, Aug 16, 2018 at 05:12:11PM +1000, Brian May wrote: > Note: This is only being sent to debian-LTS. > > > I am currently investigating CVE-2016-4975 for Apache2. The issue is > > already two years old but was only made public yesterday. [1] I skimmed > > through old commit messages but I could not isolate the fixing commit. > > However I found this changelog entry [2] from December 13th, 2016 and > > you are listed as one of the upstream committers who apparently fixed > > this vulnerability. > > Does this warrant an entry in dla-needed.txt? I don't think so, I suggest to tag it and bundle it up the next time there's a DLA for Apache. > I also wonder why it takes almost 2 years for a security vulnerability > to become public... They had a crazy backlog :-) See https://twitter.com/iamamoose/status/1029360920970125312 Cheers, Moritz
Re: Checking for regressions after the release of a DLA
On Wed, Aug 08, 2018 at 04:26:04PM +0100, Chris Lamb wrote: > Dear Moritz, > > > > I have prepared a regression update of my package slurm-llnl in jessie, > > > because of: > > > > To everyone working on LTS, there's also a process gap here; anyone who > > releases a DLA should keep an eye on the BTS for about a week > > after the release of a DLA to check for eventual regressions. We're doing > > the same for DSAs. > > Do you have any systematic process (or even tooling) for this out of > interest? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878088 will help to redirect some reports our way, but in the end there's 100% reliable method to detect regression reports, so the process is more or less to look at all the reports filed after the date of the release of the security update. Cheers, Moritz
Checking for regressions after the release of a DLA
On Wed, Aug 08, 2018 at 11:14:52AM +0200, Gennaro Oliva wrote: > Hi, > I have prepared a regression update of my package slurm-llnl in jessie, > because of: To everyone working on LTS, there's also a process gap here; anyone who releases a DLA should keep an eye on the BTS for about a week after the release of a DLA to check for eventual regressions. We're doing the same for DSAs. So if you have a best practices doc for people working on or joining the Freexian pool, please add this. This has been filed in the BTS for nine days, it should be not on the maintainer of the package to kick start a regression update. Cheers, Moritz
Re: jetty CVE triage: jetty8 ignored?
B0;115;0cOn Thu, Jul 05, 2018 at 05:24:22PM +0200, Ola Lundqvist wrote: > Hi Sebastian > > With this reasoning we cannot assume that a later release include fixes for > earlier releases for any package. Jetty seems to be actively and sanely > maintained so I think the risk you point out is very low. > But you are right, this could be the case for a badly maintained package. It's all open source, I suggest you simply look at the packages instead of making assumptions. Cheers, Moritz
Re: Dealing with renamed source packages during CVE triaging
On Fri, Jun 15, 2018 at 04:34:14PM +1000, Brian May wrote: > Moritz Muehlenhoff writes: > > > On Wed, Jun 13, 2018 at 05:19:40PM +1000, Brian May wrote: > >> "as I said in the mailing list discussion, I don't like the usage of the > >> undetermined tag... we use it to hide stuff we can't investigate under > >> the carpet, I would much prefer that we put it as directly > >> when it's the case, or otherwise." > > > > Of course, those can be resolved; it just needs someone to do the analysis > > work. > > Switching to some other tags (and incorrect ones!) doesn't change anything. > > Seems like this a mute point anyway, as from the comments you left in > the pull request, you don't like this approach of automatically adding > entries in data/CVE/list. Fair enough. > > So we could write a script, lets say: > bin/list-potential-packages-affected-by-code-copies You're mixing two things; my comment above refers to , those are one-off investigations and don't need any particular tooling. > That generates a report of all packages that we need to check. I assume > we would need some way of marking packages that we have checked and > found to be not affected, so we can get a list of packages that need > immediate attention and don't repeatedly check the same package multiple > times. How should we do this? Maybe another file in the security tracker > repository? Maybe start with the script initially and see whether it's useful as an approach in general. State tracking can be discussed/added later. Lots of the false positives will result from crappy/outdated entries in embedded-code-copies, so fixing those up will drastically reduce false positives. Cheers, Moritz
Re: Dealing with renamed source packages during CVE triaging
On Fri, Jun 15, 2018 at 05:21:55PM +1000, Brian May wrote: > Brian May writes: > > > So we could write a script, lets say: > > bin/list-potential-packages-affected-by-code-copies > > In investigating the possibility of this, I noticed the scripts in > lib/python/sectracker use legacy python coding standards. > > I have updated these files on my local box to work with Python 3, but > refraining from pushing for now, because of the possibilty I might break > something important. When the Debian Security Tracker was created, Python 3 didn't even exist yet :-) Feel free to make a pull request, I don't think we have a specific dependency on Python 2 modules anywhere. But it might take a bit to get reviewed/deployed as it's not a high priority issue. Cheers, Moritz
Re: Dealing with renamed source packages during CVE triaging
On Wed, Jun 13, 2018 at 05:19:40PM +1000, Brian May wrote: > "as I said in the mailing list discussion, I don't like the usage of the > undetermined tag... we use it to hide stuff we can't investigate under > the carpet, I would much prefer that we put it as directly > when it's the case, or otherwise." Of course, those can be resolved; it just needs someone to do the analysis work. Switching to some other tags (and incorrect ones!) doesn't change anything. Cheers, Moritz
Re: Dealing with renamed source packages during CVE triaging
On Tue, Jun 12, 2018 at 05:40:34PM +1000, Brian May wrote: > 1. Tagging with / instead of . Nothing of those can automated. The basic point of is that we lack data to make a proper assessment. The correct way to handle these is to triage https://security-tracker.debian.org/tracker/status/undetermined by contacting e.g. upstream developers or the reporters of the vulnerability and then amend CVE/list with the necessary information, i.e. either converting them to if it has been confirmed to be an issue or to . > 3. Resolve general issue regarding CVE/list, and if it should be split up. That has been proposed and nacked several times before. There's simply no practical reason for it. It would add multiple complications (starting with the MITRE sync, syncing with external parties, changes to the tracker) for no measurable gain. Quite the contrary; it's extremely useful to have 20 years of vulnerability data easily available in a single emacs buffer. Cheers, Moritz
Re: jessie update for mercurial
On Thu, Jun 07, 2018 at 08:08:06AM -0400, Antoine Beaupré wrote: > On 2018-06-07 04:45:06, Chris Lamb wrote: > > Hi Antoine, > > > >> A peculiar thing with the patchset is that it adds the --debug flag to > >> the test suite: I don't know why, but it's the only way to make it pass > >> the (new) test-http-permissions.t tests. Otherwise it just hangs there > >> forever. > > > > Personally, it would make me very very hesitant to propose a patch > > (yet alone release it via security update) when I had not discovered > > the reason for this. > > > > Bear in mind that the cause may not be in the testsuite and could be > > in the actual run-time code itself — ie. the improved testsuite is > > simply exposing it, just as it should. > > The problem is the testsuite is forward-ported from wheezy, which itself > is backported from i don't remember where. Never do that! If the fix e.g. requires changes in jessie which were stripped from the wheezy backport as the affected code isn't present there, you end up with an incomplete security update. Any backport always needs to be done invidually per release from the upstream patch. Cheers, Moritz
Re: Draft for EOL announcement
On Fri, May 25, 2018 at 10:16:43PM +0200, Markus Koschany wrote: > Hi all, > > It is true that https://deb.freexian.com/extended-lts is not available > yet but I assumed this will change on May 31. If not I can also delete > the sentence about ELTS for now and add "More information will follow > soon" or something like that. Added Raphael to CC. Hopefully he can > clarify the situation. It's not appropriate anyway for an official Debian announcement. LTS itself is already a grayish area, but advertising a service which solely prepares package updates on paid basis seems not ok with DMUP. If the service is limited to Freexian subscribers, you can send a newsletter to them? Cheers, Moritz
Re: Draft for EOL announcement
On Tue, May 22, 2018 at 11:56:00AM +0200, Markus Koschany wrote: > Hi all, > > we are approaching the end of Wheezy LTS on May 31. As usual we intend > to communicate the end and start of a new LTS cycle on various channels. > I have created the following draft which I intend to submit to the > Publicity team. Any improvement suggestions are welcome. Why the publicity team? These announcements can go to lts-announce, the same way EOL announcements for regular releases are going to debian-security-announce only. After all anyone using LTS will already have to be on lts-announce to receive notifications. Cheers, Moritz
Re: CVE triage in the tracker
Hugo Lefeuvre wrote: I added a few more ming CVEs earlier the day, BTW. > > > Second question: Even if Ming isn't present in unstable, the tracker > > > still mentions (unstable) - (unfixed) in the second table. IMO this > > > row makes no sense, is it a bug ? > > > > Then you can put: > > > > - ming > > It's already the case. That's why I asked. ;) The "(unstable) - (unfixed)" for removed packages is actually a glitch in the tracker. Patches welcome :-) Cheers, Moritz
Re: finding packages after no-dsa
On Thu, Apr 12, 2018 at 03:44:36PM +0200, Ola Lundqvist wrote: > I do not think we really have the possibility to postpone issues in LTS, > right? Why would you not?
Re: Better communication about spectre/meltdown
On Sun, Apr 01, 2018 at 07:48:55AM -0400, Roberto C. Sánchez wrote: > Additionally, when I checked the PTS for information on the recent jessie > upload it > was a binary upload built for amd64. Source uploads to the security archive are only possible from stretch onwards. Cheers, Moritz
Re: Better communication about spectre/meltdown
On Thu, Feb 15, 2018 at 12:33:12PM +0100, Raphael Hertzog wrote: > On IRC I learned that Moritz Muehlenhoff (jmm) started the work of > bakcporting retpoline to gcc-4.9 for jessie. We need to do the same > for gcc-4.6 (and maybe gcc-4.7) in wheezy. gcc-4.6 is used for the > kernel build so that's the important target really. Or rather introduce gcc-4.9 as a new source package to wheezy LTS which can then be used for the kernel build (once 3.2.x has retpoline backported). For the architectures supported in LTS the compiler difference between 4.6 and 4.9 should not matter. Cheers, Moritz
Re: Suitability of additional non-security fix for clamav?
On Sat, Jan 27, 2018 at 05:34:00PM -0500, Roberto C. Sánchez wrote: > I am in the process of preparing an update for clamav. > > I am curious as to what others might think of including an additional > fix that is not technically security-related. It fixes a rather serious > bug that causes clamd to crash if a bad virus definition file is > published. The inclusion of the additional patch in the next wheezy > update was recommended by a clamav maintainer (Scott Kitterman). > > https://bugs.debian.org/824196 > https://anonscm.debian.org/cgit/pkg-clamav/clamav.git/commit/?id=d7ea9385baefece1a1c2ff29c3c57853fa8011cb > > Unless there are objections, I plan to include the patch as just a few > days ago there was a bad virus definition file published that caused > clamav crashes for many users. In jessie/stretch clamav is updated via -updates precisely for the reason that ClamAV needs regular non-security changes to remain usable. So LTS should definitely be kept updated with the same standards. Cheers, Moritz
Re: Wheezy update of icedove?
On Fri, Oct 20, 2017 at 01:06:09PM +0200, Guido Günther wrote: > Thanks. Looks good here on Wheezy. Any idea when the versions for Jessie > and Stretch will be done? Wheezy was a straight rebuild of your work so > Jessie and Stretch should be the same. I'd like to avoid having a newer > version in Wheezy for too long. Since there's not even a MFSA for > Thunderbird yet I assume there are no really critical issues. There is https://www.mozilla.org/en-US/security/advisories/mfsa2017-23/ But I fail to see how CVE-2017-7793 can be critical for Thunderbird. Cheers, Moritz
for LTS
Hi, when we're marking issues as for the suites supported by the security team and if that issue is also marked in wheezy (or whatever is LTS at the time), ok to also mark the LTS suite as or do you want to do deal with that by yourself? Specific example of such a change: r56270 Cheers, Moritz
Re: update of debian-security-support [was Re: Marking autotrace as unsuppported ?]
On Fri, Jun 02, 2017 at 12:53:58PM +0200, Guido Günther wrote: > On Fri, Jun 02, 2017 at 12:27:47PM +0200, Moritz Muehlenhoff wrote: > > On Fri, Jun 02, 2017 at 12:21:01PM +0200, Guido Günther wrote: > > > Hi, > > > On Fri, Jun 02, 2017 at 11:32:07AM +0200, Raphael Hertzog wrote: > > > > Hi, > > > > > > > > On Fri, 02 Jun 2017, Guido Günther wrote: > > > > > > I updated the git repository of debian-security-support. Shall we > > > > > > release > > > > > > an update of that package? > > > > > > > > > > We did not do so for the last updates so that would be good. Will you > > > > > handle this? > > > > > > > > Feel free to do it. I'm going away for 3 days in a few minutes. > > > > > > > > > We would need to send out a DLA for the new debian-security-support > > > > > package. Wouldn't that be enough? > > > > > > > > Right. Yes, that would be enough. > > > > > > Can do. > > > > > > Dear security team: o.k. to with the attached diff to unstable or would > > > this conflict with your preparations for stretch? I can handle the > > > upload to jessie-p-u as well. > > > > That would be great. Could you also push a change to the jessie file to > > mark cgiemail, owncloud and owncloud-apps as unsupported (with > > a link to https://lists.debian.org/debian-announce/2017/msg2.html)? > > Sure. New debdiff attached. Thanks, please upload Cheers, Moritz
Re: update of debian-security-support [was Re: Marking autotrace as unsuppported ?]
On Fri, Jun 02, 2017 at 12:21:01PM +0200, Guido Günther wrote: > Hi, > On Fri, Jun 02, 2017 at 11:32:07AM +0200, Raphael Hertzog wrote: > > Hi, > > > > On Fri, 02 Jun 2017, Guido Günther wrote: > > > > I updated the git repository of debian-security-support. Shall we > > > > release > > > > an update of that package? > > > > > > We did not do so for the last updates so that would be good. Will you > > > handle this? > > > > Feel free to do it. I'm going away for 3 days in a few minutes. > > > > > We would need to send out a DLA for the new debian-security-support > > > package. Wouldn't that be enough? > > > > Right. Yes, that would be enough. > > Can do. > > Dear security team: o.k. to with the attached diff to unstable or would > this conflict with your preparations for stretch? I can handle the > upload to jessie-p-u as well. That would be great. Could you also push a change to the jessie file to mark cgiemail, owncloud and owncloud-apps as unsupported (with a link to https://lists.debian.org/debian-announce/2017/msg2.html)? Cheers, Moritz
Re: tiff and CVE-2016-10095
On Fri, Jun 02, 2017 at 10:25:29AM +0200, Guido Günther wrote: > Hi Moritz, > I'm trying to figure out the reasoning for @51764. This marks tiff as > affected by CVE-2016-10095. However from the upstream bug and the > changes we made in wheezy it looks like the changes we made already are > sufficient to fix the issue. Do you have a hint why you think this is > not the case? CVE-2016-10095 is the generic fix for the API. I'm not sure why that received a CVE ID, since it's not a vulnerability per se (which are in the call sites), but it's not worth arguing and providing that in jessie might be useful for building building custom tools still. Cheers, Moritz
Re: [Secure-testing-commits] r51756 - data/CVE
On Fri, May 19, 2017 at 06:34:10PM +0200, Hugo Lefeuvre wrote: > Hi Moritz, > > On Fri, May 19, 2017 at 06:25:43PM +0200, Moritz Muehlenhoff wrote: > > On Fri, May 19, 2017 at 04:23:25PM +, Hugo Lefeuvre wrote: > > > Author: hle > > > Date: 2017-05-19 16:23:25 + (Fri, 19 May 2017) > > > New Revision: 51756 > > > > > > Modified: > > >data/CVE/list > > > Log: > > > CVE triage for libav in wheezy by Diego Biurrun > > > > That's no okay. Why do you remove several entries? > > Because the CVE doesn't affect libav at all. > > Should I let the libav entry in this case ? You should re-read the security tracker docs. This obviously needs to be marked as with an explation why it's not an issue for libav. Cheers, Moritz
Re: [Secure-testing-commits] r51756 - data/CVE
On Fri, May 19, 2017 at 04:23:25PM +, Hugo Lefeuvre wrote: > Author: hle > Date: 2017-05-19 16:23:25 + (Fri, 19 May 2017) > New Revision: 51756 > > Modified: >data/CVE/list > Log: > CVE triage for libav in wheezy by Diego Biurrun That's no okay. Why do you remove several entries? Cheers, Moritz
Re: [SECURITY] [DLA 918-1] freetype security update
On Thu, Apr 27, 2017 at 01:04:54PM +0200, Bolesław Tokarski wrote: > Hi, > > > See https://security-tracker.debian.org/tracker/CVE-2016-10328 > > Nice, I see it's in 'fixed' state in 2.5.2-3+deb8u1 already. I guess it was > not > clear that this does not affect that version last time I checked - I remember > it was 'vulnerable' back then (April 21st). "fixed" in that page applies to both "patched" and "not affected to begin with", so it was only tagged as "fixed" after I had investigated CVE-2016-10328 to be a non-issue for stable and commited that to the security tracker DB. > > CVE-2016-10244 was only scheduled for the next point release due to low > > impact, but in the light of the new CVE-2017-8105, it'll be fixed in a DSA > > as well. > > I see a previous CVE fixed in Debian-LTS still lights up in jessie: > https://security-tracker.debian.org/tracker/CVE-2016-10244 > > Do you happen to know if that one's coming out in a DSA? Yes, that will be included in the next DSA. Cheers, Moritz
Re: [SECURITY] [DLA 918-1] freetype security update
On Thu, Apr 27, 2017 at 10:55:51AM +0200, Bolesław Tokarski wrote: > I'm curious to see the version scope/some proof of a particular version not > being affected by CVE-2016-10328. See https://security-tracker.debian.org/tracker/CVE-2016-10328 > The reason I'm asking is because I'm maintaining a backport of the jessie > 2.5.2-3 to wheezy and it seems that jessie one did not receive any of the > mentioned CVE fixes despite the debian-lts team prepared another patch for > 2.4.9 already. CVE-2016-10244 was only scheduled for the next point release due to low impact, but in the light of the new CVE-2017-8105, it'll be fixed in a DSA as well. Cheers, Moritz
Re: fixing links for DLAs in the security tracker
On Tue, Mar 28, 2017 at 04:08:19PM -0400, Antoine Beaupré wrote: > I constantly find myself struggling to find the actual DLA announcements > when I browse the security tracker. Take for example: > > https://security-tracker.debian.org/tracker/CVE-2016-8743 > > If you click on the DSA there: > > https://security-tracker.debian.org/tracker/DSA-3796-1 > > You have a nice "Source" link that brings you to: > > https://www.debian.org/security/2017/dsa-3796 > > Yet the DLA page doesn't have that feature: > > https://security-tracker.debian.org/tracker/DLA-841-1 Well, you don't have a web site comparable to https://www.debian.org/security/2017/dsa-3796, so where should it possibly link to? Cheers, Moritz
Re: Dealing with renamed source packages during CVE triaging
On Tue, Mar 28, 2017 at 03:55:12PM +0200, Raphael Hertzog wrote: > On Tue, 28 Mar 2017, Moritz Muehlenhoff wrote: > > I'd suggest a cron job running once or twice per day, which keeps > > a table of (current source package name / old source package name(s)) > > and adds SOURCEPACKAGE for the older source package. > > These can then be set to or after manual > > triage. > > Why this and not the usual "SOURCEPACKAGE " tag followed by > a codename-specific tag added after triaging: "[wheezy] SOURCEPACKAGE > " if needed? That's also fine, since usually the older versions happens to be affected in most cases. Cheers, Moritz
Re: [Announce] Samba 4.6.1, 4.5.7 and 4.4.12 Security Releases Available for Download
On Fri, Mar 24, 2017 at 03:55:23PM +0100, Guido Günther wrote: > Hi Roberto, > On Fri, Mar 24, 2017 at 10:45:44AM -0400, Roberto C. Sánchez wrote: > > On Fri, Mar 24, 2017 at 03:16:28PM +0100, Mathieu Parent wrote: > > > Please wait a bit before uploading. > > > > > > There is a regression in jessie when "follow symlinks = no" #858564, > > > and a segfault with vfs_shadow2 (#858590). > > > > > > > > I am working on the wheezy LTS update for samba now. > > > > There are 37 individual patches in jessie's CVE-2017-2619.patch, and not > > all apply cleanly to 3.6.6 in wheezy. That said, I will wait on > > uploading until those bugs are resolved and I have incorportated their > > fixes. > > Note that Jessie has samba4 while wheezy has samba3 (samba package) and > samba4 (samba4 package). samba4 in wheezy doesn't provide the Samba daemons, so is irrelevant here: https://packages.qa.debian.org/s/samba4/news/20140416T220212Z.html Cheers, Moritz
Re: Print undetermined issues in lts-cve-triage
On Fri, Feb 03, 2017 at 10:58:35AM +0100, Guido Günther wrote: > Hi, > while looking at the recent changes in data/CVE/list I noticed a bunch > of gstreamer issues being added but not showing up in the output > produced by lts-cve-triage. Reason was that they're marked as > undetermined. The attached patch adds undetermined issues to the output > by default. O.k. to apply? That makes sense, issues need triage like other vulnerabilities, they're just a little more vague (e.g. it's added for libav when a ffmpeg vulnarability has been found, since those two have diverged quite a bit). Cheers, Moritz
Re: nss 3.26.2 in jessie?
On Wed, Dec 21, 2016 at 05:27:30PM -0500, Antoine Beaupré wrote: > Hi, > > We (the LTS team, but mainly me and buxy) are working on an update to > the NSS package for wheezy, and we just packaged the upstream 3.26.2 > release since it was a minimal diff that was easy to review. > > We can't really update with a 3.26.2 version without making sure jessie > follows suite as well. > > Can I upload that package to 3.26.2? For now it looks like this: The only issue open in jessie is CVE-2016-9074, which doesn't really warrant a DSA on it's own. We can reconsider a DSA if further nss vulnerabilities appear. For LTS you could simply base on 2:3.26-1+debu8u1 and cherrypick the patch for CVE-2016-9074 on top. Cheers, Moritz
Re: Bug#840691: ghostscript and evince/libspectre problem
On Thu, Oct 27, 2016 at 06:31:43AM -0400, Roberto C. Sánchez wrote: > On Thu, Oct 27, 2016 at 08:54:39AM +0200, Moritz Muehlenhoff wrote: > > > > Salvatore mentioned that the same bug occurs when unstable has the security > > patches merged (which hasn't happened so far :-/), so this needs to be > > reported > > upstream. > > > Would that be to ghostscript upstream? I guess that with seeing the > evince problem in Jessie with both ghostscript 9.06~dfsg-2+deb8u2 and > 9.06~dfsg-2+deb8u3 I wasn't certain that the fault is completely with > ghostscript. I haven't debugged this myself, but my guess is that libspectre relies/relied on the insecure ghostscript behaviour which got patches with the security fixes... Cheers, Moritz
Re: ghostscript and evince/libspectre problem
On Wed, Oct 26, 2016 at 11:09:54PM -0400, Roberto C. Sánchez wrote: > On Tue, Oct 25, 2016 at 09:54:01PM +0200, Salvatore Bonaccorso wrote: > > Hi Roberto > > > > Could you double-check/confirm if you see the same > > https://bugs.debian.org/840691 in wheezy? Note although the bug is > > still assigned to ghostscript I think the problem uncovered is > > actually in libspectre as noted in the bug log. But I wonder if you > > see the same issues in wheezy now that ghostscript is updated there. > > > Salvatore, > > Here is what I found: > > - On Jessie, evince segfaults on AIM-864.ps with both ghostscript >packages at versions 9.06~dfsg-2+deb8u2 and 9.06~dfsg-2+deb8u3 >(this is clearly different for me than what is in the bug reports) > - On Wheezy, evince renders AIM-864.ps with ghostscript packages at >version 9.06~dfsg-2+deb8u2, but segfaults with ghostscript packages >at version 9.06~dfsg-2+deb8u3 > - In all cases, gv renders the document correctly > > I believe that the short answer to your question is, "yes the same issue > occurs in wheezy." > > Do you plan to address this issue, or is there something that I can to > do help speed the process along? Salvatore mentioned that the same bug occurs when unstable has the security patches merged (which hasn't happened so far :-/), so this needs to be reported upstream. Cheers, Moritz
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On Thu, Oct 20, 2016 at 05:00:36PM +0200, Guido Günther wrote: > Please file these bugs! The security team has asked for help on this > task on several occasions. It's on the LTS TODO list since the BoF at > Debconf16: > > > https://wiki.debian.org/LTS/TODO#Update_documentation_on_frontdesk_work:_filling_bug_reports_when_triaging_CVEs > > and I've added it to the housekeeping tasks recently as well: > > https://wiki.debian.org/LTS/Development#Housekeeping_Tasks Agreed. And on the topic of severity; if you've triaged a vulnerability and feel it's severe enough to warrant a DLA, feel free to mark them as RC. Severities are easy to adapt after all. Cheers, Moritz
Re: wheezy update for libav
Markus Koschany wrote: > Just to be clear a new upstream libav doesn't need to coincide with a > Debian security update. It wouldn't do any harm though. Important is > that we only fix security related issues and leave possible features out > that are not strictly needed to fix the CVEs. This is not how libav security updates are handled in Debian; we've always shipped the 0.8.x and 11.x bugfix releases in -security. Cheers, Moritz
Re: wheezy update for libav
On Mon, Sep 12, 2016 at 12:52:32PM +0200, Hugo Lefeuvre wrote: > Hi, > > > I'm counting 22 open CVEs for libav at the moment. Which of them do you > > intend to address with your fixes? Do you mind working together with > > Hugo Lefeuvre on some issues? I could imagine you both could pool your > > resources together. > > (24 if we count the two issues marked no-dsa by the security team) > > Some CVE triage: > > Upstream patch applies directly, or almost: All of the issues marked don't have upstream fixes in the sense that libav fixed them, only fixes in ffmpeg git. If you want to address them in oldstable/stable, you should get the libav developers to merge them first. Cheers, Moritz
