Bug#1053004: CVE-2019-10784 and CVE-2023-40619
On Wed, May 22, 2024 at 02:42:58PM -0300, Leandro Cunha wrote: > Hi everyone, > > On Wed, May 22, 2024 at 12:39 PM Moritz Mühlenhoff wrote: > > > > Am Wed, Mar 06, 2024 at 06:39:01AM -0300 schrieb Leandro Cunha: > > > Hi Christoph Berg, > > > > > > On Wed, Mar 6, 2024 at 5:42 AM Christoph Berg wrote: > > > > > > > > Re: Leandro Cunha > > > > > The > > > > > next job would be to make it available through backports and I would > > > > > choose to remove this package from stable. But I would only leave > > > > > bookworm backports due to other bugs found (this CVEs too) and fixed > > > > > in 7.14.7. > > > > > I have to search about the status of backports to oldstable. But I'm > > > > > also studying the possibility of working with patches for these two > > > > > versions. > > > > > > > > Why would you want to remove it from stable? In closed environments, > > > > CVEs are often not a problem. > > > > > > > > Christoph > > > > > > In addition to the CVEs, phppgadmin which is present in stable does > > > not connect to PostgreSQL 15 and 16 without a patch I inserted in > > > 7.13.0+dfsg-3, but I can add the same patch by reopening bug #1029516 > > > or opening another important bug (I am aware that the bug must have a > > > severity greater than important)[3] for the stable and submission of > > > new bug to the release team for approval. That way it would be > > > released in a future release a version with this issue fixed (if > > > approved). But CVE-2023-40619 is treated with critical severity and > > > CVE-2019-10784 is also critical according to the NVD[1][2]. The Debian > > > LTS team handled this with DLA-3644-1 (CVE-2023-40619)[4] in buster > > > (oldoldstable) and of OpenSUSE team also handled both CVEs in > > > Leap[5][6]. > > > Removing this package in stable will not leave users without them and > > > we can release it in backports. > > > I can treat this as a job of ensuring the quality of what is > > > distributed by Debian. > > > > Agreed, if the package is actually broken with the version of PostgreSQL > > in stable and if there's no sensible backport for the open security issues, > > then let's rather remove it by the next point release. > > > > Cheers, > > Moritz > > It's the best thing to do, the package with the necessary corrections > is already present in bookworm-backports and the user just needs to > run apt install -t bookworm-backports phppgadmin[1][2][3] with > sponsorship of Christoph Berg (thank you for that) and thanks also to > the Debian Security Team. Ack, will you do the removal request? You can do that with "reportbug release.debian.org" and then selecting the "rm stable/testing removal requests" option. Cheers, Moritz
Bug#1069762: pdns-recursor: CVE-2024-25583 - 4.8.8 for stable
On Thu, Apr 25, 2024 at 08:37:14AM +0200, Chris Hofstaedtler wrote: > Hi Moritz, > > could we once again use the upstream release for stable? > debdiff 4.8.7-1 -> 4.8.8-1 is attached. Ack. Following the 4.8 releases has served us well. debdiff looks fine, please build with -sa and upload to security-master. Cheers, Moritz
Bug#1068818: sngrep: CVE-2024-3119 CVE-2024-3120
On Sun, Apr 21, 2024 at 07:35:43PM +, Victor Seva wrote: > Hi, > > > I've just uploaded sngrep 1.8.1-1 to sid and prepared 1.6.0-1+deb12u1 for > bookworms-security [0]. > > Attached debdiff file. > > Waiting for you reply, > Victor > > [0] > https://salsa.debian.org/pkg-voip-team/sngrep/-/tags/debian%2F1.6.0-1+deb12u1 Hi Victor, diff looks fine, but I don't believe this really needs a DSA; it's rather obscure attack vector. I think addressing this via the next Bookworm point release is perfectly fine, what do you think? Procedure is outlined at https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions Cheers, Moritz
Bug#1068412: apache2: CVE-2024-27316 CVE-2024-24795 CVE-2023-38709
On Fri, Apr 05, 2024 at 08:16:43AM +0400, Yadd wrote: > On 4/4/24 22:51, Moritz Mühlenhoff wrote: > > Source: apache2 > > X-Debbugs-CC: t...@security.debian.org > > Severity: grave > > Tags: security > > > > Hi, > > > > The following vulnerabilities were published for apache2. > > > > CVE-2024-27316[0]: > > https://www.kb.cert.org/vuls/id/421644 > > https://www.openwall.com/lists/oss-security/2024/04/04/4 > > > > CVE-2024-24795[1]: > > https://www.openwall.com/lists/oss-security/2024/04/04/5 > > > > CVE-2023-38709[2]: > > https://www.openwall.com/lists/oss-security/2024/04/04/3 > > > > If you fix the vulnerabilities please also make sure to include the > > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > > > For further information see: > > > > [0] https://security-tracker.debian.org/tracker/CVE-2024-27316 > > https://www.cve.org/CVERecord?id=CVE-2024-27316 > > [1] https://security-tracker.debian.org/tracker/CVE-2024-24795 > > https://www.cve.org/CVERecord?id=CVE-2024-24795 > > [2] https://security-tracker.debian.org/tracker/CVE-2023-38709 > > https://www.cve.org/CVERecord?id=CVE-2023-38709 > > > > Please adjust the affected versions in the BTS as needed. > > Hi, > > I'm ready to push 2.4.59 into bookworm-security. Note that this includes a > test-framework update Target distribution needs to be bookworm-security, with that please upload. Can you also preparea the equivalent change for bullseye-security? The uploads can already happen, but let's keep the update unreleased until next week, then we can look for regressions reported in unstable (and check with Ondrej if we received reports based on his repo) Cheers, Moritz
Bug#1060407: 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
Bug#1060407: Multiple security issues
Source: gtkwave Version: 3.3.116-1 Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team A very thorough security audit of gtkwave unveiled a total of 82 security issues in gtkwave, all fixed in 3.3.118: 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 Let's first fix unstable and then we can simple build 3.3.118 for stable-security and oldstable-security as well. Full details in these advisories from TALOS: https://talosintelligence.com/vulnerability_reports/TALOS-2023-1777 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1783 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1785 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1786 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1789 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1790 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1791 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1792 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1793 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1797 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1798 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1803 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1804 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1805 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1806 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1807 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1810 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1811 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1812 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1813 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1814 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1815 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1816 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1817 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1818 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1819 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1820 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1821 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1822 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1823 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1824 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1826 https://talosintelligence.com/vulnerability_reports/TALOS-2023-1827 Cheers, Moritz
Bug#1059054: nss: CVE-2023-6135
On Wed, Dec 20, 2023 at 11:43:11AM +0900, Mike Hommey wrote: > Version: 2:3.95-1 > > On Tue, Dec 19, 2023 at 10:21:27PM +0100, Moritz Mühlenhoff wrote: > > Source: nss > > X-Debbugs-CC: t...@security.debian.org > > Severity: grave > > Tags: security > > > > Hi, > > > > The following vulnerability was published for nss. > > > > CVE-2023-6135[0]: > > | Multiple NSS NIST curves were susceptible to a side-channel attack > > | known as "Minerva". This attack could potentially allow an attacker > > | to recover the private key. This vulnerability affects Firefox < > > | 121. > > > > The bug linked from > > https://www.mozilla.org/en-US/security/advisories/mfsa2023-56/#CVE-2023-6135 > > is restricted, do you happen to have a commit reference for NSS itself? > > It was fixed via https://bugzilla.mozilla.org/show_bug.cgi?id=1861728 > and https://bugzilla.mozilla.org/show_bug.cgi?id=1863605, apparently, in > a version that was released last month. Thanks! Cheers, Moritz
Bug#1054666: open-vm-tools: CVE-2023-34059 CVE-2023-34058
On Tue, Oct 31, 2023 at 10:29:55AM +0100, Bernd Zeimetz wrote: > > Both uploaded! DSA has been released, thanks! Cheers, Moritz
Bug#1054666: open-vm-tools: CVE-2023-34059 CVE-2023-34058
On Mon, Oct 30, 2023 at 07:09:53PM +0100, Bernd Zeimetz wrote: > Hi Moritz, > > as usual, stable/oldstable updates prepared, diffs are attached to this > mail as salsa seems to have some issues right now. > > https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/ - > bookworm/bullseye branches are actually there. > > Please let me know if/when I can upload. Thanks, these look fine, please upload to security-master. Cheers, Moritz
Bug#1051888: Should Kino be removed?
Source: kino Version: 1.3.4+dfsg0-1.1 Severity: serious Your package came up as a candidate for removal from Debian: - Dead upstream for a decade - FTBFS with ffmpeg 5 since 1.5 years (Debian is at ffmpeg 6 by now) - Depends on various legacy libs (GTK2, Glade) If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1050970: open-vm-tools: CVE-2023-20900
On Thu, Sep 07, 2023 at 11:43:27AM +0200, Bernd Zeimetz wrote: > Hi Moritz, > > > Ack, that's perfectly fine! > > > > Thanks! > > Here are the current diffs: > > bullseye: > https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/compare/15b2b38edd7834b7ad93ae25831fc7ef2bf7ce28...bullseye?from_project_id=38835=false > > bookworm: > https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/compare/2231c605efb0564efee229d6c535033159cc92bc...bookworm?from_project_id=38835=false These look good, please upload to security-master. bookworm needs to be build with -sa sicne it's the first upload, bullseye doesn't. Thanks! Cheers, Moritz
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
Bug#1035474: Don't include in Bookworm?
On Wed, May 31, 2023 at 09:28:02AM +0300, Timo Aaltonen wrote: > Moritz Muehlenhoff kirjoitti 3.5.2023 klo 20.44: > > Source: libdmx > > Version: 1:1.1.4-2 > > Severity: serious > > > > The Xorg folks mentioned at > > https://www.openwall.com/lists/oss-security/2023/05/02/3: > > > > | We have also announced that we plan to retire the following packages soon > > | and while their gitlab repos are not yet archived, we expect they will be > > | archived in the future, and encourage distros that still ship them to > > | consider retiring them on your side as well: > > | > > | lib/libdmx: > > | The Xdmx server was removed from the xorg-server sources in > > | xorg-server 21 (released Oct. 2021), so this is only useful > > | for communicating with Xdmx from the 1.20 and older releases. > > > > Given that Bookworm has xorg-server 21 and there are no rdeps in the > > archive, > > let's exclude it from bookworm (and remove entirely eventually)? > > sounds good Unfortunately I missed that xorg-dev depends on libdmx-dev, so this will have to wait until after the Bookworm release. Cheers, Moritz
Bug#1034824: tomcat9 should not be released with Bookworm
On Fri, May 26, 2023 at 12:10:18AM +0200, Markus Koschany wrote: > First of all trapperkeeper-webserver-jetty9-clojure should add a build- > dependency on logback to detect such regressions in advance. > > #1036250 is mainly a logback problem, not a tomcat problem. I still would like > to hear Emmanuel's opinion. We still could revert to libtomcat9-java, if we > don't find a solution though. > > The tomcatjss / dogtag-pki situation is simple too. If there is no way to make > the application work with Tomcat 10, then there are three options: > > 1. Embed Tomcat 9 in your application by creating a standalone jar > > 2. Continue to use the current Tomcat 9 package as is but make sure that > nobody > else than dogtag-pki uses it. (Package descriptions should be adjusted, and > the > binary tomcat9 package should be probably removed too) Nobody should think > that > we support two major Tomcat versions. > > In any case the dogtag-pki maintainers must commit to at least three years of > security support, web application + Tomcat 9. Otherwise this is pointless. > > 3. Remove dogtag-pki and tomcatjss from testing and prepare backports as soon > as dogtag-pki and Co support Tomcat 10. Can't we just do the pragmatic fix of updating src:tomcat9 to only ship libtomcat9-java and libtomcat9-embed-java? The maintenance burden for security updates lies within the server stack, the percentage of issues affecting the libtomcat9-java binary packages as used by rdeps will be small to none? Cheers, Moritz
Bug#1036279: XSS in RSS syntax
Source: dokuwiki Version: 0.0.20220731.a-1 Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team No CVE yet: https://huntr.dev/bounties/c6119106-1a5c-464c-94dd-ee7c5d0bece0/ https://github.com/dokuwiki/dokuwiki/pull/3967 https://www.github.com/splitbrain/dokuwiki/commit/53df38b0e4465894a67a5890f74a6f5f82e827de Cheers, Moritz
Bug#1035474: Don't include in Bookworm?
Source: libdmx Version: 1:1.1.4-2 Severity: serious The Xorg folks mentioned at https://www.openwall.com/lists/oss-security/2023/05/02/3: | We have also announced that we plan to retire the following packages soon | and while their gitlab repos are not yet archived, we expect they will be | archived in the future, and encourage distros that still ship them to | consider retiring them on your side as well: | | lib/libdmx: | The Xdmx server was removed from the xorg-server sources in | xorg-server 21 (released Oct. 2021), so this is only useful | for communicating with Xdmx from the 1.20 and older releases. Given that Bookworm has xorg-server 21 and there are no rdeps in the archive, let's exclude it from bookworm (and remove entirely eventually)? Cheers, Moritz
Bug#1034732: Keep out of testing
Package: gpac Version: 2.0.0+dfsg1-2+b1 Severity: serious In some discussion between Reinhard, Sebastian and the Security team we've come to the conclusion that gpac isn't suitable to be included in a stable release. The massive influx of security issues makes that untenable (and there's no suitable LTS branch we could use, which e.g. makes ffmpeg manageable). Sebastian has already updated x264 to no longer depend on it, when x264 2:0.164.3095+gitbaee400-3 has reached testing, gpac can be dropped. The only other rdep in ccextractor, which is already out of testing due to a lack of support for ffmpeg 5. Cheers, Moritz
Bug#1033335: Don't include in Bookworm
Source: rust-const-cstr Version: 0.3.0-1 Severity: serious Hi, there is https://rustsec.org/advisories/RUSTSEC-2023-0020.html which flags that rust-const-cstr is unmaintained. Since there are no reverse deps in the archive, let's exclude it from bookworm (or rather remove rightaway)? Cheers, Moritz
Bug#1033334: Don't include in Bookworm
Source: rust-boxfnonce Version: 0.1.1-2 Severity: serious Per https://rustsec.org/advisories/RUSTSEC-2019-0040.html rust-boxfnonce is obsolete, let's keep it out of bookworm (and remove from the archive). Cheers, Moritz
Bug#1033333: Don't include in Bookworm
Source: rust-encoding Version: 0.2.33-1 Severity: serious Hi, there is https://rustsec.org/advisories/RUSTSEC-2021-0153.html which flags that rust-encoding is unmaintained. Since there are no reverse deps in the archive, let's exclude it from bookworm (or rather remove rightaway)? Cheers, Moritz
Bug#1032476: apache2: CVE-2023-25690 CVE-2023-27522
On Wed, Mar 08, 2023 at 07:09:20AM +0400, Yadd wrote: > On 3/7/23 23:46, Salvatore Bonaccorso wrote: > > Source: apache2 > > Version: 2.4.55-1 > > Severity: grave > > Tags: security upstream > > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > > > > Hi, > > > > The following vulnerabilities were published for apache2. > > > > CVE-2023-25690[0]: > > > > CVE-2023-27522[1]: > > Hi, > > here is the debdiff for Bullseye I'm fine with a DSA, but we've seen a fair amount of regressions in 2.4.x releases, so let's wait a few days for regressions reported in sid (and Ondreys PHP repo). You can already upload the new version, though (we can reject/reupload if needed). Cheers, Moritz
Bug#1030669: Only include in Bookworm with commitment to stable updates
On Wed, Mar 08, 2023 at 02:20:25PM +0100, Marco d'Itri wrote: 0;115;0c> On Feb 14, Moritz Muehlenhoff wrote: > > > > > Varnish should only be included in Bookworm with a reliable commitment > > > > by the maintainers to backport/test security fixes across the typical > > > > three year life cycle (two years of stable-security and one year of > > > > oldstable-security). > > > I do not think that this will be helpful for Varnish users. > > Then someone needs to step up, it's as easy as that. > Fine: "I hereby commit to backport/test security fixes for varnish > across the lifetime of bookworm". Noted, thanks. Cheers, Moritz
Bug#1032086: Don't include in Bookworm
Source: golang-github-labstack-echo.v3 Version: 3.3.10-2 Severity: serious This is an older version of src:golang-github-labstack-echo. None of the reverse deps are currently in bookworm, so golang-github-labstack-echo.v3 should be dropped as well (and post freeze the reverse deps fixed and the package removed)
Bug#1032085: Don't include in Bookworm
Source: golang-github-labstack-echo.v2 Version: 2.2.0-3 Severity: serious This is an older version of src:golang-github-labstack-echo. None of the reverse deps are currently in bookworm, so golang-github-labstack-echo.v2 should be dropped as well (and post freeze the reverse deps fixed and the package removed)
Bug#972146: /usr/share/applications/mono-runtime-common.desktop: should not handle MIME type by executing arbitrary code
On Sat, Feb 18, 2023 at 12:04:27PM +0100, Gabriel Corona wrote: > I believe obtaining a CVE ID would be beneficial so that this issue may be > tracked by downstream projects/distributions. All those distros were notified via your post to oss-security. You can try cveform, if there's no assignment via that channel, that's about it. In the past assigning CVEs for Debian was simple, but with some recent changes it has become a complicated, time-consuming process and now we only do it in select cases. Cheers, Moritz
Bug#1030669: Only include in Bookworm with commitment to stable updates
On Tue, Feb 14, 2023 at 02:48:43AM +0100, Marco d'Itri wrote: > On Feb 02, Moritz Muehlenhoff wrote: > > > Varnish should only be included in Bookworm with a reliable commitment > > by the maintainers to backport/test security fixes across the typical > > three year life cycle (two years of stable-security and one year of > > oldstable-security). > I do not think that this will be helpful for Varnish users. Then someone needs to step up, it's as easy as that.
Bug#1031046: Only include in Bookworm with commitment to stable updates
Source: asterisk Version: 1:20.1.0~dfsg+~cs6.12.40431414-1 Severity: serious Asterisk should only be included in Bookworm with a reliable commitment by the maintainers to backport/test security fixes across the typical three year life cycle (two years of stable-security and one year of oldstable-security). (There have been 37 CVEs in 2021/2022) Cheers, Moritz
Bug#1030669: Only include in Bookworm with commitment to stable updates
Source: varnish Version: 7.1.1-1.1 Severity: serious Varnish should only be included in Bookworm with a reliable commitment by the maintainers to backport/test security fixes across the typical three year life cycle (two years of stable-security and one year of oldstable-security). Especially since testing currently has 7.1, which reaches it's end of life on March 15 2023 and does not contain the LTS release. (It's not unlikely that most people who operate a CDN based on Varnish only use custom/patched/recent packages backported from stable anyway, which is perfectly fine, but then let's make that explicit by keeping it out of testing). Cheers, Moritz
Bug#1019230: Bug#1021276: Pending snort 2.9.20 update
On Sat, Jan 21, 2023 at 10:53:24PM +0100, Markus Koschany wrote: > Hi Javier, > > Am Freitag, dem 20.01.2023 um 22:23 +0100 schrieb Javier Fernandez-Sanguino: > > Dear Markus, > > > > Thank you for preparing. Could you please share the patch you are working > > on? > > Snort is available in Salsa. Maybe you could upload / provide there your > > propose changes in a separate branch? > > I'm adding the security team to CC to give them a heads-up because the snort > update is also relevant for stable and oldstable. I'm not allowed to push to > your Git repository on salsa. I will just attach my debian directory to the RC > bug reports next. > > First of all I decided to package 2.9.20 because this version seems less > intrusive than the new 3.x series. Thanks for fixing up buster/bullseye for existing users (which I think is best catered by moving to 2.9.20, but I don't think snort should be in Bookworm: - No upload since almost 1.5 years, zero followup to #1019230 or #1021276 until your poke - What's worse: The security progress is completely intransparent, apart from dropping new releases with vague Cisco advisories Cheers, Moritz
Bug#1028421: Only include in Bookworm with commitment to stable updates
Source: salt Severity: serious salt is currently RC-buggy and not in testing, but regardless of the remaining RC bugs getting fixed it should only get re-included with a reliable commitment to backport/test security-updates across the typical three year life cycle (two years of stable-security and one year of oldstable-security). Cheers, Moritz
Bug#1004441: unblocking chromium?
On Fri, Jan 06, 2023 at 08:41:50AM +0100, Paul Gevers wrote: > Dear Chromium team, Security team, > > On 27-01-2022 17:15, Moritz Muehlenhoff wrote: > > On Wed, Jan 26, 2022 at 09:38:42PM +0100, Paul Gevers wrote: > > > > So, I'm proposing the following: we unblock chromium from > > > > testing, with the understanding that prior to bookworm's release, we > > > > have a discussion with the release team about whether chromium will > > > > be allowed in the stable release. This will allow testing users to > > > > upgrade for now, and then at bookworm freeze time we can figure out what > > > > will happen with chromium (and prepare the appropriate release notes if > > > > it will no longer be in stable/testing). What does the release team & > > > > others think of this? > > > > Sounds good! > > > > > If the security team agrees with the message this is sending, > > > I propose the following. We create an RC bug against release.debian.org > > > (to > > > make sure this issue is not forgotten, but not directly blocks chromium) > > > with an "Affects: chromium", that clearly states that we postpone the > > > decision. The decision will depend on how chromium updates (both in sid > > > and > > > supported releases) are handled between now and approximately the freeze. > > > If > > > we do this, don't get me wrong, I'll kick chromium out of bookworm again > > > if > > > there's no good track record before we release. > > > > Sounds good! > > It's about time we start discussing this. In your opinion, did the Chromium > Team show enough track record to warrant chromium in bookworm during its > stable cycle? From the raw number of uploads my first impression is yes, but > I have no idea of the quality, how the communication went and those kind of > details. Andres's work has been top notch and it seems recently someone else has joined the effort as well, so if they are up for continuing with Chromium's pace, that's perfectly fine to continue to do so for bookworm. We might consider to set some expectation for oldstable-security, though e.g state that oldstable-security updates stop three months after the release of stable or so. Chromium is very fast-paced in toolchain changes (e.g. in the past new C++ features become incompatible with GCC and we might see something similar with LLVM (which is used these days) as well. Cheers, Moritz
Bug#1026163: Uses Java 11
Source: puppetdb Version: 7.11.2-3 Severity: grave Thanks for all the great work on Puppetdb! I was trying to setup a test environment with Puppetdb 7.11.2 from current testing and I noticed that it's using openjdk-11-jre-headless. While openjdk-11 is currently still in testing, Bookworm will only include openjdk-17 (#1023237). Cheers, Moritz
Bug#1025011: Keep out of bookworm unless actively maintained
Source: netatalk Version: 3.1.13~ds-2 Severity: serious netatalk should not enter bookworm unless it gets adopted and actively maintained. Cheers, Moritz
Bug#1024561: Unmaintained, keep out of stable
Source: maradns Version: 2.0.13-1.4 Severity: serious The last maintainer upload was in 2015 and the version currently in the archive is way behind current upstream releases (which is at 3.4.07), we have plenty of maintained DNS servers, keep it out of testing ( and if noone picks it up, remove it from the archive).
Bug#1023697: Keep out of testing
Source: wolfssl Version: 5.2.0-2 Severity: serious wolfssl has no active maintainer, plenty of open security issues and we already have too many TLS libraries in our releases. Keep it out of testing. I'm going to file bugs against the handful of reverse deps. Cheers, Moritz
Bug#1022931: Should viewmol be removed?
Source: viewmol Version: 2.4.1-26 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 (which will soon be removed) - Dead upstream - Dropped from testing for over two years If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1022932: Should fbpanel be removed?
Source: fbpanel Version: 7.0-4.3 Severity: serious Your package came up as a candidate for removal from Debian: - Depends on Python 2, which will soon be removed - Last maintainer upload five years ago - Dead upstream If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696
Hi Clément, > Sadly, upstream rectified and confirms it affects 2.2 [0], and has been > tested and reproduced on Bullseye. We do need to fix it. Upstream has a few > suggestions, but I guess our choices are either uploading 2.5 to stable, if > that's possible. python-stem at least will need to be updated as well, from > 1.8.0 to 1.8.1 which luckily is bugfix only. With the upstream confirmation about affected states I had a look at the remaining issues affecting Bullseye: CVE-2022-21694 (https://github.com/onionshare/onionshare/security/advisories/GHSA-h29c-wcm8-883h) is not a vulnerability by itself, it's a lack of a feature at most. We can ignore it for Bullseye. CVE-2022-21688 (https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v) is just a stop gap, the actual issue is in QT and I'll reach out to upstream for more information when this was fixed in QT so that it can be backported to Bullseye's QT packages. This leaves: https://security-tracker.debian.org/tracker/CVE-2022-21690 https://security-tracker.debian.org/tracker/CVE-2022-21689 https://security-tracker.debian.org/tracker/CVE-2021-41868 I think it's fair to ignore CVE-2021-41868 for Bullseye, it sounds like an edge case and invasive to fix. This leaves CVE-2022-21690 and CVE-2022-21689 which have isolated patches which could be backported? Given that the primary use case for onionshare will be tails, my suggestion would be that CVE-2022-21689 and CVE-2022-21690 get backported fixes for the next Bullseye point release (which Tails will sync up to). What do you think? Cheers, Moritz
Bug#1021737: lava: CVE-2022-42902
On Tue, Oct 18, 2022 at 06:09:42PM -0300, Antonio Terceiro wrote: > Hi, > > On Thu, Oct 13, 2022 at 09:13:18PM +0200, Moritz Mühlenhoff wrote: > > Source: lava > > X-Debbugs-CC: t...@security.debian.org > > Severity: grave > > Tags: security > > > > Hi, > > > > The following vulnerability was published for lava. > > > > CVE-2022-42902[0]: > > | In Linaro Automated Validation Architecture (LAVA) before 2022.10, > > | there is dynamic code execution in lava_server/lavatable.py. Due to > > | improper input sanitization, an anonymous user can force the lava- > > | server-gunicorn service to execute user-provided code on the server. > > > > https://git.lavasoftware.org/lava/lava/-/merge_requests/1834 > > https://git.lavasoftware.org/lava/lava/-/commit/e66b74cd6c175ff8826b8f3431740963be228b52?merge_request_iid=1834 > > > > If you fix the vulnerability please also make sure to include the > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > > > For further information see: > > > > [0] https://security-tracker.debian.org/tracker/CVE-2022-42902 > > https://www.cve.org/CVERecord?id=CVE-2022-42902 > > > > Please adjust the affected versions in the BTS as needed. > > I have uploaded a fix version to unstable (latest upstream), and I would > like to upload the attached debdiff to -security. That package builds > cleanly and passes its autopkgtest on bullseye. Let me know. Ack, we can fix this via a DSA. The debdiff looks fine content-wise, but the deb111u1 version is slightly off by 100 Debian releases ;-) So please change to +deb11u1 and upload to security-master. Cheers, Moritz
Bug#1021810: Should firefox-esr be dropped on 32bit architectures in bookworm?
On Sat, Oct 15, 2022 at 09:27:33AM +0300, Adrian Bunk wrote: > Package: firefox-esr > Version: 102.3.0esr-1 > Severity: serious > Tags: bookworm sid > X-Debbugs-Cc: Carsten Schoenert , > debian-rele...@lists.debian.org, t...@security.debian.org, > debian-...@lists.debian.org > > [ various potentially interested parties are Cc'ed ] > > 4 GB address space for one process is an absolute limit on 32bit > architectures, including for native building as is done in Debian.[1] Thanks for bootstrapping the discussion. I fully agree that we should limit Firefox/Thunderbird to 64 archs for bookworm. Cheers, Moritz
Bug#1019230: Current version is EOLed
Source: snort Version: 2.9.15.1-6 Severity: serious Per https://blog.snort.org/2021/07/29150-has-reached-its-end-of-life.html the version currently in sid is EOLed and no longer compatible with current rule updates. In general snort seems unsuitable for standard stable given that the engine needs to keep up with rule sets, so if it should be included in bookworm, it should probably get updated via -updates as we do for clamav. Cheers, Moritz -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1017579: Freeciv < 2.6.7, freeciv-3.0 < 3.0.3, Modpack Installer buffer overflow
Source: freeciv Version: 2.6.6-1 Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team Quoting from the announcement posted to oss-security (no CVE is available): -- Just released freeciv-2.6.7 & freeciv-3.0.3 fix buffer overflow in Modpack Installer utility's handling of the modpack URL. Specially crafted URLs, without any '/' -characters would result in an underflowing length (unsigned)(-1) string copy, i.e., all of the NULL-terminated string given as "URL" would get written beyond the buffer reserved for it. Freeciv source tarballs are available from https://www.freeciv.org/download.html for current 3.0, and from https://www.freeciv.org/wiki/Old_downloads for 2.6. In case you can't make full version update at the moment, bug tracker ticket has also a patch for this single issue attached: https://osdn.net/projects/freeciv/ticket/45299 --
Bug#1017062: Should kross be removed?
Source: kross Version: 5.96.0-1 Severity: serious See #1017061, kross isn't useful without interpreters. Cheers, Moritz
Bug#1017061: Should kross-interpreters be removed?
Source: kross-interpreters Version: 4:21.12.3-1 Severity: serious Your package came up as a candidate for removal from Debian. On IRC Sune mentioned that libkross is most probably unused these days and on the KF6 removal list. And the Python bindings still depend on Python 2 (without porting activity) which is being removed from bookworm. If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in two weeks. Cheers, Moritz
Bug#1016974: sofia-sip: CVE-2022-31001 CVE-2022-31002 CVE-2022-31003
On Thu, Aug 11, 2022 at 11:08:49PM +0200, Evangelos Ribeiro Tzaras wrote: > Hi Moritz, > > On Wed, 2022-08-10 at 22:08 +0200, Moritz Mühlenhoff wrote: > > Source: sofia-sip > > X-Debbugs-CC: t...@security.debian.org > > Severity: grave > > Tags: security > > > > Hi, > > > > The following vulnerabilities were published for sofia-sip. > > I will try to apply the patches and prepare a release! > > > CVE-2022-31001[0]: > ... > > CVE-2022-31002[1]: > ... > > CVE-2022-31003[2]: > ... > > > > > If you fix the vulnerabilities please also make sure to include the > > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > ACK. > Is there a specific format needed when referencing the CVE? Not really, just mention them in debian/changelog :-) In addition we'll keep security-tracker.debian.org updated when the upload reaches unstable. Once the fix is in unstable (and if there are issues reported after a few days) we can sort out an update for bullseye-security. Cheers, Moritz
Bug#1016986: Should pd-py be removed?
Source: pd-py Version: 0.2.2+git20170625.1.88fc77a-2 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2, which is finally being removed in Bookworm - Last upload in 2018 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1016983: Should k3d be removed?
Source: k3d Version: 0.8.0.6-8 Severity: serious Your package came up as a candidate for removal from Debian: - Python 2 will finally be removed in Bookworm and there's no upstream porting activity - Last upload four years ago - Multiple other FTBFS issue If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1016139: For Review: Bug#1016139: (net-snmp: CVE-2022-24810 CVE-2022-24809 CVE-2022-24808 CVE-2022-24807 CVE-2022-24806 CVE-2022-24805)
On Wed, Aug 10, 2022 at 05:05:12PM +1000, Craig Small wrote: > > Do you have capacity to prepare updates for bullseye? > > > Yes, see attached debdiff for review. It's just those two patches. Looks good, thanks! Please upload to security-master. Cheers, Moritz
Bug#1016667: Should this package be removed?
Source: caldav-tester Version: 7.0+20190225-4 Severity: serious Your package came up as a candidate for removal from Debian: The plan is to remove Python 2 in Bookworm and there's no porting activity towards Python 3. If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1015980: Should pd-aubio be removed?
Source: pd-aubio Version: 0.4-1 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 - Last upload in 2014 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1015981: Should grokmirror be removed?
Source: grokmirror Version: 1.0.0-1.1 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 - Last maintainer upload in 2016 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1015979: Should python-unshare be removed?
Source: python-unshare Version: 0.2-1 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 - Last upload in 2016 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1015978: Should falcon be removed?
Source: falcon Version: 1.8.8-1 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 - Dropped from testing in 2018 - Last upload in 2017 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1015977: Should vland be removed?
Source: vland Version: 0.8-1 Severity: serious Your package came up as a candidate for removal from Debian, it's one of the few remaining packages still depending on Python 2 and there're no visible upstream activity to port it to vland? If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1015976: Should vmm be removed?
Source: vmm Version: 0.6.2-2 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 - Last upload in 2017, removed from testing since 2019 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1015975: Should python-neuroshare be removed?
Source: python-neuroshare Version: 0.9.2-1 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 - Last upload in 2014 - Dead upstream (last commits from 2016) If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1015974: Should gnat-gps be removed?
Source: gnat-gps Version: 19.2-3 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 - Removed from testing since 2019 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1015973: Should xdeb be removed?
Source: xdeb Version: 0.6.7 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 - No upload since five years If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1012513: apache2: CVE-2022-31813 CVE-2022-26377 CVE-2022-28614 CVE-2022-28615 CVE-2022-29404 CVE-2022-30522 CVE-2022-30556
On Wed, Jun 08, 2022 at 07:51:28PM +0200, Yadd wrote: > Hi, > > those CVEs are tagged low/moderate by upstream, why did you tag this bug as > grave ? Anything moderate or above should get fixed by the next Debian release IOW RC severity. Cheers, Moritz
Bug#1012138: CVE-2021-40426
Source: sox Version: 14.4.2+git20190427-3 Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team https://talosintelligence.com/vulnerability_reports/TALOS-2021-1434 The report states that upstream was notified, but we need to figure out whether this was addressed by upstream already or not (and if so, in which commit) Cheers, Moritz
Bug#1009282: Should live-wrapper be removed?
Source: live-wrapper Version: 0.10 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since 2019 - Depends on vmdebootstrap which was removed - It's not included in Bullseye, but we did release live images so I guess live-wrapper got replaced by something else? If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal at some point. Cheers, Moritz
Bug#1009281: Should cinfony be removed?
Source: cinfony Version: 1.2-4 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since 2019 - Dead upstream - No reverse dependencies If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1009280: Should python-passfd be removed?
Source: python-passfd Version: 0.2-3 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since 2020 - No reverse dependencies - Last upload in 2016 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1009276: Should fsl be removed?
Source: fsl Version: 5.0.8-6 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since two years - Also FTBFSes with GCC 10 - Last upload in 2019 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1009273: Should python-keepkey be removed?
Source: python-keepkey Version: 0.7.3-1 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since 2019 - Last upload back in 2016 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1009269: Should sphinx-patchqueue be removed?
Source: sphinx-patchqueue Version: 0.5.0-2 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since 2019 - No remaining reverse dependencies - Last upload in 2015 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008792: Should vmtk be removed?
Source: vmtk Version: 1.3+dfsg-2.3 Severity: serious Your package came up as a candidate for removal from Debian: - Depends on Python 2 and thus removed from testing since 2019 (current upstream 1.4 is fixed, though) - Last maintainer upload in 2016 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008791: Should googlefontdirectory-tools be removed?
Source: googlefontdirectory-tools Version: 20120309.1-1.1 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since 2019 - Last maintainer upload in 2015 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008704: Sould astk be removed?
Source: astk Version: 1.13.1-2.1 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since 2019 - Last maintainer upload in 2014 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008703: Should sortsmill-tools be removed?
Source: sortsmill-tools Version: 0.4-2 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python and thus removed from testing since 2019 - Last upload in 2013 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008702: Should ketchup be removed?
Source: ketchup Version: 1.0.1+git20111228+e1c62066-2 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since 2019 - Last upload in 2017 - Seems dead upstream (last commit from eight years ago) - Per #946203 doesn't even suppport kernels using 5.x.x If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008701: Should broctl be removed?
Source: broctl Version: 1.4-1 Severity: serious Your package came up as a candidate for removal from Debian: - Still uses Python 2.7 and thus removed from testing since 2019 - Last upload in 2015 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008700: Should geda-gaf be removed?
Source: geda-gaf Version: 1:1.8.2-11 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since 2019 - Also uses outdated Guile - Last upload in 2018 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008500: Should undertaker be removed?
Source: undertaker Version: 1.6.1-4.2 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and thus removed from testing since 2019 - Last maintainer upload in 2016 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008499: Should neard be removed?
Source: neard Version: 0.16-0.1 Severity: serious Your package came up as a candidate for removal from Debian: - Last maintainer upload in 2013 - Depends on Python 2 and thus removed from testing since 2019 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008498: Should hgsubversion be removed?
Source: hgsubversion Version: 1.9.3+git20190419+6a6ce-5 Severity: serious Your package came up as a candidate for removal from Debian: - Still depends on Python 2 and removed from testing since 2020 - Dead upstream (no commits after 2019) If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008285: Should zorp be removed?
Source: zorp Version: 7.0.1~alpha2-3 Severity: serious Your package came up as a candidate for removal from Debian: - Last upload in 2019, removed from testing since 2017 - Still depends on Python 2.7 and thus RC-buggy If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008286: Should nglister be removed?
Source: nglister Version: 1.0.2 Severity: serious Your package came up as a candidate for removal from Debian: - Last upload in 2016 - Removed from testing since 2019 - Multiple RC bugs If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008274: Should sandsifter be removed?
Source: sandsifter Version: 1.04-1 Severity: serious Your package came up as a candidate for removal from Debian: - Still uses Python 2.7 and thus RC buggy - Last upload in 2019 and not in testing since 2019 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008273: Should python-nemu be removed?
Source: python-nemu Version: 0.3.1-1 Severity: serious Your package came up as a candidate for removal from Debian: - Last upload in 2016 and dropped from testing in 2019 - Still uses Python 2.7 and not fixed upstream either If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008272: Should postnews be removed?
Source: postnews Version: 0.7-1 Severity: serious Your package came up as a candidate for removal from Debian: - Removed from testing for ~ two years, no followup to RC bugs - Also no changes upstream since 2017 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008271: Should arriero be removed?
Source: arriero Version: 0.6-1 Severity: serious Your package came up as a candidate for removal from Debian: - Last upload in 2017 - Still uses Python 2.7 and thus RC buggy - Missed the last two stable releases and removed from testing since 2018 If you disagree and want to continue to maintain this package, please just close this bug (and fix the open issues). If you agree with the removal, please reassign to ftp.debian.org by sending the following commands to cont...@bugs.debian.org: -- severity $BUGNUM normal reassign $BUGNUM ftp.debian.org retitle $BUGNUM RM: -- RoM; thx -- Otherwise I'll move forward and request it's removal in a month. Cheers, Moritz
Bug#1008265: CVE-2018-25032: zlib memory corruption on deflate
Source: zlib Version: 1:1.2.11.dfsg-2 Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team This was assigned CVE-2018-25032: https://www.openwall.com/lists/oss-security/2022/03/24/1 https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531 Cheers, Moritz
Bug#1008264: Multiple security issues
Source: pluxml Version: 5.6-1 Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team CVE-2022-25020: https://github.com/MoritzHuppert/CVE-2022-25020/blob/main/CVE-2022-25020.pdf CVE-2022-25018: https://github.com/MoritzHuppert/CVE-2022-25018/blob/main/CVE-2022-25018.pdf CVE-2022-24587: https://github.com/Nguyen-Trung-Kien/CVE/blob/main/CVE-2022-24587/CVE-2022-24587.pdf CVE-2022-24586: https://github.com/Nguyen-Trung-Kien/CVE/blob/main/CVE-2022-24586/CVE-2022-24586.pdf CVE-2022-24585: https://github.com/Nguyen-Trung-Kien/CVE/blob/main/CVE-2022-24585/CVE-2022-24585.pdf CVE-2021-38603: http://packetstormsecurity.com/files/163823/PluXML-5.8.7-Cross-Site-Scripting.html https://github.com/KielVaughn/CVE-2021-38603 CVE-2021-38602: https://github.com/KielVaughn/CVE-2021-38602 Cheers, Moritz
Bug#1005981: Please migrate away from dpatch
On Fri, Feb 18, 2022 at 02:41:57PM -0800, Bill Poser wrote: > I am the developer of redet. I don't understand this bug report. redet does > not use anything called dpatch so far as I know. Is this something added in > the Debianization of redet downstream from me? Yes, exactly. It's a legacy mechanism in Debian to apply patches to an upstream codebase. Cheers, Moritz
Bug#1005988: Don't release with bookworm
Source: dpatch Version: 2.0.41 Severity: serious dpatch has been obsoleted by source format 3.0 (quilt), there's only 19 reverse dependencies in the archive (5 of them in testing), for which bugs have been filed. Cheers, Moritz
Bug#1005987: Please migrate away from dpatch
Source: mgetty Version: 1.2.1-1.1 Severity: serious dpatch is deprecated and will be removed before the bookworm release. Please migrate to source format 3.0 (quilt) instead.
Bug#1005986: Please migrate away from dpatch
Source: dvbsnoop Version: 1.4.50-5 Severity: serious dpatch is deprecated and will be removed before the bookworm release. Please migrate to source format 3.0 (quilt) instead.
Bug#1005985: Please migrate away from dpatch
Source: scim-skk Version: 0.5.2-7.2 Severity: serious dpatch is deprecated and will be removed before the bookworm release. Please migrate to source format 3.0 (quilt) instead.
Bug#1005984: Please migrate away from dpatch
Source: scim-canna Version: 1.0.0-4.3 Severity: serious dpatch is deprecated and will be removed before the bookworm release. Please migrate to source format 3.0 (quilt) instead.
Bug#1005983: Please migrate away from dpatch
Source: myspell Version: 1:3.0+pre3.1-24.2 Severity: serious dpatch is deprecated and will be removed before the bookworm release. Please migrate to source format 3.0 (quilt) instead.
Bug#1005981: Please migrate away from dpatch
Source: redet Version: 8.26-1.4 Severity: serious dpatch is deprecated and will be removed before the bookworm release. Please migrate to source format 3.0 (quilt) instead.
Bug#1005982: Please migrate away from dpatch
Source: elscreen Version: 1.4.6-5.3 Severity: serious dpatch is deprecated and will be removed before the bookworm release. Please migrate to source format 3.0 (quilt) instead.
Bug#1005980: Please migrate away from dpatch
Source: syrep Version: 0.9-4.3 Severity: serious dpatch is deprecated and will be removed before the bookworm release. Please migrate to source format 3.0 (quilt) instead.
Bug#1005978: Please migrate away from dpatch
Source: vdk2 Version: 2.4.0-5.5 Severity: serious dpatch is deprecated and will be removed before the bookworm release. Please migrate to source format 3.0 (quilt) instead.
Bug#1005979: Please migrate away from dpatch
Source: efax Version: 1:0.9a-20 Severity: serious dpatch is deprecated and will be removed before the bookworm release. Please migrate to source format 3.0 (quilt) instead.
Bug#1004963: CVE-2020-21598 CVE-2020-21600 CVE-2020-21602
Source: libde265 Version: 1.0.8-1 Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team CVE-2020-21602: https://github.com/strukturag/libde265/issues/242 CVE-2020-21600: https://github.com/strukturag/libde265/issues/243 CVE-2020-21598: https://github.com/strukturag/libde265/issues/237
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: > How should I handle this? NMU to sid, let people try it out, and then > deal with buster/bullseye? Yeah, let's proceed with unstable first in any case. > Upload everything all at once? I'm also > going to try building for buster, unless the security team doesn't > think I should bother. I saw https://salsa.debian.org/dilinger/chromium/-/commit/5c05f430e192961527ec9a64bbaa64401dc14d95 , but buster now also includes LLVM/clang 11 (it was introduced to support a more recent Rust toolchain needed for Firefox), so you might be reduce complexity here further: https://tracker.debian.org/pkg/llvm-toolchain-11 It's in buster-proposed-updates since there hasn't been a point release since, but for the purposes of buster-security builds, it doesn't matter (they chroots have been modified to includen buster-proposed-updates temporarily): I'd say if it works out without additional overhead, let's also update buster-security, but it's also important not to overstretch the time/resources, so focusing on bullseye and EOLing buster is also an option for sure. Cheers, Moritz
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Jan 02, 2022 at 06:53:51PM +0100, Mattia Rizzolo wrote: > Correlated, do you know how long do they plan on keeping using python2? > That's plainly unsuitable, it really is not going to last much longer in > debian. Current state of the Python 3 upstream migration can be found here: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/python3_migration.md So it sounds like it's almost ready except tests. But the migration doesn't seem like a top priority either, https://bugs.chromium.org/p/chromium/issues/detail?id=941669 dates back to March 2019... Cheers, Moritz
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote: > On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote: > > Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers: > > Exactly that. > > > > I'd suggest anyone who's interested in seeing Chromium supported to first > > update it in unstable (and then work towards updated in bullseye-security). > > I started doing just that: https://salsa.debian.org/dilinger/chromium (v96 > and misc-fixes branches). As a side note: If any of the system/* patches cause issues, feel free to switch to the vendored copies. Vendoring in general is frowned upon since it requires that a fix in a libraries spreads out to all vendored copies, but for Chromium there's a steady stream of Chromium-internal security issues anyway, so for all practical purposes it doesn't make a difference if the Chromium security releases also include a fix for a vendored lib like ICU. Cheers, Moritz
