NEW changes in oldstable-new
Processing changes file: swupdate_2020.11-2+deb11u1_s390x-buildd.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: swupdate_2020.11-2+deb11u1_all-buildd.changes ACCEPT Processing changes file: symfony_4.4.19+dfsg-2+deb11u4_all-buildd.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: gnutls28_3.7.1-5+deb11u4_all-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u4_mips64el-buildd.changes ACCEPT Processing changes file: swupdate_2020.11-2+deb11u1_i386-buildd.changes ACCEPT Processing changes file: swupdate_2020.11-2+deb11u1_mips64el-buildd.changes ACCEPT Processing changes file: swupdate_2020.11-2+deb11u1_mipsel-buildd.changes ACCEPT Processing changes file: zeromq3_4.3.4-1+deb11u1_i386-buildd.changes ACCEPT Processing changes file: zeromq3_4.3.4-1+deb11u1_mips64el-buildd.changes ACCEPT Processing changes file: zeromq3_4.3.4-1+deb11u1_mipsel-buildd.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: gnutls28_3.7.1-5+deb11u4_amd64-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u4_arm64-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u4_armhf-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u4_i386-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u4_mipsel-buildd.changes ACCEPT Processing changes file: swupdate_2020.11-2+deb11u1_amd64-buildd.changes ACCEPT Processing changes file: swupdate_2020.11-2+deb11u1_armhf-buildd.changes ACCEPT Processing changes file: zeromq3_4.3.4-1+deb11u1_amd64-buildd.changes ACCEPT Processing changes file: zeromq3_4.3.4-1+deb11u1_arm64-buildd.changes ACCEPT Processing changes file: zeromq3_4.3.4-1+deb11u1_armel-buildd.changes ACCEPT Processing changes file: zeromq3_4.3.4-1+deb11u1_armhf-buildd.changes ACCEPT Processing changes file: zeromq3_4.3.4-1+deb11u1_s390x-buildd.changes ACCEPT
Processed: tagging 1052561
Processing commands for cont...@bugs.debian.org: > tags 1052561 - moreinfo Bug #1052561 [release.debian.org] bookworm-pu: package nfdump/1.7.3-1 (pre-discussion) Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 1052561: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052561 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: tagging 1051024
Processing commands for cont...@bugs.debian.org: > tags 1051024 - moreinfo Bug #1051024 [release.debian.org] bookworm-pu: package igtf-policy-bundle/1.122-1~deb12u1 Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 1051024: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051024 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
NEW changes in oldstable-new
Processing changes file: gnutls28_3.7.1-5+deb11u4_armel-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u4_ppc64el-buildd.changes ACCEPT Processing changes file: gnutls28_3.7.1-5+deb11u4_s390x-buildd.changes ACCEPT Processing changes file: swupdate_2020.11-2+deb11u1_arm64-buildd.changes ACCEPT Processing changes file: swupdate_2020.11-2+deb11u1_armel-buildd.changes ACCEPT Processing changes file: swupdate_2020.11-2+deb11u1_ppc64el-buildd.changes ACCEPT Processing changes file: zeromq3_4.3.4-1+deb11u1_ppc64el-buildd.changes ACCEPT
Processed: Re: Bug#1054466: bookworm-pu: package localslackirc/1.17-1.1
Processing control commands: > tag -1 confirmed Bug #1054466 [release.debian.org] bookworm-pu: package localslackirc/1.17-1.1 Added tag(s) confirmed. -- 1054466: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054466 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1054466: bookworm-pu: package localslackirc/1.17-1.1
Control: tag -1 confirmed On Tue, Oct 24, 2023 at 10:27:57AM +0200, Salvo "LtWorf" Tomaselli wrote: > Slack now requires some headers to connect to the websocket, that were not > needed before. > > This patch is to backport the sending of those headers, so that localslackirc > can connect to it. Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Security releases for ecosystems that use static linking
Dear Security, Release and Wanna-build teams, As some of you may be aware, we (the LTS Team) are reviewing the packages with limitations in their support, and I would like to bring some discussion regarding Go, Rust and the like. As the bookworm (and older) release notes document: The Debian infrastructure currently has problems with rebuilding packages of types that systematically use static linking. With the growth of the Go and Rust ecosystems it means that these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably. In most cases if updates are warranted for Go or Rust development libraries, they will only be released via regular point releases. https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#limited-security-support As the number of packages in these ecosystems increases(*) we think it is important for us to help improving the current situation. Of course, this relates to LTS too, but we cannot address this kind of issues without solving them in stable first. AFAIU, these limitations could be (extremely) summarised to identifying the related and relevant reverse build dependencies to the vulnerable package; triggering their (sequential?) rebuilds; and testing them(!). On a related note, I see the Release Team has discussed about replacing binNMUs with NMUs, and there are things to be solved in that way. So let me ask you: are you interested in addressing the infrastructure limitations to handle those kind of packages? and having some help for that? Even if am very illiterate about the debian building infrastructure myself, I can see the problem is not so easy. And I must be missing important challenges and precise details about the problems to be solved, but I am willing to discuss this :-) Are there any public records of discussions on the subject that I have missed? Thanks for reading, and happy solstice! -- Santiago (*) For Go, the number of packages that I found required a Go compiler to be built are: 1140 buster 1644 bullseye 2101 bookworm Attached you can find the list for bookworm packages (based on golang-1.19-go and gccgo). I haven't looked at Rust yet. acmetool aerc age alertmanager-irc-relay amazon-ecr-credential-helper amfora android-platform-build-kati aptly arduino-builder audit aws-nuke badger balboa balloon bettercap bombadillo boohu browserpass burrow c2go caddy canid cctools certinfo certspotter cfrpki chasquid clipman cloudsql-proxy cobra-cli codesearch containerd continuity crowdsec crowdsec-custom-bouncer crowdsec-firewall-bouncer debiman debos deck delve dh-make-golang direnv dmarc-cat dnss docker.io docker-libkv docker-registry duf earlyoom easygen efm-langserver elvish emd etcd ethflux fcitx5-bamboo fdroidcl fever ffcvt ffuf fq fscrypt fzf g10k garagemq gdu ggd-utils gh gifwrap gitbatch gitbrute git-credential-oauth git-lfs gobgp gobuster gocc gocryptfs go-dlib go-gir-generator goiardi gojq gokey golang-1.19 golang-airbrake-go golang-android-soong golang-ariga-atlas golang-barcode golang-bazil-fuse golang-bindata golang-bitbucket-pkg-inflect golang-blackfriday golang-blackfriday-v2 golang-blitiri-go-log golang-blitiri-go-spf golang-blitiri-go-systemd golang-bugsnag-panicwrap golang-check.v1 golang-code.cloudfoundry-bytefmt golang-code.rocketnine-tslocum-cbind golang-code.rocketnine-tslocum-cview golang-collectd golang-coreos-log golang-dbus golang-debian-mdosch-xmppsrv golang-debian-vasudev-gospake2 golang-eclipse-paho golang-ed25519-dev golang-entgo-ent golang-filippo-edwards25519 golang-fsnotify golang-ginkgo golang-gitaly-proto golang-github-0xax-notificator golang-github-14rcole-gopopulate golang-github-a8m-tree golang-github-aalpar-deheap golang-github-abbot-go-http-auth golang-github-abdullin-seq golang-github-abeconnelly-autoio golang-github-acarl005-stripansi golang-github-achannarasappa-term-grid golang-github-adam-hanna-arrayoperations golang-github-adam-lavrik-go-imath golang-github-adrg-xdg golang-github-adrianmo-go-nmea golang-github-adtac-go-akismet golang-github-advancedlogic-goose golang-github-aead-chacha20 golang-github-aead-poly1305 golang-github-aelsabbahy-gonetstat golang-github-agext-levenshtein golang-github-agnivade-levenshtein golang-github-ajstarks-svgo golang-github-akamai-akamaiopen-edgegrid-golang golang-github-akavel-rsrc golang-github-akosmarton-papipes golang-github-akrennmair-gopcap golang-github-albenik-go-serial golang-github-alcortesm-tgz golang-github-alecaivazis-survey golang-github-alecthomas-assert golang-github-alecthomas-binary golang-github-alecthomas-chroma golang-github-alecthomas-chroma-v2 golang-github-alecthomas-colour golang-github-alecthomas-jsonschema golang-github-alecthomas-kong golang-github-alecthomas-kong-hcl golang-github-alecthomas-participle golang-github-alecthomas-repr golang-github-alecthomas-units golang-github-aleksi-pointer golang-github-alessio-shellescape
Bug#1056358: bookworm-pu: package needrestart/3.6-4+deb12u1
Control: tag -1 confirmed On Sat, Dec 02, 2023 at 06:47:42PM -0500, Antoine Beaupré wrote: > diff -Nru needrestart-3.6/debian/changelog needrestart-3.6/debian/changelog > --- needrestart-3.6/debian/changelog 2023-05-31 10:47:03.0 -0400 > +++ needrestart-3.6/debian/changelog 2023-11-15 15:05:37.0 -0500 > @@ -1,3 +1,9 @@ > +needrestart (3.6-4+deb12u1) bookworm; urgency=medium > + > + * fix microcode check regression on AMD CPUs (Closes: #1013285) > + > + -- Antoine Beaupré Wed, 15 Nov 2023 15:05:37 -0500 > + Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1056358: bookworm-pu: package needrestart/3.6-4+deb12u1
Processing control commands: > tag -1 confirmed Bug #1056358 [release.debian.org] bookworm-pu: package needrestart/3.6-4+deb12u1 Added tag(s) confirmed. -- 1056358: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056358 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1057089: bullseye-pu: package usrmerge/37~deb12u1
Processing control commands: > tag -1 confirmed Bug #1057089 [release.debian.org] bookworm-pu: package usrmerge/37~deb12u1 Added tag(s) confirmed. -- 1057089: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057089 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1057089: bullseye-pu: package usrmerge/37~deb12u1
Control: tag -1 confirmed On Wed, Nov 29, 2023 at 03:46:30PM +0100, Andreas Beckmann wrote: > [ Reason ] > Improve the usrmerge experience in bookworm. > A few more ancient packages were found that need to be removed first for > usrmerge to succeed, add versioned Breaks against them. > Depending on the time a system was bootstrapped or converted, there may > be biarch directories/links not owned by any package > (e.g. /usr/libx32 and /libx32 -> /usr/libx32) > Since these are now handled by the respective packages from src:glibc, > bootstrapping and conversion no longer create them and we can clean them > up if they are empty and not owned by a package. > Clarify errors in case something goes wrong during usrmerge conversion. Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1056969: bookworm-pu: package swupdate/2022.12+dfsg-4+deb12u1
Processing control commands: > tag -1 confirmed Bug #1056969 [release.debian.org] bookworm-pu: package swupdate/2022.12+dfsg-4+deb12u1 Added tag(s) confirmed. -- 1056969: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056969 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1056969: bookworm-pu: package swupdate/2022.12+dfsg-4+deb12u1
Control: tag -1 confirmed On Mon, Nov 27, 2023 at 12:09:33PM +0100, Bastian Germann wrote: > [ Reason ] > There is a local privilege escalation in swupdate package because the > service's control socket has world-writable file permissions. Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1058928: bookworm-pu: package cryptsetup/2:2.6.1-4~deb12u2
Processing control commands: > tag -1 moreinfo Bug #1058928 [release.debian.org] bookworm-pu: package cryptsetup/2:2.6.1-4~deb12u2 Added tag(s) moreinfo. -- 1058928: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058928 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1058928: bookworm-pu: package cryptsetup/2:2.6.1-4~deb12u2
Control: tag -1 moreinfo Hi, On Mon, Dec 18, 2023 at 02:10:20PM +0100, Guilhem Moulin wrote: > [ Reason ] > > 1. cryptsetup-suspend 2:2.6.1-4~deb12u1 was found incompatible with > systemd 254.1-3 and later, in particular with systemd/bookworm-backports. > > 2. cryptsetup-initramfs 2:2.6.1-4~deb12u2 dos not support kernel > shipping compressed modules under MODULES=dep, as is done by default > with linux 6.6 (currently in Debian experimental). Aren't these problems better sorted out in the relevant suites, e.g. with Breaks? It seems an unnecessary change in stable when stable isn't actually broken. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Re: /usr-move: Do we support upgrades without apt?
On Thu, Dec 21, 2023 at 02:42:56PM +, Matthew Vernon wrote: > On 21/12/2023 09:41, Helmut Grohne wrote: > > Is it ok to call upgrade scenarios failures that cannot be reproduced > > using apt unsupported until we no longer deal with aliasing? > > I incline towards "no"; if an upgrade has failed part-way (as does happen), > people may then reasonably use dpkg directly to try and un-wedge the upgrade > (e.g. to try and configure some part-installed packages, or try installing > some already-downloaded packages). You can configure half-installed packages, no problem, this is about unpacking (which is the first step in an install, where only Conflicts and Pre-Depends matter, if you are not deep into dpkg vocabulary) The "try installing" part is less straight forward. In general, you are running into dpkg "features" (e.g. not handling pre-depends) or into dpkg bugs (e.g. #832972, #844300): In the best case your system state became a bit worse and hence harder to "un-wedge". In the worst case a maintainer script has run amok as nobody tested this. But yeah, most of the time you will indeed be lucky and hence come to the unreasonable conclusion that its reasonable to call dpkg directly. Anyway, if your upgrade failed part-way, you are probably in luck given that its more likely the upgrade failed in unpack/configure than in removal – so if you aren't too eager to install more packages by hand but limit yourself to e.g. (re)installing the ones who failed you are fine as apt will have removed the conflictors already for you (or upgraded them, if that can resolve the conflict). But lets assume you are not: As you are driving dpkg by hand you also have the time to read what it prints, which in the problematic case is (as exampled by #1058937): | dpkg: considering removing libnfsidmap-regex:amd64 in favour of libnfsidmap1:amd64 ... | dpkg: yes, will remove libnfsidmap-regex:amd64 in favour of libnfsidmap1:amd64 (and the same for libnfsidmap2:amd64 as well. If your terminal supports it parts of these messages will be in bold) Note that the similar "dpkg: considering deconfiguration of …" which is the result of Breaks relations is not a problematic case. (Also note that this exact situation is indeed another reason why interacting with dpkg by hand is somewhat dangerous as you might not expect packages to be removed from your system while you just told dpkg to unpack something… just remember that the next time you happen to "dpkg -i" some random deb file onto your system.) That is of course no hint that a file might have been lost due to aliasing if you don't know that this could be the case, but on the upside it is not entirely a silent file lose situation either. We could write something in the release notes if someone happens to read them AND also encounters this message. Query your memory: Did you encounter this message before? Nothing in the /usr merge plan makes that particularly more likely to be encountered for a user and not all of the encounters will actually exhibit the file lose. So if you haven't – and I would argue that most people haven't – there is a pretty good chance you wont have a problem in the future either… So, in summary: Yes, there are theoretic relatively easy ways to trigger it with dpkg directly. That isn't the question. The question is if a real person who isn't actively trying to trigger it is likely to run into it by accident (and/or if such a person can even reasonably exist) so that we have to help them by generating work for many people and potentially new upgrade problems for everyone – or if we declare them, existing or not, a non-issue at least for the upgrade to trixie. And on a sidenote: I would advise to reconsider interacting with dpkg too casually – but luck is probably on your side in any case. Best regards David Kalnischkies signature.asc Description: PGP signature
Processed: Re: Bug#1059235: bookworm-pu: package fish/3.6.0-3.1+deb12u1
Processing control commands: > tag -1 confirmed Bug #1059235 [release.debian.org] bookworm-pu: package fish/3.6.0-3.1+deb12u1 Added tag(s) confirmed. -- 1059235: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059235 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1059235: bookworm-pu: package fish/3.6.0-3.1+deb12u1
Control: tag -1 confirmed On Thu, Dec 21, 2023 at 10:06:23PM +0100, Salvatore Bonaccorso wrote: > Can you as well add a bug closer for #1057455? And a brief description of what the vulnerability actually is, please. You can go ahead with those changes. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1
Processing control commands: > tag -1 confirmed Bug #1058938 [release.debian.org] bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1 Added tag(s) confirmed. -- 1058938: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058938 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1058938: bookworm-pu: package onionprobe/1.0.0+ds-2.1+deb12u1
Control: tag -1 confirmed On Mon, Dec 18, 2023 at 03:21:27PM +, Georg Faerber wrote: > [ Reason ] > On bullseye, this works without a warning: > $ tor --hash-password some-string > 16:A871A161E60E3C3960934C88AA783AC6B693DF63CF7897CA5E87219E26 > > Whereas on bookworm, this throws a warning: > $ tor --hash-password some-string > Sep 28 20:48:10.111 [warn] Tor was compiled with zstd 1.5.2, but is running > with zstd 1.5.4. For safety, we'll avoid using advanced zstd functionality. > 16:E4DFE5BA0F5C257060D3D092B5666351C8A04DEF6C77E27DAE7B6015A8 > > Due to this, onionprobe fails to initialize Tor. > > This was fixed, both upstream and in Debian unstable via 1.1.2+ds-1. Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1053997: bullseye-pu: package curl/7.74.0-1.3+deb11u11
Processing control commands: > tag -1 confirmed Bug #1053997 [release.debian.org] bullseye-pu: package curl/7.74.0-1.3+deb11u11 Added tag(s) confirmed. -- 1053997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053997 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1053997: bullseye-pu: package curl/7.74.0-1.3+deb11u11
Control: tag -1 confirmed On Sun, Oct 15, 2023 at 04:22:12PM +0100, Samuel Henrique wrote: > [ Reason ] > This change provides DEB_VERSION on "--version" output. Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1025789: bullseye-pu: wolfssl/4.6.0+p1-0+deb11u1_4.6.0+p1-0+deb11u2.debdiff
Processing control commands: > tag -1 confirmed Bug #1025789 [release.debian.org] bullseye-pu: wolfssl/4.6.0+p1-0+deb11u2 Added tag(s) confirmed. -- 1025789: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025789 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1025789: bullseye-pu: wolfssl/4.6.0+p1-0+deb11u1_4.6.0+p1-0+deb11u2.debdiff
Processing control commands: > tag -1 confirmed Bug #1025789 [release.debian.org] bullseye-pu: wolfssl/4.6.0+p1-0+deb11u2 Ignoring request to alter tags of bug #1025789 to the same tags previously set -- 1025789: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025789 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1025789: bullseye-pu: wolfssl/4.6.0+p1-0+deb11u1_4.6.0+p1-0+deb11u2.debdiff
Control: tag -1 confirmed On Mon, Oct 23, 2023 at 08:10:34PM +0200, Bastian Germann wrote: > Please find a version with an additional fix for CVE-2023-3724 attached. > diff -Nru wolfssl-4.6.0+p1/debian/changelog wolfssl-4.6.0+p1/debian/changelog > --- wolfssl-4.6.0+p1/debian/changelog 2022-03-17 21:47:46.0 + > +++ wolfssl-4.6.0+p1/debian/changelog 2023-07-22 16:08:27.0 + > @@ -1,3 +1,14 @@ > +wolfssl (4.6.0+p1-0+deb11u2) bullseye; urgency=medium > + > + * Stable update for the following vulnerabilities. The patches were > +provided by upstream. > +- PR 5498: CVE-2022-42961 > +- PR 5588: CVE-2022-39173 > +- PR 5682: CVE-2022-42905 > +- PR 6412: CVE-2023-3724 > + Please add a brief description of what each of these vulnerabilities actually is. > + -- Jacob Barthelmeh Sat, 22 Jul 2023 10:08:27 -0600 I take it you're sponsoring? Otherwise this looks odd. Once updated please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#993809: bullseye-pu: package segemehl/0.3.4-3+deb11u1 (Pre-approval)
Processing control commands: > tag -1 confirmed Bug #993809 [release.debian.org] bullseye-pu: package segemehl/0.3.4-3+deb11u1 (Pre-approval) Added tag(s) confirmed. -- 993809: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993809 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
NEW changes in oldstable-new
Processing changes file: gnutls28_3.7.1-5+deb11u4_multi.changes ACCEPT Processing changes file: swupdate_2020.11-2+deb11u1_source.changes ACCEPT Processing changes file: symfony_4.4.19+dfsg-2+deb11u4_source.changes ACCEPT Processing changes file: zeromq3_4.3.4-1+deb11u1_source.changes ACCEPT
Bug#993809: bullseye-pu: package segemehl/0.3.4-3+deb11u1 (Pre-approval)
Control: tag -1 confirmed
On Sat, Dec 04, 2021 at 12:51:31AM +0530, Nilesh Patra wrote:
> On 3 December 2021 9:41:48 pm IST, Julien Cristau wrote:
> >On Tue, Sep 07, 2021 at 12:27:05AM +0530, Nilesh Patra wrote:
> >> diff -Nru segemehl-0.3.4/debian/patches/arm64.patch
> >> segemehl-0.3.4/debian/patches/arm64.patch
> >> --- segemehl-0.3.4/debian/patches/arm64.patch 1970-01-01
> >> 05:30:00.0 +0530
> >> +++ segemehl-0.3.4/debian/patches/arm64.patch 2021-09-06
> >> 23:43:50.0 +0530
> >> @@ -0,0 +1,75 @@
> >> +Description: Change the signed-ness for several chars to fix segfault
> >> +Author: Nilesh Patra
> >> +Last-Update: 2021-08-24
> >> +--- a/libs/biofiles.c
> >> b/libs/biofiles.c
> >> +@@ -1916,7 +1916,7 @@
> >> + Uint max, Uint *minlen, Uint *maxlen, unsigned char *minq, unsigned
> >> char *maxq)
> >> + {
> >> +
> >> +- char ch;
> >> ++ signed char ch;
> >> + char idchar=0;
> >> + int ret=0;
> >> + off_t curseqoffset, lastindexoffset=0;
> >
> >Shouldn't `ch` be an `int` instead, to match the return value of getc,
> >and type of EOF?
> >
> >Anyway, I guess this is fine if it works...
>
> Should I upload this to p-u?
If it's still relevant, yes please (sorry for the delay). If not please
close the request.
Thanks,
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
NEW changes in stable-new
Processing changes file: firefox-esr_115.6.0esr-1~deb12u1_source.changes ACCEPT Processing changes file: firefox-esr_115.6.0esr-1~deb12u1_all-buildd.changes ACCEPT Processing changes file: firefox-esr_115.6.0esr-1~deb12u1_amd64-buildd.changes ACCEPT Processing changes file: firefox-esr_115.6.0esr-1~deb12u1_arm64-buildd.changes ACCEPT Processing changes file: firefox-esr_115.6.0esr-1~deb12u1_armhf-buildd.changes ACCEPT Processing changes file: firefox-esr_115.6.0esr-1~deb12u1_i386-buildd.changes ACCEPT Processing changes file: firefox-esr_115.6.0esr-1~deb12u1_mips64el-buildd.changes ACCEPT Processing changes file: firefox-esr_115.6.0esr-1~deb12u1_ppc64el-buildd.changes ACCEPT Processing changes file: firefox-esr_115.6.0esr-1~deb12u1_s390x-buildd.changes ACCEPT
Processed: Re: Bug#1002956: New debdiff
Processing control commands: > tag -1 moreinfo Bug #1002956 [release.debian.org] bullseye-pu: package rabbitmq-server/3.8.9-3 CVE-2021-32718, CVE-2021-32719 Bug #1004513 [release.debian.org] bullseye-pu: package rabbitmq-server/3.8.9-3 Ignoring request to alter tags of bug #1002956 to the same tags previously set Ignoring request to alter tags of bug #1004513 to the same tags previously set -- 1002956: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002956 1004513: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004513 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1002956: New debdiff
Processing control commands: > tag -1 moreinfo Bug #1002956 [release.debian.org] bullseye-pu: package rabbitmq-server/3.8.9-3 CVE-2021-32718, CVE-2021-32719 Bug #1004513 [release.debian.org] bullseye-pu: package rabbitmq-server/3.8.9-3 Added tag(s) moreinfo. Added tag(s) moreinfo. -- 1002956: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002956 1004513: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004513 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1002956: New debdiff
Control: tag -1 moreinfo
Hi,
On Tue, Nov 29, 2022 at 10:12:20PM -0500, Alex Vandiver wrote:
> On Sat, 06 Aug 2022 19:09:05 +0100 "Adam D. Barratt"
> wrote:
> > + * Stop moving mv /etc/rabbitmq/rabbitmq.conf
> > /etc/rabbitmq/rabbitmq-env.conf.
> >
> > This could do with an explanation as to _why_ this move should not be
> > happening.
>
> I believe this is https://bugs.debian.org/943699
>
> > + if ! [ -e /var/lib/rabbitmq/.erlang.cookie ] ; then
> > + OLD_UMASK=$(umask)
> > + umask 077; openssl rand -base64 -out
> > /var/lib/rabbitmq/.erlang.cookie 42
> > + umask ${OLD_UMASK}
> > + else
> > + # This matches an Erlang generated cookie file: 20 upper
> > case chars
> > + if grep -q -E '^[A-Z]{20}$'
> > /var/lib/rabbitmq/.erlang.cookie ; then
> > + OLD_UMASK=$(umask)
> > + umask 077; openssl rand -base64 -out
> > /var/lib/rabbitmq/.erlang.cookie 42
> > + umask ${OLD_UMASK}
> > + if [ ""$(ps --no-headers -o comm 1) = "systemd" ] ;
> > then
> > + if systemctl is-active --quiet
> > rabbitmq-server.service ; then
> > + systemctl restart
> > rabbitmq-server.service
> > [...]
> > +Since 3.9.8-3, the rabbitmq-server node will use openssl to generate a
> > +cryptographically-secure cookie during first installation, mitigating
> > +this vulnerability.
> > +
> > +Servers which installed a prior version, and are upgrading to 3.9.8-3
> > +or higher, ARE STILL VULNERABLE, as the package will not regenerate
> > +the secret if it exists already. This is because the secret is
> > +designed to be shared between nodes in a cluster, and thus
> > +regenerating it would break existing clusters.
> >
> > This seems to be inaccurate. The latter block quoted above specifically
> > *does* regenerate an existing secret if it deems it to be not "good
> > enough", so far as I can tell?
>
> The README.debian changes are out of date with the code, yes. The
> warnings in README.debian, I believe, date from when that
> documentation was a compromise solution, rather than fixing existing
> weak magic cookies. Since the code now does address those, the README
> should be updated accordingly. The changelog might also merit a
> warning that this may break clustered installs which share a weak
> magic cookie, similar to the note in the initial mail of
> https://bugs.debian.org/1004513
That probably needs doing then, and a revised debdiff proposing. I get the
impression this bug is languishing because everybody is waiting for each
other...
Thanks,
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1059226: release.debian.org: Help doris migrate to testing
Processing control commands: > retitle -1 britney2 wrong installability block in autopkgtest Bug #1059226 [release.debian.org] release.debian.org: Help doris migrate to testing Changed Bug title to 'britney2 wrong installability block in autopkgtest' from 'release.debian.org: Help doris migrate to testing'. -- 1059226: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059226 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1059226: release.debian.org: Help doris migrate to testing
Control: retitle -1 britney2 wrong installability block in autopkgtest Hi Bas, On 21-12-2023 14:06, Bas Couwenberg wrote: doris (5.0.3~beta+dfsg-17) is not migrating to testing, the excuses suggest this is due to superficial autopkgtests: https://qa.debian.org/excuses.php?package=doris No, I think the problem is: uninstallable on arch arm64, not running autopkgtest there which I think is a bug in britney2 as this isn't a regression and britney2 shouldn't block on it. I've hinted doris but I'll leave this bug open for us to fix the issue. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059235: bookworm-pu: package fish/3.6.0-3.1+deb12u1
Hi, On Thu, Dec 21, 2023 at 03:16:22PM -0500, M. Zhou wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: f...@packages.debian.org > Control: affects -1 + src:fish > > > [ Reason ] > > Cherry-pick upstream fix to CVE-2023-49284 > > [ Impact ] > > This is a low severity security issue that affects basically > all historical releases of fish. The upstream created new > releases (i.e. 3.6.2) solely for fixing this bug. > https://github.com/fish-shell/fish-shell/commits/Integration_3.6.2/ > So it would be good if we can integrate the fix into stable. > > > [ Tests ] > > The fix is already included in fish/3.6.4-1 (sid). > The rebased patch passed my local sbuild test. > I installed the package in a chroot and tested it. > > [ Risks ] > > low. > > [ Checklist ] > [x] *all* changes are documented in the d/changelog > [x] I reviewed all changes and I approve them > [x] attach debdiff against the package in (old)stable > [x] the issue is verified as fixed in unstable > > [ Changes ] > > Only one change. Please refer to the patch header for explanation. > > [ Other info ] > > diff -Nru fish-3.6.0/debian/changelog fish-3.6.0/debian/changelog > --- fish-3.6.0/debian/changelog 2023-05-01 13:01:01.0 -0400 > +++ fish-3.6.0/debian/changelog 2023-12-21 14:47:56.0 -0500 > @@ -1,3 +1,9 @@ > +fish (3.6.0-3.1+deb12u1) bookworm; urgency=medium > + > + * Cherry-pick upstream fix for CVE-2023-49284. Can you as well add a bug closer for #1057455? Regards, Salvatore
Bug#1054189: bullseye-pu: package debian-security-support/1:11+2023.10.17
Control: tag -1 confirmed On Mon, Dec 11, 2023 at 04:30:08PM +, Holger Levsen wrote: > I've updated this update request for adding 3 more lines to > security-support-ended.deb11 (and updating d/changelog) Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1054189: bullseye-pu: package debian-security-support/1:11+2023.10.17
Processing control commands: > tag -1 confirmed Bug #1054189 [release.debian.org] bullseye-pu: package debian-security-support/1:11+2023.12.11 Added tag(s) confirmed. -- 1054189: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054189 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1053816: bullseye-pu: package nftables/0.9.8-3.1+deb11u2
Control: tag -1 confirmed On Wed, Oct 11, 2023 at 11:13:03PM +0100, Jeremy Sowden wrote: > A version of this pu has already been accepted for Bookworm. I have cribbed > liberally from the bookworm-pu bug report. > > nftables bug: https://bugs.debian.org/1051592 > bookworm-pu bug: https://bugs.debian.org/1052021 > > [ Reason ] > Timo Sigurdsson reported after the release of DSA 5492-1 for linux that > in his case nftables rules were not loaded anymore. Please go ahead. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1053816: bullseye-pu: package nftables/0.9.8-3.1+deb11u2
Processing control commands: > tag -1 confirmed Bug #1053816 [release.debian.org] bullseye-pu: package nftables/0.9.8-3.1+deb11u2 Added tag(s) confirmed. -- 1053816: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053816 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: tagging 1057180
Processing commands for cont...@bugs.debian.org: > tags 1057180 + moreinfo Bug #1057180 [release.debian.org] bullseye-pu: package mariadb-10.5 1:10.5.23-0+deb11u1 Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 1057180: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057180 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: /usr-move: Do we support upgrades without apt?
On Thu, Dec 21, 2023 at 03:31:55PM +0100, Marc Haber wrote: > On Thu, Dec 21, 2023 at 11:19:48AM -0300, Antonio Terceiro wrote: > > On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote: > > > Is it ok to call upgrade scenarios failures that cannot be reproduced > > > using apt unsupported until we no longer deal with aliasing? > > > > I think so, yes. I don't think it's likely that there are people doing > > upgrades on running systems not using apt. > > Do those GUI frontends that work via packagekit or other frameworks > count as "using apt"? I explained that in full detail in my mail to the pause-thread: https://lists.debian.org/debian-devel/2023/12/msg00039.html In short: helmuts "apt" (my "APT") includes everything that uses libapt. That is apt, apt-get, python-apt, aptitude, synaptics, everything based on packagekit, … I know of only cupt and dselect which don't count, but I have some suspicion that they would work anyhow. IF you don't run into other problems with them, like that they do not implement Multi-Arch. So this thread is really about: How much are people REALLY fiddling with dpkg directly in an upgrade and can we just say its unsupported – because, at least that is my view, in practice nobody does it and its therefore also completely untested. Case in point: We have this thread not because someone found it while working with dpkg directly even through they had potentially years, but because Helmut ended up triggering an edge case in which apt interacts with dpkg in this way and only after that people looked for how to trigger it with dpkg because triggering it with apt is hard (= as Helmut checked, no package (pair) in current unstable is known to exhibit the required setup). (I will write another mail in another subthread about the finer details of what interacting with dpkg in an upgrade means and what might be problematic if you aren't careful – in general, not just with aliasing) Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Bug#1057755: Qt WebEngine Security Support In Stable
Hi Soren, On Thu, Dec 21, 2023 at 12:48:44PM -0700, Soren Stoutner wrote: > On Thursday, December 21, 2023 3:00:23 AM MST Dmitry Shachnev wrote: > > Just one particular class (QQuickWebEngineDownloadItem) is private. My guess > > is that it’s upstream oversight, because upstream documentation even > > mentions > > that one needs to call QWebEngineDownloadRequest::accept() [1], yet calling > > that method is not possible without including a private header. > > > > [1]: https://doc.qt.io/qt-6/qquickwebengineprofile.html#downloadRequested > > There is both a public and a private version of the header for this class, > similar to a lot of classes in Qt WebEngine. > > The public versions of this header are contained in > `qquickwebengineprofile.h` > and `qwebenginedownloadrequest.h` in the qt6-webengine-dev package. No, they are both not of _this_ header. QQuickWebEngineProfile ≠ QQuickWebEngineDownloadRequest QWebEngineDownloadRequest ≠ QQuickWebEngineDownloadRequest Maybe my previous emails were not clear enough, let me try again. Qt has two different interface systems: Qt Widgets and Qt Quick. Qt Widgets can be used from C++ only. Qt Quick is intended for use from QML, but sometimes it can be controlled from C++ code, that's why there are C++ classes for it too. Many Qt modules, including Qt WebEngine, provide classes for both interface systems. For example, qt6-webengine source in Debian builds libqt6webenginewidgets6 and libqt6webenginequick6 binary packages. Angelfish is written in Qt Quick, unlike many other browsers which are using Qt Widgets. This is why it needs QQuick* classes, and the widgets classes can not be a replacement. > It isn’t clear to me why Qt feels the need to have private headers that > mirror > their public headers for many of their functions. This way you can easily change private ABI (e.g. add a new argument) without breaking the public interface. See https://wiki.qt.io/D-Pointer for details. > And there may be some way in which Qt borked their public QML implementation > of this particular class in such a way that one really does need to depend > on the private headers (in which case, as Dmitry has pointed out, they > would probably be very willing to fix it if it was reported to them). Probably. Feel free to create an upstream bug report, based on the analysis from my previous email. > But from what I can see by reviewing the code (without taking the time to > actually build a project and test it out myself) it ought to be possible for > Angelfish to just switch to using the public headers. As explained above, no, QQuickWebEngineDownloadRequest does not have a public header. -- Dmitry Shachnev signature.asc Description: PGP signature
Processed: zeromq3 4.3.4-1+deb11u1 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 1053608 = bullseye pending Bug #1053608 [release.debian.org] bullseye-pu: zeromq3/4.3.4-1+deb11u1 Added tag(s) pending; removed tag(s) confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 1053608: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053608 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: symfony 4.4.19+dfsg-2+deb11u4 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 1055988 = bullseye pending Bug #1055988 [release.debian.org] bullseye-pu: package symfony/4.4.19+dfsg-2+deb11u4 Added tag(s) pending; removed tag(s) confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 1055988: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055988 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: gnutls28 3.7.1-5+deb11u4 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 1057137 = bullseye pending Bug #1057137 [release.debian.org] bullseye-pu: package gnutls28/3.7.1-5+deb11u4 Added tag(s) pending; removed tag(s) confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 1057137: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057137 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: swupdate 2020.11-2+deb11u1 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 1056970 = bullseye pending Bug #1056970 [release.debian.org] bullseye-pu: package swupdate/2020.11-2+deb11u1 Added tag(s) pending; removed tag(s) confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 1056970: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056970 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1057137: gnutls28 3.7.1-5+deb11u4 flagged for acceptance
package release.debian.org tags 1057137 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: gnutls28 Version: 3.7.1-5+deb11u4 Explanation: security fix for timing sidechannel attack [CVE-2023-5981]
Bug#1056970: swupdate 2020.11-2+deb11u1 flagged for acceptance
package release.debian.org tags 1056970 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: swupdate Version: 2020.11-2+deb11u1 Explanation: prevent acquiring root privileges through inappropriate socket mode
Bug#1055988: symfony 4.4.19+dfsg-2+deb11u4 flagged for acceptance
package release.debian.org tags 1055988 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: symfony Version: 4.4.19+dfsg-2+deb11u4 Explanation:
Bug#1053608: zeromq3 4.3.4-1+deb11u1 flagged for acceptance
package release.debian.org tags 1053608 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: zeromq3 Version: 4.3.4-1+deb11u1 Explanation:
Processed: bookworm-pu: package fish/3.6.0-3.1+deb12u1
Processing control commands: > affects -1 + src:fish Bug #1059235 [release.debian.org] bookworm-pu: package fish/3.6.0-3.1+deb12u1 Added indication that 1059235 affects src:fish -- 1059235: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059235 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1059235: bookworm-pu: package fish/3.6.0-3.1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: f...@packages.debian.org
Control: affects -1 + src:fish
[ Reason ]
Cherry-pick upstream fix to CVE-2023-49284
[ Impact ]
This is a low severity security issue that affects basically
all historical releases of fish. The upstream created new
releases (i.e. 3.6.2) solely for fixing this bug.
https://github.com/fish-shell/fish-shell/commits/Integration_3.6.2/
So it would be good if we can integrate the fix into stable.
[ Tests ]
The fix is already included in fish/3.6.4-1 (sid).
The rebased patch passed my local sbuild test.
I installed the package in a chroot and tested it.
[ Risks ]
low.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Only one change. Please refer to the patch header for explanation.
[ Other info ]
diff -Nru fish-3.6.0/debian/changelog fish-3.6.0/debian/changelog
--- fish-3.6.0/debian/changelog 2023-05-01 13:01:01.0 -0400
+++ fish-3.6.0/debian/changelog 2023-12-21 14:47:56.0 -0500
@@ -1,3 +1,9 @@
+fish (3.6.0-3.1+deb12u1) bookworm; urgency=medium
+
+ * Cherry-pick upstream fix for CVE-2023-49284.
+
+ -- Mo Zhou Thu, 21 Dec 2023 14:47:56 -0500
+
fish (3.6.0-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru fish-3.6.0/debian/patches/CVE-2023-49284.patch
fish-3.6.0/debian/patches/CVE-2023-49284.patch
--- fish-3.6.0/debian/patches/CVE-2023-49284.patch 1969-12-31
19:00:00.0 -0500
+++ fish-3.6.0/debian/patches/CVE-2023-49284.patch 2023-12-21
14:44:13.0 -0500
@@ -0,0 +1,31 @@
+Description: fixes CVE-2023-49284
+ The CVE report can be found at
+
https://github.com/fish-shell/fish-shell/security/advisories/GHSA-2j9r-pm96-wp4f
+ The corresponding fix can be found at
+
https://github.com/fish-shell/fish-shell/commit/09986f5563e31e2c900a606438f1d60d008f3a14
+ This patch is rebased from the upstream fix.
+diff --git a/src/common.cpp b/src/common.cpp
+index baee97a..0e76bf1 100644
+--- a/src/common.cpp
b/src/common.cpp
+@@ -345,9 +345,7 @@ static wcstring str2wcs_internal(const char *in, const
size_t in_len) {
+ } else {
+ ret = std::mbrtowc(, [in_pos], in_len - in_pos, );
+ // Determine whether to encode this character with our crazy
scheme.
+-if (wc >= ENCODE_DIRECT_BASE && wc < ENCODE_DIRECT_BASE + 256) {
+-use_encode_direct = true;
+-} else if (wc == INTERNAL_SEPARATOR) {
++if (fish_reserved_codepoint(wc)) {
+ use_encode_direct = true;
+ } else if (ret == static_cast(-2)) {
+ // Incomplete sequence.
+@@ -1323,6 +1321,9 @@ maybe_t read_unquoted_escape(const wc
+ }
+
+ if (result_char_or_none.has_value()) {
++if (fish_reserved_codepoint(*result_char_or_none)) {
++return none();
++}
+ result->push_back(*result_char_or_none);
+ }
+
diff -Nru fish-3.6.0/debian/patches/series fish-3.6.0/debian/patches
--- fish-3.6.0/debian/patches/series2023-05-01 13:01:01.
+++ fish-3.6.0/debian/patches/series2023-12-21 14:44:23.
@@ -1,3 +1,4 @@
0001-reader-make-Escape-during-history-search-restore-com.patch
0002-reader-Remove-assert-in-history-search.patch
0003-workaround-for-Midnight-Commander.patch
+CVE-2023-49284.patch
Re: /usr-move: Do we support upgrades without apt?
Am 21.12.23 um 11:50 schrieb Christoph Berg: Re: Helmut Grohne Is it ok to call upgrade scenarios failures that cannot be reproduced using apt unsupported until we no longer deal with aliasing? If the answer is yes here, we'll close #1058937 (Ben's libnfsidmap1 bug) with no action calling the scenario unsupported. I think we should only deal with problems that can reasonably happen in practice. If an extra hammer is required to hit the problem, we should not spend extra effort on it. A (dist-)upgrade not using apt is very much a corner case/niche use case. I'd be interested if #1058937 can be reproduced using aptitude, though. While the release notes explicitly recommend using apt/apt-get, I do think that dist-upgrades using aptitude should not run into those file loss issues. If aptitude is safe, I'd consider #1058937 a bug, that is not release critical and I'd assign low(er) priority to it. Other issues, like getting all packages updated to move their files to /usr, have higher priority. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Re: /usr-move: Do we support upgrades without apt?
On Thu, 21 Dec 2023 at 15:31:55 +0100, Marc Haber wrote: > Do those GUI frontends that work via packagekit or other frameworks > count as "using apt"? Managing apt/dpkg packages via packagekit uses libapt-pkg6.0 (via /usr/lib/*/packagekit-backend/libpk_backend_apt.so). I don't know whether that's enough to give it the specific desirable behaviour around Conflicts that Helmut is referring to, but I hope it is. Other non-CLI package management like unattended-upgrades is generally in a similar situation, using libapt-pkg or its language bindings, but not the apt(8) or apt-get(8) CLIs specifically. smcv
Re: /usr-move: Do we support upgrades without apt?
Hi, On 21/12/2023 09:41, Helmut Grohne wrote: Is it ok to call upgrade scenarios failures that cannot be reproduced using apt unsupported until we no longer deal with aliasing? I incline towards "no"; if an upgrade has failed part-way (as does happen), people may then reasonably use dpkg directly to try and un-wedge the upgrade (e.g. to try and configure some part-installed packages, or try installing some already-downloaded packages). It may be that the mitigations necessary are worse than the risk, but I think the behaviour as described in #1058937 is definitely buggy. Regards, Matthew
Re: /usr-move: Do we support upgrades without apt?
On Thu, Dec 21, 2023 at 11:19:48AM -0300, Antonio Terceiro wrote: > On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote: > > Is it ok to call upgrade scenarios failures that cannot be reproduced > > using apt unsupported until we no longer deal with aliasing? > > I think so, yes. I don't think it's likely that there are people doing > upgrades on running systems not using apt. Do those GUI frontends that work via packagekit or other frameworks count as "using apt"? I now that WE recommend using apt in a text console outside of X, but even many of our own users do what their Desktop Environment does, and our downstreams like *b*nt* recommend other ways to upgrade as well. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: /usr-move: Do we support upgrades without apt?
On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote: > ## Upgrading using dpkg directly? > > We already have quite a number of packages that use Conflicts to prevent > file loss in upgrades in a very similar way to #1058937 (Ben's > libnfsidmap1 bug) even in released versions of Debian. For instance, > dhcpcd-base's Replaces were upgraded to Conflicts, see #1053657. If you > employ dpkg, you can still experience the problem there. > > Is it ok to call upgrade scenarios failures that cannot be reproduced > using apt unsupported until we no longer deal with aliasing? I think so, yes. I don't think it's likely that there are people doing upgrades on running systems not using apt. If there are, they already need to deal with doing the dpkg calls in the right order anyway -- basically doing the apt dependency resolution by hand -- that this is just another corner case that they need to handle; there could be already Conflicts in there for other reasons than /usr-merge. signature.asc Description: PGP signature
Bug#1059226: release.debian.org: Help doris migrate to testing
Package: release.debian.org Severity: normal X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org doris (5.0.3~beta+dfsg-17) is not migrating to testing, the excuses suggest this is due to superficial autopkgtests: https://qa.debian.org/excuses.php?package=doris Should this really block testing migration? Shouldn't it just not reduce the age? Kind Regards, Bas
Re: /usr-move: Do we support upgrades without apt?
Re: Helmut Grohne > Is it ok to call upgrade scenarios failures that cannot be reproduced > using apt unsupported until we no longer deal with aliasing? > > If the answer is yes here, we'll close #1058937 (Ben's libnfsidmap1 bug) > with no action calling the scenario unsupported. I think we should only deal with problems that can reasonably happen in practice. If an extra hammer is required to hit the problem, we should not spend extra effort on it. Christoph
/usr-move: Do we support upgrades without apt?
Hi, this installment serves a dual purpose. Let me first give an update of the status quo and then pose a consensus question on how we want to deal with a particular problem. I Cc d-release@l.d.o as upgrades are an integral part of releases. I Cc d-ctte@l.d.o for advisory feedback with experience due to earlier decisions on merged-/usr. # Status As I detailed earlier, diversions have been proving more difficult than anticipated. I spent significant time on molly-guard to get to a working mitigation and thanks to Francois and Daniel, all of the diverters of /sbin/halt and others have been updated in experimental for wider testing. This is looking promising and passing all testing that has been performed thus far. Meanwhile Chris Hofstaedler and kind folks in Cambridge worked a lot on M-A:same shared file loss (DEP17 P7) and got us down to one (reintroduced) issue. Pending further reintroductions, this aspect is done. Cool! I've since uploaded debhelper and dh_installudev will now also install to /usr. udevdir in udev.pc has been changed in a NEW upload to experimental as well and is expected to hit unstable before too long (thanks Michael and Luca). Earlier, I requested a pause of /usr merges. Since we have a better understanding and solutions that seem to be working now, I am happy for you to move stuff again more widely. For moves involving diversions in any way, consider having me review your change ahead of upload. At the time of this writing, there are 1237 source packages in unstable that still ship something aliased. This is the number we need to get down to 0 for trixie. Of these 860 involve a systemd unit and of these 761 only have systemd units aliased many of which can be converted by a no-change upload due to changed debhelper and systemd.pc behaviour. # The problem with conflicts The idea in DEP17 was to use Conflicts as a mitigation strategy in agreement with a naive reading of Debian policy. As it turns out, that doesn't exactly match reality (#1057199 debian-policy) and there are situations where files can be lost despite Conflicts having been declared. In theory, this subtlety should be irrelevant and unobservable, but aliasing (which breaks dpkg's assumptions) makes this observable. We move a file from / to /usr in $PKGA. AND one of The file is also being moved to a different package (causing DEP17 P1). OR The file is being diverted (causing DEP17 P3). AND The mitigation involves declaring a Conflict for unpack ordering (i.e. M7 for P1 or M18 for P3). AND one of The upgrade is being performed using a direct dpkg invocation without apt in a way that unpacks the package declaring the conflict before the conflicted package is removed. Example: #1058937 (Ben's libnfsidmap1 bug) OR The involved packages declare a mutual conflict (or mutual conflicts + breaks) and therefore apt invokes dpkg as in the earlier point. Example: An earlier version of the molly-guard mitigation declared versioned Breaks for systemd-sysv. This condition is complex, so let me try to break it down into something simpler. We'll have somewhere between 20 and 100 instances of P1 + P3 I guess and we aimed for mitigating most of them using Conflicts (i.e. first two conditions). The horny part is the last one. It basically says that as long as we only ever use apt and avoid mutual conflicts, the issue is not practically observable. That mutual conflict condition is delicate on its own. There are basically two ways to trigger it. The way my molly-guard patch did it was having two versioned Conflicts or Breaks declarations. I checked the archive and there is no instance of any package combination doing this. Hypothetically, another way to trigger this is unversioned Conflicts combined with a package that drops Provides in a later version (thanks David), but we haven't seen any practical instance and I haven't figured a good way to gauge this problem yet. ## Options (combinations possible) When mitigating P1, we can opt for protective diversions (M8) instead of Conflicts (M7), though that is more fragile. When mitigating P3, we can avoid the mutual conflicts. For molly-guard that has been more involved, but it seems manageable. For other packages (that do not need to access diverted files), it becomes simpler. We can restore lost files in a postinst. For this to work, we must duplicate (e.g. hard link) affected files in the data.tar. Example: #1057220 (systemd-sysv upgrade file loss) Note that this approach is not policy compliant for essential packages as they must work when unpacked and this is relevant for gzip being diverted by zutils for instance. We can introduce "barrier" packages (one or more) and have them enforce conflicting packages removed before the conflictor being unpacked (thanks Julian). We can - and this is the crux of the matter - argue that upgrading with bare dpkg is unsupported and you get to keep the pieces if you do so anyway.
Re: Bug#1057755: Qt WebEngine Security Support In Stable
On Wed, Dec 20, 2023 at 02:06:28PM -0700, Soren Stoutner wrote: > I must admit that I have no personal experience with connecting QML and C++. I don’t have any personal experience with that too. > But it seems to me from the documentation Qt has produced there are several > ways to bridge the two without accessing private headers. > > https://doc.qt.io/qt-5/qtqml-cppintegration-overview.html > > Beyond what is written there, Angelfish deals with a lot of classes besides > WebEngineDownloadItem. Somehow, with all the others, they are able to do > what they need to do without accessing private headers, which would > indicate to me that there must be some way to do it in this case as well. I didn’t say that you need private headers for _any_ stuff like that. Just one particular class (QQuickWebEngineDownloadItem) is private. My guess is that it’s upstream oversight, because upstream documentation even mentions that one needs to call QWebEngineDownloadRequest::accept() [1], yet calling that method is not possible without including a private header. [1]: https://doc.qt.io/qt-6/qquickwebengineprofile.html#downloadRequested -- Dmitry Shachnev signature.asc Description: PGP signature
