Your message dated Wed, 14 May 2025 03:25:01 +0200
with message-id <20250514012501.52szouhs7yxzf...@mraw.org>
and subject line Re: Bug#1105179: unblock: openssh/1:10.0p1-5
has caused the Debian Bug report #1105179,
regarding unblock: openssh/1:10.0p1-5
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1105179: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105179
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: open...@packages.debian.org
Control: affects -1 + src:openssh
User: release.debian....@packages.debian.org
Usertags: unblock
I know the hard freeze hasn't started yet, but this openssh upload isn't
quite going to make it into testing in time, and since it's a key
package you're going to need to review it anyway; so I might as well get
the request in early. This fixes one grave bug (#1103418), one serious
bug (#1104992, filed after the upload so not in the changelog) and one
important bug (#1103522). All the changes are as targeted as I believe
to be possible.
The --with-linux-memlock-onfault change is probably the only non-obvious
one; see https://bugzilla.mindrot.org/show_bug.cgi?id=3822 for more
details there. It's basically just restoring previous behaviour, since
that option and the behaviour associated with it were new in 10.0p1.
openssh has pretty extensive autopkgtests. Admittedly they didn't catch
these issues (although I have my suspicions that the riscv64 autopkgtest
failures that I fixed by disabling --with-linux-memlock-onfault just on
riscv64 in 1:10.0p1-2 were in fact the canary in the coalmine), but they
do provide decent assurance that openssh still works in general.
unblock openssh/1:10.0p1-5
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru openssh-10.0p1/debian/changelog openssh-10.0p1/debian/changelog
--- openssh-10.0p1/debian/changelog 2025-04-15 14:19:35.000000000 +0100
+++ openssh-10.0p1/debian/changelog 2025-05-09 13:40:49.000000000 +0100
@@ -1,3 +1,25 @@
+openssh (1:10.0p1-5) unstable; urgency=medium
+
+ * Ensure that configure knows the path to passwd; fixes reproducibility of
+ openssh-tests.
+
+ -- Colin Watson <cjwat...@debian.org> Fri, 09 May 2025 13:40:49 +0100
+
+openssh (1:10.0p1-4) unstable; urgency=medium
+
+ [ Daniel Kahn Gillmor ]
+ * Add Requires=ssh-agent.socket to ssh-agent.service (closes: #1103522).
+
+ -- Colin Watson <cjwat...@debian.org> Fri, 09 May 2025 10:16:45 +0100
+
+openssh (1:10.0p1-3) unstable; urgency=medium
+
+ * Disable --with-linux-memlock-onfault again, since it causes
+ RLIMIT_MEMLOCK to be exceeded with some combinations of PAM modules
+ (closes: #1103418).
+
+ -- Colin Watson <cjwat...@debian.org> Wed, 07 May 2025 16:18:43 +0100
+
openssh (1:10.0p1-2) unstable; urgency=medium
[ Colin Watson ]
diff -Nru openssh-10.0p1/debian/rules openssh-10.0p1/debian/rules
--- openssh-10.0p1/debian/rules 2025-04-15 14:19:35.000000000 +0100
+++ openssh-10.0p1/debian/rules 2025-05-09 13:40:49.000000000 +0100
@@ -74,6 +74,10 @@
confflags += ossh_cv_cflag__fzero_call_used_regs_used=no
endif
+# passwd isn't otherwise needed and may not be installed at build time.
+# Ensure that sshd knows its path.
+confflags += PATH_PASSWD_PROG=/usr/bin/passwd
+
# Everything above here is common to the deb and udeb builds.
confflags_udeb := $(confflags)
@@ -88,11 +92,6 @@
confflags += --with-selinux
confflags += --with-audit=linux
confflags += --with-security-key-builtin
-# On riscv64, this causes failures in ed25519-sk keytype tests, for unclear
-# reasons.
-ifneq ($(DEB_HOST_ARCH),riscv64)
-confflags += --with-linux-memlock-onfault
-endif
endif
# The deb build wants xauth; the udeb build doesn't.
diff -Nru openssh-10.0p1/debian/systemd/ssh-agent.service
openssh-10.0p1/debian/systemd/ssh-agent.service
--- openssh-10.0p1/debian/systemd/ssh-agent.service 2025-04-15
14:19:35.000000000 +0100
+++ openssh-10.0p1/debian/systemd/ssh-agent.service 2025-05-09
13:40:49.000000000 +0100
@@ -1,6 +1,7 @@
[Unit]
Description=OpenSSH Agent
Documentation=man:ssh-agent(1)
+Requires=ssh-agent.socket
[Service]
Environment=SSH_ASKPASS_REQUIRE=force
--- End Message ---
--- Begin Message ---
Hi,
Colin Watson <cjwat...@debian.org> (2025-05-12):
> I know the hard freeze hasn't started yet, but this openssh upload isn't
> quite going to make it into testing in time, and since it's a key
> package you're going to need to review it anyway; so I might as well get
> the request in early. This fixes one grave bug (#1103418), one serious
> bug (#1104992, filed after the upload so not in the changelog) and one
> important bug (#1103522). All the changes are as targeted as I believe
> to be possible.
>
> The --with-linux-memlock-onfault change is probably the only non-obvious
> one; see https://bugzilla.mindrot.org/show_bug.cgi?id=3822 for more
> details there. It's basically just restoring previous behaviour, since
> that option and the behaviour associated with it were new in 10.0p1.
>
> openssh has pretty extensive autopkgtests. Admittedly they didn't catch
> these issues (although I have my suspicions that the riscv64 autopkgtest
> failures that I fixed by disabling --with-linux-memlock-onfault just on
> riscv64 in 1:10.0p1-2 were in fact the canary in the coalmine), but they
> do provide decent assurance that openssh still works in general.
>
> unblock openssh/1:10.0p1-5
openssh popped up on my radar when it came to picking and choosing which
packages would make sense to have in D-I Trixie RC 1, and which ones
could or should wait
(https://lists.debian.org/debian-release/2025/05/msg00524.html).
While I'm not usually reviewing unblock requests (and haven't been for
years), I'll take charge (and blame of course) of this one.
Your description of the recent changes match my “it seems we really want
to have this in testing” sentiment before sending the aforementioned
mail (even if nothing was required as far as d-i is concerned), and your
reply in the other thread confirms that waiting some more doesn't seem
warranted (the latest upload being 5/10 days old already).
Let's have this into testing now, then; thanks!
Cheers,
--
Cyril Brulebois (k...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
--- End Message ---
