package: debian-security-support severity: serious Hi,
In https://bugs.debian.org/974552 dpkg runs the debian-security-support hook in a situation where perl is broken. This makes the hook fail, and aborts dpkg and apt, leaving the system in a very bad state. More on the exact situation below. Even though debian-security-support clearly isn't at fault here, the debian-security-support should never cause dpkg/apt to fail. Based on that, I think it might be good if debian-security-support would make 2 changes: - in /etc/dpkg/dpkg.cfg.d/debian-security-support, make sure the hook can never fail (eg by adding '|| /bin/true' in the appropriate place) - in /usr/share/debian-security-support/check-support-status.hook check if perl is functional before trying to do anything. If perl is not functional, just do nothing (and exit successfully). This would be somewhat similar to what glibc is doing here: https://salsa.debian.org/glibc-team/glibc/commit/04373a4e6df6b3c61fa4bbf78f8409aadc7d2753 Longer term, it might be useful to investigate whether is might make more sense to use an apt hook instead of a dpkg hook. Ideally this would allow the user to abort the installation before the unsupported package is installed, instead of getting a notice afterwards. Obviously this should be done in a way that doesn't cause apt to abort in the middle of an upgrade. I don't know if apt currently provides an appropriate hook to do this. Some background on the issue in #974552: In buster, libcrypt.so is shipped by libc6. In bullseye, it is shipped by libcrypt1. During the upgrade from buster to bullseye, it seems a situation can occur that causes the new libc6 (without libcrypt.so) to be unpacked before the new libcrypt. At that point, libcrypt.so is missing, so anything that needs it (like perl) is broken. Fixing this issue is what #974552 is about. However, it seems that in some upgrades, the debian-security-support hook is started in such a situation where libcrypt.so is missing. The standard assumption that perl should be functional at all times is broken by this. Clearly, this is not caused by debian-security-support and this should be fixed. Furthermore, there is the risk that maintainer scripts might hit the same issue, even if debian-security-support doesn't. However, it's unclear if the situation can be avoided in all scenarios. If a situation occurs where the debian-security-support hook runs on a broken system, there's no point in trying to do something useful and failing. The best that can be done is making sure dpkg/apt can continue, hoping that the breakage will be fixed later on. Thanks, Ivo
