Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns
Am Wed, Jun 22, 2022 at 10:05:37AM +0200 schrieb Graham Inggs: > Hi, > > As part of the interim architecture qualification for bookworm, we > request that DSA, the security team, Wanna build, and the toolchain > maintainers review and update their list of known concerns for bookworm > release architectures. > In particular, we would like to hear any new concerns for riscv64 > (see below). There are no concerns für riscv64, but the quickly vaninishing upstream support for i386 and the lack of active porters make i386 problematic from the Security Team's point of view. For packages where new upstream releases are being introduced this makes it extra brittle: Firefox/buster fails to compile due to toolchain issues (triggers an ICE in GCC) for almost a year now (since the update to ESR91) and for Chromium there have also been random build failures (e.g. #1011096) and for Chromium current releases no longer officially i386, quoting from the chromium 102.0.5005.115-1 changelog entry: | - debianization/support-i386.patch - re-enable support for i386 builds. | Upstream no longer officially supports i386 builds on linux, so we | are on our own here. Essentially that means that noone can expect to have consistent security updates when running i386 for the two main browsers. These two specific issues could very well be addressed by dropping i386 from the archs for Firefox/Thunderbird/Chromium, but Chromium also spreads into the Qt web packages. But there are also issues in software not following new upstream releases in stable, e.g. #1006935 or 1009855 which broke Samba in stable. In addition there's also the issues with late or missing upstream support for the quartely speculation attacks Ben has already mentioned. Cheers, Moritz
Bug#990542: glibc: CVE-2021-35942
Source: glibc X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for glibc. CVE-2021-35942[0]: Wild read in wordexp (parse_param) https://sourceware.org/bugzilla/show_bug.cgi?id=28011 https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=5adda61f62b77384718b4c0d8336ade8f2b4b35c 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-2021-35942 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-35942 Please adjust the affected versions in the BTS as needed.
Bug#969926: glibc: Parsing of /etc/gshadow can return bad pointers causing segfaults in applications
Am Wed, Sep 09, 2020 at 12:30:44PM +0200 schrieb Aurelien Jarno: > control: forcemerge 967938 969926 > > Hi, > > On 2020-09-09 02:58, Bernd Zeimetz wrote: > > Source: glibc > > Version: 2.28-10 > > Severity: serious > > Tags: security upstream patch > > X-Debbugs-Cc: Debian Security Team > > > > Hi, > > > > we are running into the bug > > https://sourceware.org/bugzilla/show_bug.cgi?id=20338 > > causing systemd-sysusers to segfault. > > > > Patch is available in the linked bug report. > > This has already been reported, Florian will work on a backport, as it > is not straightforward to backport it to buster due to the usage of > private symbols. Florian, did you manage to backport this to 2.31? It would be nice to get this fixed for a Buster point release still. Cheers, Moritz
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Paul Gevers wrote: > As part of the interim architecture qualification for bullseye, we > request that DSA, the security team, Wanna build, and the toolchain > maintainers review and update their list of known concerns for bullseye > release architectures. There's nothing really of concern from the security team PoV, we don't withhold security updates due to missing archs, so the worst case is that some archs are outdated (happens to openjdk from time to time). > Whilst porters remain ultimately responsible for ensuring the > architectures are ready for release, we do expect that you / your team > are willing to assist with clarifications of the concerns and to apply > patches/changes in a timely manner to resolve the concerns. I think the porter requirement for i386 should no longer be waived (the current wiki page still says so). i386 is legacy hardware for a long time and increasingly starts to lose upstream support (and most other distros ceased support a well). If there people who care about i386 for whatever reason, they should form a debian-i386@ porter list which offers to fix i386-specific issues. Cheers, Moritz
Bug#681888: CVE-2012-3406: exploits in the wild, upstream report?
On Tue, Feb 05, 2013 at 05:56:15PM +0100, Arne Wichmann wrote: Hi, just for information: [1] suggests that exploits for one of 340[456] may be out in the wild. Moreover I did not find an upstream glibc-bug about this yet. Is there one? [1] https://bugs.launchpad.net/ubuntu/%2Bsource/eglibc/%2Bbug/1031301 This has now been fixed upstream, can you please merge this into jessie ? https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5985c6ea868db23380977a35a2167549f9a3653b Cheers, Moritz -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150117144415.GA21078@pisco.westfalen.local
Bug#522774: Bug#522773: possible solutions for __unused problem
On Sun, Jun 19, 2011 at 07:09:37PM +, Thorsten Glaser wrote: Ben Hutchings dixit: The use of __undefined in the BSDs predates use of it by both Linux and GNU. (But when using this argumentation style, we’d probably better take this upstream… except that upstream may not be helping…) We already asked you back in September 2009 to report this upstream. If you don't think that will help, we can just close the bug, then. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110729150817.GA23022@pisco.westfalen.local
