Bug#1110033: unblock: openssh/1:10.0p1-6

[Ivo De Decker <ivodd@debian.org>]

Hi Colin,

On Mon, Jul 28, 2025 at 12:54:40PM +0100, Colin Watson wrote:
> The self-diversion approach is a bit alarming, but it limits the scope 
> of the workaround code to just the affected upgrade scenarios, and the 
> code is mechanically simple enough even if it requires some careful 
> thinking.  I can't think of any better approaches.

I'm leaning towards unblocking this, as it's probably the least bad option. I
wonder if there are any corner cases where the result of this change is worse
than not doing it.

Fortunately, I haven't been able to come up with such a case yet.

Some questions:

Can you think of any scenario where the system would end up without a
/usr/sbin/sshd binary?


What happens if the system crashes during the upgrade, after the diversion is
added, but before it is removed? Will sshd work after reboot (it's possible
that sshd wouldn't work in this scenario without the change anyway)? If not,
will it work after the upgrade is finished (by an admin connected in a
different way)?


Can you think of a scenario where dpkg thinks the upgrade of openssh-server is
done, but the diversion is still there? In that case, even (purging and)
reinstalling openssh-server won't help, because the code removing the
diversion will no longer be triggered.


Thanks,

Ivo