On Tue, Mar 10, 2026 at 04:42:47PM +0000, Colin Watson wrote: > Control: tag -1 patch > > On Tue, Mar 10, 2026 at 10:07:59AM -0400, Nicolas Mora wrote: > > Le 2026-03-03 à 14 h 17, Nicolas Mora a écrit : > > > I'm the maintainer for the package libssh2, and recently, a FTBFS bug > > > was opened due to test_sshd tests fail [1]. > > > > > > In the build log, the tests test_sshd.test 1 and test_sshd.test 2. > > > > > > The logs mentions a lot of messages like this: > > > "# User sbuild not allowed because account is locked". > > > > > > I didn't make any changes to the libssh2 package for a while and the > > > package did built until january. > > > > > > I'm wondering if a default configuration in openssh changed recently > > > that could cause this ftbfs? > > > > I've sent a mail last week about a bug in the package libssh2, but it hasn't > > been answered yet. Can you help me about the bug #1129134 ? > > Sorry for missing this. > > debbisect is great for tracking down this sort of thing...
That was a great tip about debbisect, thanks! But see below :) [snip] > So that would seem to point to: > > [ Luca Boccassi ] > * openssh-client: use sysusers.d instead of manual scripting. > * openssh-client: drop compat postinst not needed since bookworm/noble. > * openssh-client: drop versioned dependency on i-s-h, satisfied since > trixie/noble. > * openssh-client: drop dependency on passwd, add recommends on > openssh-server. > * Use dh-sequence-installsysusers and drop d/rules override. > > This made me wonder if there might be an implicit dependency on passwd > hiding somewhere in your test suite. And indeed, this patch fixes your > build: > > diff --git a/debian/control b/debian/control > index cd6d6825..f53ff4e9 100644 > --- a/debian/control > +++ b/debian/control > @@ -7,6 +7,7 @@ Build-Depends: dpkg-dev (>= 1.22.5) > , libssl-dev > , zlib1g-dev > , openssh-server <!nocheck> > + , passwd <!nocheck> > Standards-Version: 4.7.0 > Homepage: https://libssh2.org/ > Rules-Requires-Root: no TL;DR: I do not really believe this is a correct fix; it only works by happy accident :) Much, much longer stream-of-consciousness explanation: So my attention was drawn to this bug after I fixed a similar one in my remrun package (#1129148). However, I fixed mine by disabling the build-time test and only leaving the test suite to run at autopkgtest time when I control the horizontal... erm, I mean, when I can control the setup, user accounts, and everything. It appeared kind of obvious to me that if I cannot rely on a non-locked user account at build time, I should not rely on a non-locked user account at build time :) Now imagine my surprise when Santiago Vila challenged my fix for #1129148 - he asked me whether a more correct fix would be to add a dependency on the passwd package and he pointed me here. So my first reaction was to shoot a brisk e-mail saying "how, exactly, would adding a dependency on passwd suddenly make the account not-locked so the tests would pass?!" ...then I decided to not be glib and actually look into it, since you seemed to believe that this is the correct fix here... and it turns out the situation is even more surprising. So what do the Debian package builds of libssh2 and remrun have in common? - they want to run /usr/sbin/sshd from a non-root account at build time - they both use Rules-Requires-Root: no (either by default, or specified by dpkg-build-api (= 1) in remrun's case) - they do not attempt to unlock any accounts in any way - they both fail to build now that passwd is not installed Looking into the openssh-server source, I realized that sshd will only consider the account locked if it can read the password entry and the password field starts with a '!' (okay, it's a bit more complicated than that, it has more logic for more OS's and platforms, but that's what it does on Debian). ...wait... ......wait, wait, wait....... We run sshd from a non-root account. Of course it cannot read /etc/shadow, can it?! So... With the passwd package installed, the user-run /usr/sbin/sshd CANNOT read its own /etc/shadow entry and so it does not know that the sbuild account is locked. With the passwd package NOT installed, the user-run /usr/sbin/sshd CAN absolutely read its /etc/passwd entry (there is no /etc/shadow file) and it DOES notice the "!" character for the locked sbuild account :) So installing the passwd package HIDES the truth from sshd, and the tests pass because sshd simply doesn't know the account is locked :) With that in mind, of course it is up to the libssh2 Debian package maintainers to decide how to handle this. I still believe that disabling the test at package build time and only running it as autopkgtest is correct for the remrun package. Thanks for reading this far :) G'luck, Peter -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
