Bug#1072300: RM: phppgadmin/7.13.0+dfsg-2
Am Fri, May 31, 2024 at 03:53:13PM -0300 schrieb Leandro Cunha: > Package: release.debian.org > Control: affects -1 + src:phppgadmin > X-Debbugs-Cc: phppgad...@packages.debian.org > User: release.debian@packages.debian.org > Usertags: rm > X-Debbugs-Cc: leandrocunha...@gmail.com > Severity: normal > > Reason and request > I open this bug to request the removal of the phppgadmin package > version 7.13.0+dfsg-2 from the current stable version of Debian I suppose it should also be removed from bullseye/oldstable, right? If so, can you please file a separate bug for it? Cheers, Moritz
Bug#1068694: bullseye-pu: package json-smart/2.2-2+deb11u1
Am Tue, Apr 09, 2024 at 10:01:11AM +0200 schrieb Andreas Beckmann: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: Bastien Roucariès > Control: affects -1 + src:json-smart > Control: block 1039985 with -1 > Control: block 1033474 with -1 > > [ Reason ] > Two CVEs were fixed in buster-lts, but not yet in bullseye or later, > causing version skew on upgrades: CVE-2023-1370 / #1033474 is unfixed in sid, and being fixed in unstable is a pre condition for a point update. Bastien, since you fixed it in buster-lts, can you please also take care of addressing unstable? Cheers, Moritz
Bug#1040925: bookworm-pu: package ca-certificates-java/20230103+x
Am Sat, Jul 22, 2023 at 02:44:17PM +0100 schrieb Jonathan Wiltshire: > Control: tag -1 confirmed > > On Sat, Jul 15, 2023 at 11:39:02PM +0200, Andreas Beckmann wrote: > > Followup-For: Bug #1040925 > > Control: retitle -1 bookworm-pu: package > > ca-certificates-java/20230620~deb12u1 > > > > my suggestion: rebuild the 20230620 package from sid > > Please go ahead. Andreas, could you please proceed with the upload? This bug also affects the bookworm-security chroots for building Java applications and your upload (since the bookworm-security chroots currently include bookworm-proposed-updates) would unbreak the orthanc builds needed for CVE-2023-33466. Cheers, Moritz
Bug#1008164: RM: obfs4proxy/0.0.8-1
Am Mon, Jul 31, 2023 at 08:05:29AM +0100 schrieb Jonathan Wiltshire: > Hi, > > On Mon, Jul 04, 2022 at 07:36:12PM +0100, Adam D. Barratt wrote: > > Control: retitle -1 RM: obfs4proxy -- RoM; security issues > > Control: tags -1 + moreinfo > > > > On Sat, 2022-03-26 at 21:21 +0100, Paul Gevers wrote: > > > Control: tag -1 bullseye > > > > > > Hi Ana, > > > > > > On 23-03-2022 13:13, Ana Custura wrote: > > > > Opening this bug after a recomendation from debian-security. > > > > Version 0.0.8 of obfs4proxy has a security bug, which has only been > > > > fixed in a later > > > > version (0.0.13, see bug number #1004374), and also suffers from > > > > incompatibilty issues > > > > with later versions of the package. Version 0.0.13 is already in > > > > bullseye-backports. > > > > > > So this want's removal from bullseye, setting the right tag to have > > > it on the radar of the SRM. > > > > obfs4proxy has a reverse-dependency in bullseye: > > > > Checking reverse dependencies... > > # Broken Depends: > > onionshare: onionshare > > > > Dependency problem found. > > This remains unresolved - obfs4proxy cannot be removed while onionshare > depends on it. Security team - is removal your recommendation? How can the > dependency be resolved? Let's add the onionshare maintainer to CC. In #1004375 onionshare demoted the dependency on obfs4proxy to a Recommends, can we apply the same to onionshare 2.2 from Bullseye? Cheers, Moritz
Bug#1033492: unblock: php8.2/8.2.4-1 ????
Am Tue, Apr 04, 2023 at 09:14:36PM +0200 schrieb Paul Gevers: > On 04-04-2023 20:07, Moritz Mühlenhoff wrote: > > If we would add the list of source packages which are following micro > releases > > in stable-security to a machine-parseable list (e.g. somewhere in the > > Security Tracker repo), would that be useful to enhance release > > management tooling (e.g. by automatically annotating unblock requests > > or similar?) > > Do you have any idea how many packages are in that set. Yes if that were > public that would help. My gut feeling is "less than 20", I'll try to compile a list in the next days. Cheers, Moritz
Bug#1033492: unblock: php8.2/8.2.4-1 ????
Am Tue, Apr 04, 2023 at 08:58:37AM +0200 schrieb Ondřej Surý: > Hi Paul, Salvatore, > > In all honesty, I thought that the pre-negotiated exception for PHP > does apply to all future Debian releases, so it did come as surprise > that I have to explain this again. Question to the release team: If we would add the list of source packages which are following micro releases in stable-security to a machine-parseable list (e.g. somewhere in the Security Tracker repo), would that be useful to enhance release management tooling (e.g. by automatically annotating unblock requests or similar?) Cheers, Moritz
Bug#1033770: bullseye-pu: package apache2/2.4.56-1~deb11u2
Am Sat, Apr 01, 2023 at 08:32:55AM +0400 schrieb Yadd: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: apac...@packages.debian.org > Control: affects -1 + src:apache2 > > [ Reason ] > apache2 silently reenable apache2-doc.conf despite having been disabled > (#1018718) If we update Apache in Bullseye, how about also adding patches for #1033408 and #1033284? Cheers, Moritz
Bug#1032885: unblock: debian-security-support/1:12+2023.03.05
Am Mon, Mar 13, 2023 at 03:07:34PM + schrieb Holger Levsen: > On Mon, Mar 13, 2023 at 03:58:45PM +0100, Moritz Mühlenhoff wrote: > > Am Mon, Mar 13, 2023 at 01:43:11PM +0100 schrieb Holger Levsen: > > > * security-support-limited: > > > - for golang and openjdk-17, point to the bookworm manual instead the > > > one > > > for bullseye. > > That's wrong, though. (And the release notes need updating to, I'll file > > a bug soonish): In Bookworm openjdk-17 is the default Java and fully > > supported, but we need the equivalent note for openjdk-21 now. > > thanks, Moritz. I'll happily update d-s-s once the release manual is updated. > or i could update d-s-s now too, if it's really just about replacing 17 with > 21 in this line from security-support-limited : > > openjdk-17See > https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#openjdk-17 Ack. I also filed #1033069 to update the release notes. > Are there any further updates expected from the security team's POV? I pushed a change to add a note on the legacy Spring classes we only use to build some packages, but with by itself are not supported to run anything. With that I think everything is covered for Bookworm I think. Cheers, Moritz
Bug#1032885: unblock: debian-security-support/1:12+2023.03.05
Am Mon, Mar 13, 2023 at 01:43:11PM +0100 schrieb Holger Levsen: > * security-support-limited: > - for golang and openjdk-17, point to the bookworm manual instead the one > for bullseye. That's wrong, though. (And the release notes need updating to, I'll file a bug soonish): In Bookworm openjdk-17 is the default Java and fully supported, but we need the equivalent note for openjdk-21 now. Cheers, Moritz
Bug#1031635: bullseye-pu: package snakeyaml/1.28-1
Am Sun, Feb 19, 2023 at 05:23:55PM +0100 schrieb Markus Koschany: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: a...@debian.org > > Hi, > > I would like to update snakeyaml in Bullseye. The package is currently > affected by various potential (no-dsa) security vulnerabilities. Those have > been fixed in Buster, Bookworm and Sid already. Please find attached > the debdiff. Could we also ship the README.Debian.security that was recently added in unstable to bullseye/buster? Cheers, Moritz
Re: Bug#1028451: 2nd DisplayPort doesn't get video
Am Mon, Jan 16, 2023 at 12:46:37PM + schrieb Didier 'OdyX' Raboud: > > I understand that would be annoying for you, but I don't think that it would > > affect the majority of our users. > > Hrm. More and more laptops come with usb-c only, and dongles/docks become more > and more common. > > It's clearly a serious regression, as such setups "just worked" with 6.0. Not moving to 6.1.x (which is most likely the next Linux kernel LTS) is by far a worse regression since it applies to every single Debian system. As a community distro without paid, full time kernel maintainers we can't just randomly stick to an older kernel tree and decide to assess/backport hundreds of patches sent to stable@ every week. Cheers, Moritz
Bug#1028452: unblock: golang-1.19/1.19.5-1
Am Thu, Jan 12, 2023 at 09:17:18PM +0100 schrieb Paul Gevers: > On 12-01-2023 16:50, Shengjing Zhu wrote: > > > But this bug report triggered me: did the golang security situation > > > already improved during this release cycle. I may be misremembering, but > > > I recall the problems on the security archive side haven't been fixed, > > > have they? > > > > For some reference, I did several security updates for golang-1.15 for > > bullseye, but we didn't rebuild other packages. These security updates > > are not urgent enough anyway. > > And others also update some Go packages for bullseye. In general, we > > just do the usual update for stable release. > > > > As for the security archive, IIRC, for bullseye, the security team did > > need to ask ftp-master to copy some individual packages manually. I'm > > not sure how it is going now. But given the low update frequency I > > overseved for bullseye, probably that works. > > Do you agree with this view for bookworm? I know you want the situation > improved, but as far as I am aware nobody (from either side) has been > pushing this forward so it feels a bit late to make this blocking. I agree with what Shengjing wrote. The situation around Go isn't great, but it's pretty much identical to what we had in past releases, so no specific concerns there. Let's simply carry over the existing entry from the release notes. The biggest blocker to fixing this on the toolchain level (like e.g. a script which programatically detects dependencies in need of rebuilds and issues binNMUs) is still the split ftp.d.o/security.d.o, which prevents binNMUs and causes a lot of churn with Built-Using whenever a Go-based program is updated. One possible solution discussed was to import all of each stable distro into security.debian.org, but that disk space demand would mean to move security-master to baremetal (it's currently a Ganeti VM). I don't think there has ever been a solution/outcome so far TTBOMK. Cheers, Moritz
Bug#1004441: unblocking chromium?
Am Sun, Jan 08, 2023 at 12:27:52AM -0500 schrieb Andres Salomon: > > On Fri, Jan 6 2023 at 11:36:02 AM +0200, Adrian Bunk > wrote: > > On Fri, Jan 06, 2023 at 10:18:16AM +0100, Moritz Muehlenhoff wrote: > > > ... > > > 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. > > > > > > Yeah, I like that idea. I think I could comfortably handle about 6 months of > dual security support (stable+oldstable), personally. Sounds good! Can you add a README.Debian.security to the next unstable uploads which briefly documents that? When bookworm has been released we can also add a note to Chromium DSAs to give folks a headsup. Cheers, Moritz
Bug#1026177: bullseye-pu: package golang-github-prometheus-exporter-toolkit/0.5.1-2
Hi Martina, > Control: affects -1 + src:golang-github-prometheus-exporter-toolkit > > [ Reason ] > This package is currently FTBFS on stable due to flaky tests. If we're doing a stable update anyway, could we also piggyback the fix https://security-tracker.debian.org/tracker/CVE-2022-46146 ? Cheers, Moritz
Bug#1025010: bullseye-pu: package jtreg6/6.1+2-1~deb11u1
Am Wed, Dec 07, 2022 at 08:27:05PM + schrieb Adam D. Barratt: > Control: tags -1 + confirmed > > On Mon, 2022-11-28 at 20:35 +0100, Moritz Muehlenhoff wrote: > > openjdk bumped the requirements for the test suite within > > their 11.x branch (which is what we ship in Bullseye), it > > now needs jtreg6. > > > > "Yay". Please go ahead. Uploaded (and hit NEW) Cheers, Moritz
Bug#1025205: bullseye-pu: package mplayer/2:1.4+ds1-1+deb11u1
Am Wed, Dec 07, 2022 at 08:31:06PM + schrieb Adam D. Barratt: > Control: tags -1 + confirmed > > On Wed, 2022-11-30 at 22:42 +0100, Moritz Muehlenhoff wrote: > > This updates fixes various minor crashes in mplayer, which > > don't warrant a DSA by itself. I've run the PoCs against > > the updated build where applicable and also tested various > > random media files. > > > > Note this isn't fixed in unstable, since mplayer FTBFSes > > with ffmpeg 5.0 and won't be in bookworm (#1005899). > > > > Please go ahead. Thanks! Upload. Cheers, Moritz
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#1004831: transition: ffmpeg
Am Tue, Jul 05, 2022 at 10:13:20AM +0200 schrieb Sebastian Ramacher: > ffmpeg has a bad history of security issues including RCEs. It requires > too many DSAs for both stable and oldstable. So I am only > going to maintain one ffmpeg version for a specific Debian release. > Anything else needs coordination with the security team. Yeah, no way we're going to have two ffmpeg branches in a stable release... Cheers, Moritz
Bug#1013755: bullseye-pu: package ganeti/3.0.2-1~deb11u1
Apollon wrote: > I would like to update Ganeti to the current upstream bugfix version > (3.0.2) - including all Debian packaging fixes currently in unstable - > and I seek your approval. > > 3.0.2 was released a while back[1] as a bugfix-only release. Due to my > involvement upstream, I had full oversight of the release process and I > can confirm it solves important issues, the vast majority of which affect > Bullseye, while it does not introduce any breaking changes in behavior. f0189ae15 is also relevant for buster->bullseye updates, since it it leads to "gnt-cluster verify" alerting about a certificate mismatch while actually everything is fine. > I'm attaching a full source debdiff against 3.0.1-2. The following > information is for ease of review, please let me know if there is any > additional information I can provide. JFTR, I've built 3.0.2-1~deb11u1 and deployed it to one of Wikimedia's Ganeti clusters yesterday and everything is working fine. Cheers, Moritz
Bug#1008168: bullseye-pu: package node-url-parse/1.5.3-1+deb11u1
Am Wed, Mar 23, 2022 at 02:25:26PM +0100 schrieb Yadd: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > > [ Reason ] > node-url-parse is vulnerable to an authorization Bypass Through > User-Controlled (CVE-2022-0686). If we're doing an update, we could also include a fix for CVE-2022-0691? Cheers, Moritz
Bug#1006215: bullseye-pu: package node-prismjs/1.23.0+dfsg-1+deb11u1
Am Mon, Feb 21, 2022 at 01:57:54PM +0100 schrieb Yadd: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > > [ Reason ] > node-prismjs has 2 vulnerabilities: > * Regex DoS (CVE-2021-40438) Where did you get that CVE reference from? CVE-2021-40438 is for a mod_proxy vulnerability in Apache httpd? Cheers, Moritz
Re: Bug#975016: #975016 - OpenJDK 17 support state for Bullseye
Am Thu, Feb 03, 2022 at 03:59:00PM +0100 schrieb Thorsten Glaser: > Hi Holger, > > > and filed against src:debian-security-support, as openjdk-17 seems to be > > supported and src:debian-security-support's purpose is to documented what's > > no, 11 is supported, 17 is just for users to run third-party > stuff on (IIUC). In Bullseye 11 is the default Java and fully covered by security support. 17 can be installed (and it can also take over the typical alternatives), but nothing pulls it in via dependencies. But if anyone needs to run an application requiring 17, this is the JRE of choice (those are rare at this point, but it will change over the life time of Bullseye). And yes there have been security updates for 17 already, but it's a best effort thing. If someone commits to rebuild the openjdk-17 uploads to unstable for bullseye-security (along with proper testing), we can also omit a note for src:debian-security-support. Cheers, Moritz
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
Mattia Rizzolo schrieb: > > --FJqzFV9NFse93u4l > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > >> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers: >> > The problem really is lack of maintenance. In my opinion, chromium dese= > rves >> > an active *team* to support it in Debian. > [..] >> > We'll not ship it in bookworm unless we see steady uploads >> > in unstable and we see security uploads in stable. > > FWIW, as the person currently sponsoring the (few) uploads thatt happen, > I also approve of this. > I had some hopes for the current "team" (m)ilbert and Michel), but > gilbert's mail even started bouncing, and Micheal became less and less > responsive :( - I understand it's a complicated package so yes, there > needs to be a real team: I also recommend you require an active (as > gilbert is not) DD in the team that actually maintains chromium (so not > me who just sponsor the uploads). Could anyone who's using Chromium on Debian please create a page on wiki.debian.org which lists the alternative options to use a current Chromium (Flatpak, ungoogled Chromium from elsewhere, snap, whatever else there is)? This would be useful to help people now looking for an alternative and we can eventually also reuse this page if we need to EOL for stable/oldstable (which we should do if the situation doesn't change in a sustainable manner by early next year). Cheers, Moritz
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers: > Hi Andres, > > On 05-12-2021 03:36, Andres Salomon wrote: > > So what's happening with chromium in both sid and stable? I saw on > > d-release that it was removed from testing (#998676 and #998732), with a > > discussion about ending security support for it in stable. I'm willing > > to help out with chromium packaging if the problem is simply lack of > > time (or I could just as easily help with something like > > ungoogled-chromium, #939406, if the plan is to have that in debian > > instead). Either way, both as a user and a developer, it is really not > > great to have chromium in limbo. :( > > The problem really is lack of maintenance. In my opinion, chromium deserves > an active *team* to support it in Debian. What we have seen over the past > years, are just (more or less) incidental uploads. Not enough for stable (we > shipped it in bullseye because we had the impression support was picked up > again, but alas). We'll not ship it in bookworm unless we see steady uploads > in unstable and we see security uploads in stable. The security team doesn't > have the bandwidth to do it themselves, they need a team to help them. 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). If it gets actively maintained again there's no real blocker to have it in bookworm, but it's a lot of work. Cheers, Moritz
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
Am Tue, Nov 30, 2021 at 06:00:57PM + schrieb Adam D. Barratt: > I was assuming the plan was for the Firefox and Thunderbird updates to > be released via the security archive. Definitely! For the last ESR round DSA deployed a change to make the security chroots include buster-proposed-updates. Not sure, if that is still the case, but we'll need the same for the bullseye chroots. This will also be needed for the openjdk-11 buster-security update after jtreg/jtharness are in buster-proposed-updates. Cheers, Moritz
Bug#991703: unblock: openjdk-11/11.0.12+7-2
Am Fri, Jul 30, 2021 at 02:41:35PM +0200 schrieb Matthias Klose: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-CC: secur...@debian.org > > Please unblock openjdk-11, the next openjdk-11 security release. And for context: openjdk-11 also follows the upstream releases within buster-security already, so moving this to testing will also fix the current situation where stable has a higher version than testing. Cheers, Moritz
Re: Apache2 policy for Bullseye
Yadd wrote: > Our current apache2 policy keeps a lot of (maybe unimportant) CVE opened > [1]. Note that this isn't really accurate: While there are CVEs listed with 2019- or 2020-, those were in fact all only recently published with the latest Apache release. > Then I'd like to see if it is possible to follow 2.4.x changes for > Bullseye (and maybe Buster). Upstream provides fully-tested versions > with no major behavior changes in 2.4.x branch [2], but with many CVE > fixes [3]. JFTR, I think this is worth a shot. TTBOMK the httpd developers avoid breaking changes within 2.4.x and with the many different modules around, the test coverage around their maintenance releases is certainly higher than what we can realistically cover with testing for isolated backports. Cheers, Moritz
Re: Bug#987504: imagemagick: attempt to perform an operation not allowed by the security policy `EPS'
Am Wed, May 19, 2021 at 08:49:01PM +0200 schrieb Paul Gevers: > Hi, > > First off, thanks Adrian for raising the concern. In general, at this > stage we don't like packages breaking other packages. This should have been fixed in unstable for a long time, I pinged the maintainer multiple times even. imagemagick badly needs co-maintainers, the current state is not sustainable at all. imagemagick only saw one maintainer upload in 2020... > If I understand correctly, not having this patch in bullseye can be > considered a security regression. Yes, we should not revert this and rather fix fallout in the handful of affected packages. This patch e.g. prevented the exploitability of https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html and will prevent other issues in the future. Cheers, Moritz
Bug#988746: RM: jodd/3.8.6-1.1
Am Wed, May 19, 2021 at 08:47:24PM +0200 schrieb Sebastian Ramacher: > On 2021-05-18 23:38:58 +0200, Moritz Muehlenhoff wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: rm > > X-Debbugs-Cc: ebo...@apache.org > > > > Please remove jodd from bullseye, it has open security issues and > > there are currently no rdeps (it was uploaded for jmeter 3, which > > didn't enter the archive yet). Acked by Emmanuel in #961298. > > Removal hint added. Could you please file an RC bug against so that it > doesn't re-enter bookworm until it's ready? Thanks. I've bumped the severity of 961298 to RC to prevent it from re-entering. Cheers, Moritz
Re: Tentative summary of the AMD/ATI/NVidia issue
Du schriebst in gmane.linux.debian.devel.release: > Lucas Nussbaum writes: >> It looks like the three open paths for resolution are: >> >> A) understand and restore the behaviour from Debian 10, that is, get X >> to work in a degraded mode after installation. How it worked with Debian >> 10 (and why it doesn't with Debian 11) is unknown. >> >> B) In the installer, detect that firmware-amd-graphics or >> firmware-misc-nonfree should be installed, and either install it (?), >> or redirect the user to the unofficial installer that includes them. >> >> C) Do nothing and document this in the release notes > > There is at least also > > D) Install (non-free) firmware and include it in official install media. > > I don't think degraded operation (just vesa, no sound, no wifi, known > issues in microcode, ...) will continue to be an attractive option. > So maybe we should revisit whether we should just include firmware; I > wanted to suggest so at least for Bookworm. +100 Let's postpone the tentative release date and use the time to create a separate non-free/firmware section which contains the various firmwares and amd64-microcode/intel-microcode and which gets included in our default installation media. There can still be special images for use in virtualisation, containers and special hardware for those who care, but let's end this fallacy. If the involved teams (FTP masters, d-i, debian-cd) feel they need some educated opinion from the rest of the project, then by all means let's settle this with a GR, but A-C are just wasted efforts or provide a horrible user experience for no benefit at all. Cheers, Moritz
Bug#987299: unblock: gstreamer1.0/1.18.4-1
Am Wed, Apr 21, 2021 at 09:31:12AM +0300 schrieb Sebastian Dröge: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package gstreamer1.0 > > In addition to various more minor bugs, this release also fixes CVE-2021-3497 > and CVE-2021-3498 as well as other potentially security-relevant issues that > didn't get their own CVE. JFTR, there was an earlier discussion about CVE-2021-3497/CVE-2021-3498 with Sebastian and given the way gstreamer release branches are handled we suggested to ask for an unblock of 1.18.4 (it's fundamentally quite similar to ffmpeg or vlc where we're also following release branches). Cheers, Moritz
Bug#983531: buster-pu: package python2.7/2.7.16-2+deb10u2
Am Sat, Mar 13, 2021 at 06:46:38PM + schrieb Adam D. Barratt: > On Fri, 2021-02-26 at 16:30 +0100, Moritz Muehlenhoff wrote: > > On Fri, Feb 26, 2021 at 07:49:38AM +0100, Matthias Klose wrote: > > > On 2/25/21 7:41 PM, Moritz Muehlenhoff wrote: > > > > + * CVE-2021-3177 > > > > > > are all the ctypes tests passing with this patch? See #983516. > > > > I'll have a look at Marc' updated patch and revise if needed. > > Was there a conclusion on that? I won't have time for preparing/testing a revised update, this will need to wait for 10.10 Cheers, Moritz
Bug#983134: buster-pu: package python3.7/3.7.3-2+deb10u3
Am Sat, Mar 13, 2021 at 05:29:30PM + schrieb Adam D. Barratt: > Control: tags -1 + confirmed > > On Fri, 2021-02-19 at 22:32 +0100, Moritz Muehlenhoff wrote: > > +python3.7 (3.7.3-2+deb10u3) buster; urgency=medium > > + > > + * CVE-2020-26116 > > + * CVE-2021-3177 > > > > Please go ahead. Uploaded. Cheers, Moritz
Bug#981664: buster-pu: package privoxy/3.0.28-2
Am Tue, Feb 02, 2021 at 07:15:37PM +0100 schrieb Roland Rosenfeld: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > This fixes CVE-2021-20216 and CVE-2021-20217. > Since both are tagged " (Minor issue)" in security tracker, I > tend to send this into the next point release of buster. Hi Roland, yesterday upstream assigned a few additional CVE IDs (also no-dsa): https://www.openwall.com/lists/oss-security/2021/02/03/3, maybe you also want to fold these in? Cheers, Moritz
Re: Bug#975016: OpenJDK 15 support state for Bullseye
Am Tue, Jan 26, 2021 at 04:36:13PM +0100 schrieb Matthias Klose: > On 12/2/20 5:42 PM, Holger Levsen wrote: > > On Fri, Nov 20, 2020 at 08:40:22AM +, Holger Levsen wrote: > >>> Thanks for the upload. > >> :) note however that "#975016: OpenJDK 15 support state for Bullseye" is > >> still > >> open... > > > > ping, has there been any progress on this? > > chatting with Moritz from the security team, we found four options: > > 1) Ship a snapshot of OpenJDK 17 in bullseye. The package is >marked as a snapshot build. Mention in debian-security-support >and the Release Notes, that the package is unsupported. The >package should be updated to the final OpenJDK 17 release via >debian-security (final release is expected in October 2021). >I volunteer to do that, I also volunteer to prepare follow-up >updates, but unlikely for every security update which is >expected every three months. > > 2) Like option 1), but find somebody committing to constant security >updates. Mentioning in debian-security-support and the Release >Notes is not needed. > > 3) Provide OpenJDK 17 in the same archive area as planned for all >the go dependencies. I don't know what would be involved with >that. > > 4) Provide OpenJDK 17 in bullseye-backports only. I don't know >how it can land there. The backports section also might not be >enabled for everybody. Ack, ideally we can come up with someone committing to 2), but those are all workable options. Cheers, Moritz
Bug#976811: transition: php8.0
Am Fri, Jan 15, 2021 at 07:58:10PM +0100 schrieb Ondřej Surý: > Thinking about it, security-wise it might be better. Microsoft will support > the security backports to EOL versions of PHP 7.x, but they announced they > won’t do it for PHP 8.x, so we are (maybe) bit more covered with PHP 7.4. Even better :-) Cheers, Moritz
Bug#976811: transition: php8.0
Am Thu, Jan 14, 2021 at 10:28:41AM +0100 schrieb Sebastian Ramacher: > I'm also CCing the security team for their input in case the have a > strong opinion on this transition. It's fine. PHP 8 would have been great, but it is what it is. Cheers, Moritz
Bug#974695: buster-pu: package libxml2/2.9.4+dfsg1-7+deb10u1
On Thu, Nov 19, 2020 at 08:39:55PM +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Fri, 2020-11-13 at 22:33 +0100, Moritz Muehlenhoff wrote: > > This fixes a few low severity security fixes affecting libxml2, > > I've tested the package on a buster system with a few rdeps. > > > > Please go ahead. Uploaded, thanks. Cheers, Moritz
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On Wed, Nov 18, 2020 at 10:31:30PM +0100, Thorsten Glaser wrote: > I think nobody wants to switch default-jdk to 17 or even not ship > 11 at all any more or stop supporting it during bullseye’s lifetime. > Maybe that also was too implicit? Exactly, the supported Java release for the entire Bullseye lifetime will be 11 (which packages will build-depend on and what's provided by default-jdk. The idea is to include 15/16 so that later on when 17 is ready, 17 can be made available in addition via backports (since at some point later in the bullseye lifecycle might be software one wants to run which requires 17 as the next LTS. Cheers, Moritz
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On Sun, Nov 08, 2020 at 12:36:50PM +0200, Adrian Bunk wrote:
> On Fri, Jul 10, 2020 at 06:13:58PM +0100, Ben Hutchings wrote:
> > I don't know if this should be a blocker, but the MIPS builders are
> > still extremely slow for kernel builds. In the worst case (mipsel:
> > mipsel-aql-{01,02}) it takes about 41 hours, which is 3 times longer
> > than the next slowest group of builders (armhf: hasse, henze, holby).
> > This can be a problem for getting security updates out promptly.
>
> 12:32 < aurel32> starting now, eberlin, mipsel-aql-01 and mipsel-aql-02
> do not build security anymore
>
> (The 7 faster buildds continue to build security.)
Thanks Aurelien, this is really nice and will be quite helpful for big packages.
Cheers,
Moritz
Bug#972183: buster-pu: package libjpeg-turbo/1:1.5.2-2+deb10u1
On Sat, Oct 24, 2020 at 07:44:12PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Tue, 2020-10-13 at 22:39 +0200, Moritz Muehlenhoff wrote: > > This fixes a number of security issues in libjpeg, > > which don't warrant a DSA. Package has been tested on > > a buster system. > > Please go ahead. Thanks, uploaded. Cheers, Moritz
Re: Updating Mozilla plugins in stable (was: Re: Bug#971807: buster-pu: package webext-tbsync)
Adam D. Barratt schrieb: > There's a school of thought which says that it doesn't make sense to > include the plugins in the Debian archive at all, and we should instead > suggest that users install and update plugins from the upstream > repositories directly. The TB 68->78 is a little special as it drops old addon interfaces, now with only web extensions being supported it should be much better. AFAICT the packaged web extensions for Firefox all continue to work with 78 compared to 68. Cheers, Moritz
Bug#972183: buster-pu: package libjpeg-turbo/1:1.5.2-2+deb10u1
On Tue, Oct 13, 2020 at 08:57:14PM +, Mike Gabriel wrote: > Hi Moritz, > > On Di 13 Okt 2020 22:39:53 CEST, Moritz Muehlenhoff wrote: > > > Package: release.debian.org > > Severity: normal > > Tags: buster > > User: release.debian@packages.debian.org > > Usertags: pu > > X-Debbugs-Cc: ond...@debian.org, sunwea...@debian.org > > > > This fixes a number of security issues in libjpeg, > > which don't warrant a DSA. Package has been tested on > > a buster system. > > > > Cheers, > > Moritz > > Will you do the upload onced ACK'ed by the RT (I guess ACK'ing pre-upload is > not required for the .debdiff you prepared)? Or have you already uploaded > that version (I am currently on VAC and not following all mail channels...)? > Or shall I upload? I'm fine either way. Given that I have a package ready (which I used on for my tests), better enjoy your vacation and I'll upload once acked by SRMs. Ack? Cheers, Moritz
Bug#971866: buster-pu: package okular/4:17.12.2-2.2+deb10u1
On Sun, Oct 11, 2020 at 03:29:22PM +0100, Adam D. Barratt wrote: > On Sat, 2020-10-10 at 13:42 +0200, Moritz Mühlenhoff wrote: > > On Sat, Oct 10, 2020 at 09:40:05AM +0100, Adam D. Barratt wrote: > > > Control: tags -1 + confirmed > > > > > > On Thu, 2020-10-08 at 21:15 +0200, Moritz Muehlenhoff wrote: > > > > Low severity fix for Okular, which doesn't warrant a DSA. > > > > I've tested with the reproducerand a number of other PDF > > > > files that everything works as expected. > > > > > > > > > > Please go ahead. > > > > Uploaded. > > It looks like that didn't work out. The queued log has: > > Oct 11 11:54:35 Deleted stray file > /okular-dbgsym_17.12.2-2.2+deb10u1_amd64.deb > Oct 11 11:54:35 Deleted stray file > /libokular5core8-dbgsym_17.12.2-2.2+deb10u1_amd64.deb > Oct 11 11:54:35 Deleted stray file > /libokular5core8_17.12.2-2.2+deb10u1_amd64.deb > Oct 11 11:54:35 Deleted stray file /okular_17.12.2-2.2+deb10u1.dsc > Oct 11 11:54:35 Deleted stray file /okular_17.12.2-2.2+deb10u1.debian.tar.xz Meh, should be fixed now. Cheers, Moritz
Bug#971866: buster-pu: package okular/4:17.12.2-2.2+deb10u1
On Sat, Oct 10, 2020 at 09:40:05AM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2020-10-08 at 21:15 +0200, Moritz Muehlenhoff wrote: > > Low severity fix for Okular, which doesn't warrant a DSA. > > I've tested with the reproducerand a number of other PDF > > files that everything works as expected. > > > > Please go ahead. Uploaded. Cheers, Moritz
Bug#971915: buster-pu: package transmission/2.94-2+deb10u2
On Sat, Oct 10, 2020 at 09:44:31AM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Fri, 2020-10-09 at 19:40 +0200, Moritz Muehlenhoff wrote: > > Fixes a memory leak when running Transmission in daemon mode. > > > > [ Tests ] > > Have been using the package since a few weeks and the user > > who reported the leak (running an affected setup) confirmed > > that it fixes the leak. > > Please go ahead. Uploaded. Cheers, Moritz
Bug#971869: buster-pu: package freecol/0.11.6+dfsg2-2+deb10u1
On Sat, Oct 10, 2020 at 09:41:38AM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2020-10-08 at 21:20 +0200, Moritz Muehlenhoff wrote: > > Low severity bugfix for freecol, which doesn't warrant a DSA. > > > > The (identical) patch has been in unstable for half a year, also > > doublechecked by playing for half an hour :-) > > Please go ahead. Uploaded. Cheers, Moritz
Bug#970584: buster-pu: package inetutils/2:1.9.4-7+deb10u1
On Sat, Sep 19, 2020 at 06:17:20PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2020-09-19 at 13:33 +0200, Moritz Muehlenhoff wrote: > > Fix for CVE-2020-10188, which doesn' really warrant a DSA. > > > > Please go ahead. Thanks, uploaded. Cheers, Moritz
Bug#970583: buster-pu: package chocolate-doom/3.0.0-4+deb10u1
On Sat, Sep 19, 2020 at 06:15:22PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2020-09-19 at 13:31 +0200, Moritz Muehlenhoff wrote: > > Fix for CVE-2020-14983, which doesn't really warrant a DSA. > > Please go ahead. Thanks, uploaded. Cheers, Moritz
Re: Go issues wrt. Debian infrastructure: moving forward
On Sat, Aug 29, 2020 at 10:18:57PM +0200, Clément Hermann wrote: > Hi, > > On 29/08/2020 20:09, Ansgar wrote: > > Hi, > > > > Clément Hermann writes: > >> The original message on debian-go and debian-release is here: > >> > >> https://lists.debian.org/msgid-search/176455fa-4611-f2c1-9ca1-f855d7d99...@debian.org > > > > For the ftp-master side, I wanted to just import all sources from a > > stable release into security-master (in a private archive). dak can > > then use these when binNMUs arrive, for Built-Using, or when people > > upload without the .orig.tar.gz included. The second part should > > already work. > > > > There are currently two issues with this: > > > > - security-master.d.o should get more disk space. > > Maybe we should get a (new) physical host for security-master that > > provides this? It should probably be a physical host and not a VM to > > allow using a YubiKey (or similar) for the signing key. > > Is there a way one can help on this? Maybe open a ticket with DSA to discuss options for extending disk space with or without a physical machine? > Other than that, I don't think there are, my understanding was that the > missing orig.tar.gz when dealing with a lot of new packages in the > security archive was the main blocker on ftp-master plate. I think so, too. That should resolve the tooling issues and only leave the implementation of how to detect what needs to be rebuilt. Cheers, Moritz
Re: Go issues wrt. Debian infrastructure: moving forward
On Thu, Aug 27, 2020 at 07:16:19PM +0200, Clément Hermann wrote: > I'm fine with IRC too. I think the dak implementation would be the best > (along with a script or something that can tell which packages to > binNMU, but with the proper field set d/control for binaries that > doesn't sound difficult). > > What I'd hope to get from such a session would be possible, acceptable > workaround if the dak issue is (as it seems) too complicated to fix in a > timely manner. I think only FTP masters have the necessary insight to answer that. The important thing is that in end binNMUs are made, a script which in the end performs sourceful uploads would cause too much churn. > For instance, a script that would get all the needed source package and > upload then whenever someone needs to binNMU a go package. Or whatever > makes security@d.o and release management life easier. Ideally we'd have a script which accepts a source package name as a parameter and the distro to target (like buster or unstable). The output should be a list of wanna build commands, like wb nmu $SOURCEPKG . ANY . $DISTRO . - "Rebuild for $REASON" I think there might be staggered build steps. Like when liba gets binNMUd and then libb (which uses liba) needs the same. So ideally the order of wb commands emitted should reflect that. With that setup in place, supporting Go and Rust updates in stable (and the same tool will also be useful in unstable!) should be fine. Shared libs would ofc be preferable, but withful thinking doesn't help us either :-) 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#959723: RM: matrix-synapse/0.99.2-6 -- ROM; security issues; obsolete version
On Wed, May 06, 2020 at 11:22:42PM +0200, Moritz Mühlenhoff wrote: > On Mon, May 04, 2020 at 11:04:21PM +0200, Andrej Shadura wrote: > > On Mon, May 04, 2020 at 06:33:26PM +0200, Julien Cristau wrote: > > > > I think in this case it’s okay because of this NEWS entry: > > > > > > > > https://sources.debian.org/src/matrix-synapse/0.99.2-6/debian/NEWS/ > > > > > I'm not sure how that makes it any better? NEWS is shown on upgrade at > > > best, so anyone installing this on buster won't see it. > > > > True; I haven’t thought about people who never had synapse installed > > before. In any case, I think anyone installing this on buster does > > follow the news about Matrix and probably tried to figure out how to > > upgrade. > > Notifying users about an EOL package is handled by debian-security-support, > simply file a bug against it and the next time it lands in stable, people > will be notified who have it installed. > > I'm all in favour of removing it by 10.4 or 10.5, depending on whether > the timing still allows for 10.4. Let's remove it for the upcoming 10.5 update, then? Cheers, Moritz
Bug#961270: RM: pdns-recursor/4.0.4-1+deb9u4
On Fri, May 22, 2020 at 10:36:51AM +, Holger Levsen wrote: > FYI, > > debian-security-support (2020.05.22) unstable; urgency=medium > . >* Add pdns-recursor to security-support-ended.deb9 as explained in > DSA-4691-1. Thanks for this. Cheers, Moritz
Bug#959723: RM: matrix-synapse/0.99.2-6 -- ROM; security issues; obsolete version
On Mon, May 04, 2020 at 11:04:21PM +0200, Andrej Shadura wrote: > On Mon, May 04, 2020 at 06:33:26PM +0200, Julien Cristau wrote: > > > I think in this case it’s okay because of this NEWS entry: > > > > > > https://sources.debian.org/src/matrix-synapse/0.99.2-6/debian/NEWS/ > > > I'm not sure how that makes it any better? NEWS is shown on upgrade at > > best, so anyone installing this on buster won't see it. > > True; I haven’t thought about people who never had synapse installed > before. In any case, I think anyone installing this on buster does > follow the news about Matrix and probably tried to figure out how to > upgrade. Notifying users about an EOL package is handled by debian-security-support, simply file a bug against it and the next time it lands in stable, people will be notified who have it installed. I'm all in favour of removing it by 10.4 or 10.5, depending on whether the timing still allows for 10.4. Cheers, Moritz
Re: on updating debian-security-support in stable and oldstable (due to DSA-4562-1)
On Thu, Jan 30, 2020 at 10:41:56PM +, Holger Levsen wrote: > On Thu, Jan 30, 2020 at 07:41:32PM +, Holger Levsen wrote: > > I'll upload 2019.12.12~deb9u2 then which is lower than what's in > > buster-pu currently and will be in buster soon. (2019.12.12~deb10u1) > > uploaded now. > > (once this is accepted I'll upload to jessie-security and be done.) I've just installed the stretch packages into the archive. Cheers, Moritz
Bug#949826: buster-pu: package haproxy/1.8.19-1
On Sat, Jan 25, 2020 at 02:39:04PM +0100, Vincent Bernat wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hey! > > The logrotate configuration file for HAProxy doesn't signal rsyslog > correctly. Therefore, logs are not really rotated and on a moderately > busy site, this can fill up a log partition. When running with > systemd, rsyslog doesn't write a PID file and there fore, the SysV > init script invoked to rotate logs does not work. Instead, rsyslog > package provides an helper for this purpose. > > The change has been applied to 2.0.12-1 currently in unstable and > testing. I would like to push it for the next point release next week. If we're doing a Buster update anyway, could we also piggyback the fix for https://nathandavison.com/blog/haproxy-http-request-smuggling (CVE-2019-18277), https://git.haproxy.org/?p=haproxy-2.0.git;a=commit;h=196a7df44d8129d1adc795da020b722614d6a581 ? Cheers, Moritz
Bug#949541: buster-pu: package mesa/18.3.6-2+deb10u1
On Sat, Jan 25, 2020 at 07:29:20PM +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Tue, 2020-01-21 at 21:09 +0100, Moritz Muehlenhoff wrote: > > Attached debdiff fixes a minor security issue in mesa. I've been > > running the updated packaged on a Buster workstation over the last > > days. > > > > Please go ahead. Thanks, uploaded. Cheers, Moritz
Bug#945845: buster-pu: package qtwebengine-opensource-src/5.11.3+dfsg-2+deb10u1
On Tue, Dec 03, 2019 at 11:30:44AM +0300, Dmitry Shachnev wrote: > Dear Release team, > > On Fri, Nov 29, 2019 at 11:10:16PM +0300, Dmitry Shachnev wrote: > > This update fixes bug #919504 that is also known as #929286, #931860, > > #933278 and #945147. > > > > The debdiff is attached. Please see the header of the added patch for the > > description of the fix. FWIW, I ran into a Buster system with the broken print (preview) in Kmail and can confirm that a build with the proposed patches fixes this issue for good. Cheers, Moritz
Bug#947676: RM: qt4-x11/4:4.8.7+dfsg-19
On Sun, Dec 29, 2019 at 12:17:11PM +0100, Paul Gevers wrote: > Hi Lisandro, Moritz, > > On 29-12-2019 11:26, Moritz Mühlenhoff wrote: > >> Hi! As you know we are doing an effort to remove qt4-x11 from the archive. > >> The > >> next big step is removing it from testing. > >> > >> If my data is accurate the only package holding qt4-x11 in testing is scim, > >> which I have just NMUed. > >> > >> So: > >> > >> - Is there any other blocker I might be missing? > > > > scim is in fact the only remaining blocker, from a "dak rm -Rn qt4-x11 -s > > testing": > > > > | Checking reverse dependencies... > > | # Broken Depends: > > | scim: scim-qt-immodule > > | > > | # Broken Build-Depends: > > | scim: libqt4-dev > > > > AFAICT it will need an explicit removal hint as it's a key package. > > In general we prefer to sync removals from unstable. Is there any reason > why this package can't be removed from unstable first? (If it can be > done via unstable, please reassign this bug to ftp.debian.org and the > removal can happen automatically in testing). It's not that simple for a core lib like Qt (the process was similar for the OpenSSl 1.0 removal e.g.), there's about 20 rdeps left which were auto-removed from testing, but are still in unstable. Cleaning those out will take a few more months, but it would be good to make a clean cut for bullseye beforehand. Cheers, Moritz
Bug#947676: RM: qt4-x11/4:4.8.7+dfsg-19
On Sat, Dec 28, 2019 at 08:59:45PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > Hi! As you know we are doing an effort to remove qt4-x11 from the archive. The > next big step is removing it from testing. > > If my data is accurate the only package holding qt4-x11 in testing is scim, > which I have just NMUed. > > So: > > - Is there any other blocker I might be missing? scim is in fact the only remaining blocker, from a "dak rm -Rn qt4-x11 -s testing": | Checking reverse dependencies... | # Broken Depends: | scim: scim-qt-immodule | | # Broken Build-Depends: | scim: libqt4-dev AFAICT it will need an explicit removal hint as it's a key package. Cheers, Moritz
Re: Request: removal of package lilo from testing
Joachim Wiedorn schrieb: >> Your approach above will be good for users of unstable and testing, but >> how does this help users of stable, when they upgrade from buster to >> bullseye after the release of the latter? Just by writing this in the >> release notes? Is that the best we can do? > > That's right, it doesn't help users of stable and oldstable, if they make > an upgrade.=20 > > But then the only solution is making a transitional package "lilo" which > have dependency to grub2, which will install grub2 and remove the binaries > of lilo. This can entail many risks. Because of many different system > structures it could be, that at the end there is no functioning booting on > this system ...=20 I doubt that's really needed? Anyone who willingly installed lilo over the default in the last decade (or longer) made a very specific expert choice, simply mentioning that in the release notes should be totally fine. Cheers, Moritz
Re: Should qpdf depend on gnutls?
On Sat, Nov 09, 2019 at 07:10:44PM -0500, Jay Berkenbilt wrote: > I am the upstream author and the debian maintainer of qpdf. > > At the request of RedHat, I have made an enhancement to qpdf that > allows an external library to be used for crypto functions rather than > using qpdf's native crypto implementations. The qpdf library includes > code to compute hashes with md5 and sha2 (256, 384, and 512) as well > as encryption functions for rc4 and aes256 with and without CBC. > Disabling insecure crypto is not a practical option because of the way > these things are used in the PDF spec, but it is possible create PDFs > that don't use insecure crypto by just using 256-bit encryption. > > I can build qpdf 9.1 for Debian in one of three ways: 1) use only the > native crypto as in all previous releases, thus avoiding a dependency > on gnutls; 2) build only the gnutls crypto provider thus causing a > dependency on gnutls but eliminating the native crypto entirely; or 3) > building both crypto providers, in which case gnutls will be used by > default, but developers and end users will have the ability to select > the native crypto provider at runtime if desired. > > Do you have an opinion about which way I should go? I believe RHEL and > Fedora are going to use the second option of building with only gnutls > and dropping native crypto, but I have also enjoyed the fact that qpdf > has so few build dependencies. It is possible that a future version of > qpdf may support digital signature, in which case I will definitely > have to add either openssl or gnutls as a dependency. I'd recommend to go with 2); there's a lot of value in using a common / scrutinised crypto library over a custom implementation and for all practical purposes gnutls would not be an additional dep as systemd already pulls it in on virtually every Linux system these days. Cheers, Moritz
Bug#943846: buster-pu: package python-cryptography/2.6.1-3+deb10u2
On Fri, Nov 08, 2019 at 10:09:07PM +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2019-10-30 at 16:44 +0100, Moritz Muehlenhoff wrote: > > (This is a followup update on top of the +deb10u1 already in s-p-u, > > I've reached out to Tristan beforehand) > > > > Attached debdiff fixes a memory leak in python-cryptography, which > > was noticed in an ACME-related service ( > > https://wikitech.wikimedia.org/wiki/Acme-chief) > > running on Buster. It has been verified that the updated packages > > fix the memory leak (and are otherwise working fine as well). > > > > Please go ahead. Uploaded. Cheers, Moritz
Bug#942793: RM: trafficserver/7.0.0-6+deb9u2
On Mon, Oct 21, 2019 at 04:36:23PM +0200, Jean Baptiste Favre wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear release managers, > Please remove trafficserver from Stretch next point release. > This version hass been EOL upstream for 2 years now, and security patches > backport > became to much invasive to be efficient. > I prefer this version to be removed from old-stable releases. JFTR, we already added a note to DSA-4520-1 which advises to upgrade to Buster if HTTP/2 is used, so +1 from me. Cheers, Moritz
Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)
On Fri, Aug 30, 2019 at 09:17:32AM +0200, Raphael Hertzog wrote: > Hi, > > On Fri, 30 Aug 2019, Pirate Praveen wrote: > > Fast Track repo works exactly like current backports except the packages > > are added from unstable (or experimental during transitions and freeze) > > as they cannot go to testing and hence to current backports. > > > > As Paul noted earlier, backports team is not interested to change > > current backports criteria. > > Can you point us the discussion where this got refused? > > Honestly I don't like the idea of using an external service. Let's just see how it works out? backports also started as an external service and was eventually moved under debian.org infrastructure. Cheers, Moritz
Bug#935746: buster-pu: package nss/2:3.42.1-1+deb10u1
On Mon, Aug 26, 2019 at 06:04:55PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sun, 2019-08-25 at 21:25 +0200, Moritz Muehlenhoff wrote: > > The NSS update below fixes a few non-severe security issues. I've > > been running this version with Firefox on Buster (which uses the > > system copy of NSS unlike Firefox in Stretch) without any issues. > [...] > > + * Fixes for CVE-2019-11719, CVE-2019-11727 and CVE-2019-11729 (in > > unstable > > +these were addressed via the 2:3.45-1 upload to unstable) > > > > FWIW that stanza mentions unstable twice in the parentheses. > > Please go ahead. Thanks, uploaded. Cheers, Moritz
Bug#935600: RM: valkyrie/2.0.0-1
reassign 935600 ftp.debian.org retitle 935600 RM: valkyrie - depends on qt4, dead upstream thanks On Sat, Aug 24, 2019 at 02:40:31PM +0200, László Böszörményi (GCS) wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > Please remove src:valkirye from Sid. Its upstream is dead for years. > It's not compatible with Qt5 and Qt4 is being removed. This needs to be against ftp.debian.org, reassigning. Cheers, Moritz
Bug#935460: stretch-pu: package sox/14.4.1-5+deb9u2
On Thu, Aug 22, 2019 at 10:07:51PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2019-08-22 at 22:56 +0200, Moritz Muehlenhoff wrote: > > Attached debdiff fixes a number of bugs in sox. These have been in > > jessie for a while already (Stretch and Jessie have the same base > > version as the package was unmaintained for a while) and I've ran > > some of the POCs on > > the Stretch build. Debdiff below. > > > > Please go ahead. Thanks, uploaded. Cheers, Moritz
Bug#934206: buster-pu: package golang-github-docker-docker-credential-helpers/0.6.1-2+deb10u1
On Thu, Aug 08, 2019 at 09:53:16AM +0100, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On 2019-08-08 08:47, Arnaud Rebillout wrote: > > Package: release.debian.org > > Severity: normal > > Tags: buster > > User: release.debian@packages.debian.org > > Usertags: pu > > > > The debdiff attached brings in an upstream patch to fix > > CVE-2019-1020014, hence closes #933801. > > > > This is my first contribution to Debian Stable, please check for > > beginners mistake ;) > > > > Also, the devel-announce "Bits from the Stable Release Managers" > > mentions: > > > >* Fixes for security issues should be co-ordinated with the > > Security Team, unless they have explicitly stated that they > > will not issue an DSA for the bug (e.g. via a "no-dsa" marker > > in the Security Tracker) [SECURITY-TRACKER] > > > > So, is there anything else I should do here? Like, CC them or something? > > Yes, *before* filing this bug, as if the Security Team want to handle it > then this bug shouldn't exist to begin with. > > I've CCed them now, let's see what they say. It's harmless, stable-proposed-updates sounds good. I'll mark it as no-dsa in the security tracker. Cheers, Moritz
Bug#929257: stretch-pu: package mariadb-10.1 10.1.41-0+deb9u
On Fri, Aug 02, 2019 at 10:42:37PM +0100, Otto Kekäläinen wrote: > (sorry for replying to wrong bug report earlier) > > Hello! > > I have now prepared 10.1.41 for upload to Stretch. I am CC'ing > security team in case you want this faster in than waiting for the > next stable update (planned for 2019-09-07). Ack, next point release sounds fine here. Cheers, Moritz
Bug#933754: buster-pu: package mariadb-10.3 10.3.17-0+deb9u1
On Fri, Aug 02, 2019 at 10:48:53PM +0100, Otto Kekäläinen wrote: > Package: release.debian.org > Severity: normal > Tags: buster, moreinfo > User: release.debian@packages.debian.org > Usertags: pu > > MariaDB 10.3.17 includes security fixes and a few bug fixes > appropriate for a stable release. > > This bug report is intentionally void of the debdiff as I might still > amend something, or the severity of the security issues might change > on further investigation. > > See buster branch at https://salsa.debian.org/mariadb-team/mariadb-10.3/ > > > Changelog: > > mariadb-10.3 (1:10.3.17-0+deb9u1) buster; urgency=high Should rather be +deb10u1, Buster is the tenth stable release. Cheers, Moritz
Bug#932175: stretch-pu: package openssh/1:7.4p1-10+deb9u7
On Sat, Jul 27, 2019 at 12:34:38PM +0200, Cyril Brulebois wrote: > Adam D. Barratt (2019-07-26): > > On 2019-07-16 06:36, Moritz Muehlenhoff wrote: > > > This update for OpenSSH fixes a dead lock in AuthorizedKeysCommand > > > (#905226). > > > > > > The fixed package is running fine on a formerly affected Stretch system > > > (https://phabricator.wikimedia.org) > > > > This looks OK to me, but will need a d-i ack due to the udeb; tagging and > > CCing accordingly. > > No objections, thanks. Uploaded. Cheers, Moritz
Bug#931245: unblock: encoding-rs/0.8.15-2
On Sat, Jun 29, 2019 at 09:22:54AM +0200, Sylvestre Ledru wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package encoding-rs > > Last minute, we had to update rustc to facilitate the packaging > of Firefox ESR 68. > However, this new version of rustc, platform intrinsics crate aren't > supported anymore: > https://github.com/rust-lang/rust/pull/57416 > > This broke the rust-simd package. > This encoding-rs version is removing the dep. > > The patch is big because most of it is generated code. > However, I am not worried because: > * the rust programming language is doing a huge number of checks at > compilation time. > * ripgrep (the main program using encoding-rs) testsuite executes > without any issue. > > unblock encoding-rs/0.8.15-2 Given this didn't make it in time, can you fix this through the 10.1 point release? Cheers, Moritz
Bug#930687: unblock: rdesktop/1.8.6-2
On Tue, Jun 18, 2019 at 06:19:33PM +0200, László Böszörményi (GCS) wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hi Release Team, > > There's several security issues fixed with rdesktop 1.8.6 and while it > has some regressions, I've backported the needed fixes for the -2 > package version. > As upstream notes: "This is a security release to address various > buffer overflow and overrun issues in the rdesktop protocol handling. > rdesktop will now detect any attempts to access invalid areas and > refuse to continue. Users are adviced to upgrade as soon as possible." > > The debdiff is a bit large, but hopefully can be accepted for Buster. JFTR, we'll likely also rebase stretch to that version (we did similarly for 1.8.4 in a previous DSA). Cheers, Moritz
Bug#928185: unblock: openjdk-11/11.0.3+7-4
On Mon, Jun 10, 2019 at 09:46:41PM -0700, tony mancill wrote: > I am not a member of the OpenJDK team and contributed far less to the > JDK 8 -> 11 transition than Emmanuel has. If he and Matthias are in > agreement and the plan is palatable to the Release and Security Teams, > that's ideal. I don't have any preference either, just adding my 2 cents here; with our buster release set to 6th of July and the next Oracle CPU set for July 16, we'll ship a non-GA release of Java for maybe two, at most three weeks (as buster-security will rebase to the next openjdk-11 following the CPU). I'm also fairly sure we've shipped non-GA releases for openjdk-8 before? In any case, whether we go with t-p-u or unblocking the sid version, we should fix a solution before the release and not ship buster with the unfixed issues from the April CPU :-) Cheers, Moritz
Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
On Tue, Jun 04, 2019 at 09:27:55PM +0200, Paul Gevers wrote: > Hi Michael, Jonathan, > > On Tue, 4 Jun 2019 14:11:23 +0100 Jonathan Wiltshire wrote: > > On Mon, May 27, 2019 at 08:23:09AM +0300, Michael Tokarev wrote: > > > I've prepared next release of the qemu debian package, with > > > a few bugfixes, and am asking if it's okay to upload these > > > changes to unstable (targetting buster). The change includes > > > 3 security fixes which should go anyway, and 2 "other" fixes > > > which are questionable, hence the pre-approval bugreport/question. > > > > Unblocked; thanks. > > qemus migration is blocked by gcc-8, which nobody unblocked so far, so > that is probably not going to happen. I think this should be fixed via tpu. There's an existing unblock request for gcc-8 at #928188 Cheers, Moritz
Re: CVE-2019-3902
On Sun, Apr 21, 2019 at 12:32:13AM +0200, Moritz Muehlenhoff wrote: > Source: mercurial > Version: 4.8.2-1 > Severity: grave > Tags: security > > See https://www.mercurial-scm.org/wiki/WhatsNew from 4.9: > > This was assigned CVE-2019-3902: > It was possible to use symlinks and subrepositories to defeat Mercurial's > path-checking > logic and write files outside a repository. This has been fixed. Users on > older versions > can either disable subrepositories with [subrepos] allowed=false in their > configuration > or by ensuring any cloned repositories don't contain malicious symlinks. > > This is fixed in sid, but buster still has 4.8.2. A month later this is still unfixed in buster. Does anyone care about having this in a stable release? Probably not, because noone cared about stretch already either: https://security-tracker.debian.org/tracker/source-package/mercurial If that's the case, let's drop it from buster? Cheers, Moritz
Re: security support in buster and the release notes
Hi, > I am reaching out to you to align on the security support that users can > expect during the lifetime of buster and how this is covered in the > release notes. > > The release notes currently contain a section on "Limitations in > security support", which currently covers: > * web browsers and their rendering engines > * ecosystem around libv8 and Node.js > > Do these subjects still cover your current view of the support for > buster. Especially about the second item I am not sure if it still > applies (although I expect so). webkit2gtk will be covered by security support in buster, this has been sorted out with the maintainers (and primarily with Alberto), it has worked fine for Ubuntu since their last release and I'm optimistic it will also work out fine for Buster. The various webkit forks in QT are still not sanely supportable, but noone else including upstream really covers them with security support, so I think these are fine to be simply listed in src:debian-security-support, I'm not sure really warrant a further callout in the release notes. Same for whatever version of mozjs we'll ship in buster. For Nodejs, upstream has fixed their processes and there are now sensible long term branches which are updated in a professional manner, so nodejs (and transitively the node-* packages) are properly supportable (and we've also sorted out with Jememy and Xavier that they agree that it's supportable). Further work needs to happen to trim down the set of packages (there's a number of "upload once because I need this as a build dep" kind of dead packages), but that can be dealt with after the buster release. libv8 in the form of src:libv8-3.14) is still a mess and won't be part of buster anyway (maybe it can be built out of the libv8 copy shipped by nodejs for bullseye). I'll update debian-security-support in the next days to reflect all that. > Are there other concerns or warnings and > should they already be mentioned in the release notes? There has been no visible movement on the issues with Go as mentioned in https://lists.debian.org/debian-release/2018/07/msg2.html (and this dates back much further, initial discussions were from 2016 or earlier). This is already an issue in Stretch (e.g. #922170), but will be much worse in Buster, so unless someone reliably commits to work on this ASAP the available options are to drop everything Go apart from the toolchain packages from buster or exclude of all that mess from security updates so that people know what they can expect. > On top of the above questions, of course it would be great if you would > check the wording of the current text [1]. Ack, I'll have a look in the next days. Cheers, Moritz
Bug#925506: stretch-pu: package java-common/0.58+deb9u1
On Tue, Apr 16, 2019 at 10:04:20AM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Mon, 2019-04-15 at 22:49 +0200, Moritz Mühlenhoff wrote: > > On Sun, Apr 14, 2019 at 09:20:13PM +0100, Adam D. Barratt wrote: > > > Control: tags -1 + moreinfo > > > > > > On Mon, 2019-03-25 at 22:35 +0100, Moritz Muehlenhoff wrote: > > > > How about the following debdiff to address the fallout of > > > > the Xul deprecation in icedtea-web (#921748) for the next > > > > point update? > > > > > > > > default-jre is the only reverse dependency of > > > > default-java-plugin, so the patch also removes default-java- > > > > plugin > > > > along. > > > > > > I assume the upgrade path from systems with the packages already > > > installed has been tested without issue? > > > > I think so: > > I've upgraded my stretch desktop with java-common and the various > > default-foo packages from the previous version to the new release > > for about two weeks now, given that the only in-archive reverse > > dep of default-java-plugin was in java-common, I can't think of > > another upgrade path to test. > > OK, thanks; please go ahead. Ack, uploaded. > Based on experience from the previous attempt at fixing this, I imagine > #debian will tell us if there is still a problem. :-) Best CI in the world! Cheers, Moritz
Bug#925506: stretch-pu: package java-common/0.58+deb9u1
On Sun, Apr 14, 2019 at 09:20:13PM +0100, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Mon, 2019-03-25 at 22:35 +0100, Moritz Muehlenhoff wrote: > > How about the following debdiff to address the fallout of > > the Xul deprecation in icedtea-web (#921748) for the next > > point update? > > > > default-jre is the only reverse dependency of > > default-java-plugin, so the patch also removes default-java-plugin > > along. > > I assume the upgrade path from systems with the packages already > installed has been tested without issue? I think so: I've upgraded my stretch desktop with java-common and the various default-foo packages from the previous version to the new release for about two weeks now, given that the only in-archive reverse dep of default-java-plugin was in java-common, I can't think of another upgrade path to test. Cheers, Moritz
Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW
On Tue, Apr 02, 2019 at 10:40:44PM -0400, Reinhard Tartler wrote: > Ah, that's great news. I didn't realize that Moritz backported the > security fixes to an earlier upstream version. I managed to locate the > git commits but wasn't comfortable with backporting them to version 0.5.2, > not all of them applied cleanly and I lacked the confidence to resolve > the conflicts. > > Thanks Moritz for taking care of this! Yeah, I sent a mail to debian-multimedia@ldo about this, but seems to have fallen through the cracks: https://lists.debian.org/debian-multimedia/2019/03/msg00081.html BTW, I also prepared an MR on salsa for the remaining open security issues in src:audiofile, it would be great if anyone in the debian multimedia team could merge and upload: https://salsa.debian.org/multimedia-team/audiofile/merge_requests/1 > > As for gpac/0.7.1+dfsg1-1, I cannot find a debdiff for it on the mailing > > list nor the BTS. Therefore, I have no clue whether it is suitable for > > buster. > > The debdiff is unreasonably large (several MiB), there are a *lot* of > unrelated upstream changes included. > > I'll spare you to review it. > > Given we do have those RC bugs fixed with more targeted patches, I > no longer see the urgency to get 0.7.1 into unstable. Would you agree > with having 0.7.1 in experimental instead? If so, I'd upload it as > 0.7.1-2 to experimental. experimental should be fine, as it's totally to the freeze process. Cheers, Moritz
Bug#921748: stretch-pu: package icedtea-web/1.6.2-3.1+deb9u1
On Sat, Feb 16, 2019 at 11:31:24AM +, Adam D. Barratt wrote: > On Fri, 2019-02-08 at 21:03 +0100, Moritz Muehlenhoff wrote: > > This disables the browser plugin (which was broken due to the Firefox > > Quantum changes), the equivalent change in sid was done in 1.7.1-1. > > Unfortunately, we failed to spot that the plugin package gets pulled in > by default on a fair amount of desktop installations (at the very > least, LO -> default-jre -> default-java-plugin -> icedtea-8-plugin), > and there were late reports of APT not handling the upgrade scenario > well (specifically, refusing to touch the packages on a dist-upgrade). > > We therefore decided not to include this update for now, until we can > look at better fixes for the user experience. Meh, I missed the Recommends in default-jre, I can prepare an update for the next point release to remove it from there. Cheers, Moritz
Bug#912730: RM: useragentswitcher/0.7.3-3
On Wed, Nov 07, 2018 at 06:22:58AM +0100, Julien Aubin wrote: > On Sat, 03 Nov 2018 10:45:33 +0100 Moritz Muehlenhoff wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: rm > > > > Broken with Firefox 60, please remove from stretch. > > > > Cheers, > > Moritz > > > > > > Hi Moritz, > > Sorry but upstream releases for this one IS compatible with newer > Firefox. I've created ticket #910756 about it. Could you please upload > them, at least within BPO ? I'm not involved in maintaining useragentswitcher, I'm only cleaning out the broken extensions for stretch. Cheers, Moritz
Bug#912465: RM: mozvoikko/2.2-0.1
On Wed, Oct 31, 2018 at 09:17:02PM +, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Wed, 2018-10-31 at 21:29 +0100, Moritz Muehlenhoff wrote: > > Please remove mozvoikko from stretch, it's broken with Firefox 60. > > Removal from sid was filed in #912457. > > Unfortunately it has r-deps: > > # Broken Depends: > debian-parl: parl-desktop-eu > parl-desktop-world Oh, well. The package has a trivial RC bug unfixed and unacknowledged since January. The dependencies are not even part of debian-parl, but instead defined in src:boxer-data, which would also need an update :-/ In addition all the meta packages have strict dependencies instead of Recommends. Adding the maintainer to CC. Jonas, are you still maintaining debian-parl or shall I file removal bugs? Otherwise, please get this fixed in stable as well, the dependencies for xul-ext-certificatepatrol xul-ext-cookie-monster xul-ext-flashblock xul-ext-noscript xul-ext-refcontrol xul-ext-requestpolicy xul-ext-y-u-no-validate are also all broken since the migration to Firefox 60, so parl-desktop currently sets up a mostly broken Firefox environment. Cheers, Moritz
Bug#910398: stretch-pu: package gnupg2/2.1.18-8~deb9u3
On Sat, Oct 20, 2018 at 10:43:31AM +0100, Adam D. Barratt wrote: > On Fri, 2018-10-05 at 17:48 -0500, Daniel Kahn Gillmor wrote: > > I'd like to update the version of GnuPG in debian stable with a > > series of targeted bugfixes (most of which are backported from > > upstream). > [...] > > I note that this is *not* itself a security fix -- these fixes do not > > address a specific vulnerability in stretch's version of GnuPG. > > However, they do have security implications for stretch, because they > > are needed in order to support enigmail since the thunderbird 60 > > upgrade. > > > > If the release team or the security team (x-debbug-cc'ed here) would > > prefer that we handle this via stretch-security instead of > > stretch-proposed-updates, that's fine with me: please let me know. > > Any chance of an explicit opinion from the Security Team here? [CCed] That's all bugfixes related to enabling Enigmail and nothing in their is itself security-related, so I think that's something for the point update, not security.debian.org Cheers, Moritz
Re: please add a chromium-source binary package
On Mon, Oct 15, 2018 at 10:41:25PM +0200, Steinar H. Gunderson wrote: > On Mon, Oct 15, 2018 at 10:33:11PM +0200, Moritz Muehlenhoff wrote: > > Ultimately this is up for Michael to decide, as he's dealing with Chromium > > updates single-handedly. > > Agreed. > > > Personally I have no reservations against this entering unstable, but this > > doesn't sound > > like something that should enter a stable release. If the Chrome > > development team with > > it's hundreds of full time developers can't/wont commit to a stable > > interface for these > > kinds of extensions, why should we kludge around this with our sparse > > resources? > > I guess the answer is because software wants it. :-) > > CEF exists precisely to be an API-stable interface for this; it's unfortunate > that Chrome doesn't care enough, but CEF is meant to be that layer, and seems > to be doing pretty well (judging by the amount of software that uses it). But our current infrastructure for security.debian.org doesn't scale for this kind of API whack-a-mole. Any update to unbreak CEF after Chromium major releases would need to go through the security team and sucks up our time which is more usefully spend elsewhere. Realistically, to make this would we'd need $SOMEONE to implement #817285, if that were in place we could simply push an ACL change and enable you take care of CEF updates in buster-security on your own. Cheers, Moritz
Bug#910383: RM: spdy-indicator/2.2-1
On Sat, Oct 06, 2018 at 11:16:00AM +0200, Emilio Pozuelo Monfort wrote: > On 05/10/2018 21:04, Moritz Muehlenhoff wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: rm > > > > Broken with Firefox ESR 60, filed for removal from unstable in 910382. > > Is this for stretch? If so, it should be tagged appropriately. Yeah, that's for stretch, now tagged. Cheers, Moritz
Bug#907906: stretch-pu: package openssl/1.1.0f-3+deb9u2
On Tue, Sep 04, 2018 at 12:12:56AM +0200, Sebastian Andrzej Siewior wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: pu > Tags: stretch > Severity: normal I can't speak for the SRMs, but personally I'm in favour of this. In fact, I had been meaning to contact you and Kurt wrt switching to releasing the openssl micro releases for buster-security onwards (but I think it's ok to retroactively apply this for stretch as well). We've had good results of shipping upstream micro releases in -security for selected packages which sane/well-established release/QA processes and I think openssl is a sensible candidate. Apart from the pure security fixes, there's a grey area of changes which are important to also get to stable (and there have been cases where a bugfix shipped in an openssl stable release turned out to be security-relevant later on). (I've been deploying customs debs of the 1.0.2x and 1.1.0x openssl releases at work and I haven't run into any compatibility issues/API issues during that). > The BTS bugs #903566 and #907457 are two examples which were raised > within Debian. It also allows to build some software in stretch which doesn't work with 1.1.0f, e.g. nodejs 10 requires 1.1.0g as it depends on some API functions only introduced there. Cheers, Moritz
Bug#905061: stretch-pu: package mruby/1.2.0+20161228+git30d5424a-1+deb9u1
On Tue, Jul 31, 2018 at 11:29:16AM +0900, Nobuhiro Iwamatsu wrote: > Package: release.debian.org > Severity: normal > Tags: stretch > User: release.debian@packages.debian.org > Usertags: pu > > Dear stable release manager, > > I hereby propose an update for stretch of mruby. There's a few more no-dsa issues for mruby, if you're doing an update anyway, could you also check whether they make sense to be fixed in stretch? See here: https://security-tracker.debian.org/tracker/CVE-2018-10191 https://security-tracker.debian.org/tracker/CVE-2018-14337 https://security-tracker.debian.org/tracker/CVE-2018-12249 https://security-tracker.debian.org/tracker/CVE-2018-12248 https://security-tracker.debian.org/tracker/CVE-2018-11743 Cheers, Moritz
Bug#902832: stretch-pu: package rustc/1.24.1+dfsg1-1~deb9u1
How closed is 9.5 for a followup upload at this point? See the debdiff below to address #903118. Cheers, Moritz diff -Nru rustc-1.24.1+dfsg1/debian/changelog rustc-1.24.1+dfsg1/debian/changelog --- rustc-1.24.1+dfsg1/debian/changelog 2018-07-01 13:42:52.0 +0200 +++ rustc-1.24.1+dfsg1/debian/changelog 2018-07-08 21:39:35.0 +0200 @@ -1,3 +1,11 @@ +rustc (1.24.1+dfsg1-1~deb9u2) stretch; urgency=medium + + * Add Build-Depends on rustc [!amd64] to prevent buildds from attempting +further builds, further supported architectures need to be cross-compiled +(Closes: #903118) + + -- Moritz Mühlenhoff Sun, 08 Jul 2018 21:39:35 +0200 + rustc (1.24.1+dfsg1-1~deb9u1) stretch; urgency=medium * Build for stretch to be used by Firefox ESR60 diff -Nru rustc-1.24.1+dfsg1/debian/control rustc-1.24.1+dfsg1/debian/control --- rustc-1.24.1+dfsg1/debian/control 2018-07-01 13:42:52.0 +0200 +++ rustc-1.24.1+dfsg1/debian/control 2018-07-08 21:39:35.0 +0200 @@ -17,6 +17,7 @@ autotools-dev, cmake (>= 3.0) | cmake3, gperf, + rustc [!amd64], # this is sometimes needed by rustc_llvm zlib1g-dev:native, zlib1g-dev,
Re: dosbox_0.74-4.2+deb9u1_amd64.changes REJECTED
Aurelien Jarno schrieb: > Hi, > > The amd64 build of dosbox/stretch has been rejected by dak, as the > changes file used for the source upload clashes with the one for the > amd64 binary upload. This something not supported by dak for some > suites. > > I guess the best is to do a manual upload of amd64 package using the > _amd64+1.changes extension. I've uploaded such a _amd64+1.changes build. Cheers, Moritz
Bug#901089: stretch-pu: package dosbox/0.74-4.2+deb9u1
On Sun, Jul 01, 2018 at 06:44:08PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Fri, 2018-06-08 at 22:41 +0200, Moritz Muehlenhoff wrote: > > dosbox is broken in the default setting on a number of systems/DOS > > binaries > > (see #857341). This got fixed in unstable back in September, but the > > patch > > is also needed in stretch. Apart from debian/changelog, the debdiff > > the > > only change applied to the package in unstable since the stretch > > release. > > > > Please go ahead. Thanks, uploaded. Cheers, Moritz
Re: Security support for go in buster (Was: Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)
On Sun, Jul 01, 2018 at 08:54:00AM +, Niels Thykier wrote: > Moritz Mühlenhoff: > > Niels Thykier wrote: > >> If the issues and concerns from you or your team are not up to date, > >> then please follow up to this email (keeping debian-release@l.d.o and > >> debian-ports@l.d.o in CC to ensure both parties are notified). > > > > Two issues that we discussed at the recent Security Team sprint wrt > > problems affecting buster: > > > > [...] > > > > (2) Not an architectual issue, but a cross-arch problem: Buster is > > reaching a critical mass of applications written in Go and our tooling > > for security updates is absolutely not in a position to deal with it's > > approach to link everything statically: > > > > dak on ftpmaster and security-master don't share tarballs, IOW the > > first time an application is updated in foo-security it's needs an > > upload including the orig tarball. That's somewhat manageable for > > standard security updates, but if we'd need to recompile all reverse > > deps with individual source uploads (which would be dozens to hundreds > > of packages if it's e.g. in Golang itself), it ends up being total > > madness. > > > > To be able to support Go-based applications in buster-security we > > need tooling which > > - detects which packages need a rebuild if a given Go package has been > > fixed. > > - handles the actual rebuilds and sharing tarballs between security-master > > and ftp-master is an automated manner > > > > Cheers, > > Moritz > > > > Hi Moritz, > > Thanks for highlighting this issue. > > Do you have any idea on whether anyone is working on this tooling at the > moment (e.g. the tarball sharing between security- and ftp-master)? I'm not aware of anyone. > What do you envision as the contingency plan if the tooling is not in > place for buster? The canonical solution for unsupportable packages is usually to exclude them from a stable release, but I really hope we can fix this on a tooling level. Cheers, Moritz
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On Fri, Jun 29, 2018 at 10:33:16PM +0100, Ben Hutchings wrote: > On Fri, 2018-06-29 at 22:31 +0200, Moritz Mühlenhoff wrote: > > Niels Thykier wrote: > > > If the issues and concerns from you or your team are not up to date, > > > then please follow up to this email (keeping debian-release@l.d.o and > > > debian-ports@l.d.o in CC to ensure both parties are notified). > > > > Two issues that we discussed at the recent Security Team sprint wrt > > problems affecting buster: > > > > (1) Linux upstream security support for i386 seems at risk at this point. > > E.g. KPTI for i386 still isn't merged in Linux master half a year later > > after > > the public Meltdown disclosure in early January (and the development of KPTI > > started months before that). Someone at SuSE actually developed patches > > as an older SLES release using Linux 3.0 (!) still supports i386, but that > > will also EOL at some point and if we don't have the manpower to > > develop upstream fixes for future i386-specific flaws. > > > > It's not a strict blocker, but we wanted to raise the discussion whether > > it still makes sense to ship 32 bit kernels for buster, which means with > > support until ~ 2022. > [...] > > The lack of Meltdown mitigation on i386 is concerning, though I remain > somewhat hopeful that it will get fixes eventually. A quick look > through kernel-sec finds maybe 3 other i386-specific issues in the last > 5 years (CVE-2013-0190, CVE-2014-4508, CVE-2016-3672), and none of the > fixes were difficult to backport. Fair enough. Ultimately it's your call, but we wanted to raise it due to the long term perspective upstream. > It's worth noting that Meltdown also never got mitigated for any of the > other affected architectures (at least ppc64el and s390x) in jessie, > despite being addressed upstream. So I don't think it makes sense to > pick on i386 as being particularly vulnerable. Well, the difference is that 99% of users still installing a buster system with i386 are doing it out of ignorance and would otherwise be protected if they'd picked amd64. For ppc64el and s390x no such alternative exists. Cheers, Moritz
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Niels Thykier wrote: > If the issues and concerns from you or your team are not up to date, > then please follow up to this email (keeping debian-release@l.d.o and > debian-ports@l.d.o in CC to ensure both parties are notified). Two issues that we discussed at the recent Security Team sprint wrt problems affecting buster: (1) Linux upstream security support for i386 seems at risk at this point. E.g. KPTI for i386 still isn't merged in Linux master half a year later after the public Meltdown disclosure in early January (and the development of KPTI started months before that). Someone at SuSE actually developed patches as an older SLES release using Linux 3.0 (!) still supports i386, but that will also EOL at some point and if we don't have the manpower to develop upstream fixes for future i386-specific flaws. It's not a strict blocker, but we wanted to raise the discussion whether it still makes sense to ship 32 bit kernels for buster, which means with support until ~ 2022. (2) Not an architectual issue, but a cross-arch problem: Buster is reaching a critical mass of applications written in Go and our tooling for security updates is absolutely not in a position to deal with it's approach to link everything statically: dak on ftpmaster and security-master don't share tarballs, IOW the first time an application is updated in foo-security it's needs an upload including the orig tarball. That's somewhat manageable for standard security updates, but if we'd need to recompile all reverse deps with individual source uploads (which would be dozens to hundreds of packages if it's e.g. in Golang itself), it ends up being total madness. To be able to support Go-based applications in buster-security we need tooling which - detects which packages need a rebuild if a given Go package has been fixed. - handles the actual rebuilds and sharing tarballs between security-master and ftp-master is an automated manner Cheers, Moritz
Bug#901355: stretch-pu: package llvm-4.0/1:4.0.1-10~deb9u1
On Wed, Jun 27, 2018 at 08:18:01PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > It's a straightforward rebuild. The debdiff against 1:4.0.1-10 > > from buster is very simple (with an additional build conflicts > > I ran into when preparing the build). > > Please go ahead. Uploaded. Cheers, Moritz
Re: jessie-security packages missing from ftp-master
On Tue, Jun 12, 2018 at 09:45:06AM +0100, Adam D. Barratt wrote: > > > * git-annex 5.20141125+deb8u1 (arm64 ppc64el) > > > * graphicsmagick 1.3.20-3+deb8u2 (powerpc) > > > * mariadb-10.0 10.0.32-0+deb8u1 (mips mipsel powerpc s390x) > > Thanks, but at this stage I think we'll just have to accept the packages > "as-is" in order to get as much as we can into 8.11. That makes a lot of sense. > Unless I'm mistaken, > these are all architectures that won't be supported by jessie-lts? Ack, arm64 ppc64el powerpc mips mipsel and s390x are not archs not covered in jessie-lts. Cheers, Moritz
Re: jessie-security packages missing from ftp-master
On Mon, Jun 11, 2018 at 10:04:29PM +0100, Adam D. Barratt wrote: > Unfortunately not quite yet, as none of the builds made it to > oldstable-new. It looks like this is due to: > > Version check failed: > Your upload included the binary package openjdk-7-jre-zero, version > 7u181-2.6.14-1~deb8u1, for amd64, however experimental already has > version 7u161-2.6.12-1. That seems like stale data, experimental has 7u181-2.6.14-1? Cheers, Moritz
Bug#901276: jessie-pu: package lame/3.99.5+repack1-7+deb8u2
On Sun, Jun 10, 2018 at 02:59:49PM -0400, Hugo Lefeuvre wrote: > > lame 3.99.5+repack1-7+deb8u1 is affected by several vulnerabilities in > the code used to read the input file. These issues are not present in > any Debian release after Jessie because the package switched to > libsndfile to read and write audio files. The upstream code itself was > recently fixed in 3.100. FWIW, patch looks fine. Cheers, Moritz
