[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1105179: marked as done (unblock: openssh/1:10.0p1-5)

Your message dated Wed, 14 May 2025 03:25:01 +0200
with message-id <20250514012501.52szouhs7yxzfjrb@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 owner@bugs.debian.org
immediately.)


-- 
1105179: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105179
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: openssh@packages.debian.org
Control: affects -1 + src:openssh
User: release.debian.org@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)                              [cjwatson@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 <cjwatson@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 <cjwatson@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 <cjwatson@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 <cjwatson@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 (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: