On 11/07/25 at 19:20 +0100, Mark Hindley wrote:

Control: tags -1 unreproducible

Lucas,

Thanks for this. I am afraid I am unable to reproduce.

On Tue, Jul 08, 2025 at 01:58:19PM +0200, Lucas Nussbaum wrote:

I suppose that this happens if exim4-base is unpacked but not configured before utrans-rc is configured, but I'm not sure.

There might be a potential issue in that /etc/init.d/exim is in exim4-base whereas /usr/lib/systemd/system/exim4.service is in exim4-daemon-light.

Having said that, I cannot generate a failure by installing utrans-rc and exim4-base or exim4-daemon-light. It would seem that your error is caused by utrans-rc producing /etc/init.d/exim4 from /usr/lib/systemd/system/exim4.service
before exim4-base is installed. But exim4-daemon-light depends on exim4-base, so
I don't currently see how that can happen.

Do you have a reliable reproducer?

Yes, using incus:
incus launch images:debian/13 d13 --vm --type c2-m4
# or: incus launch images:debian/13 d13
incus exec d13 -- apt-get -y install utrans-rc

Or mmdebstrap:
mmdebstrap --variant=minbase --chrooted-customize-hook='apt update && apt -o APT::Install-Recommends=yes install -y utrans-rc' trixie /dev/null
(Inspired from Zeha's reproducer in #1108944)

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul,

Thanks for this.

On Sat, Jul 19, 2025 at 10:58:02AM +0200, Paul Gevers wrote:

On Sat, 12 Jul 2025 15:38:41 +0100 Mark Hindley <mark@hindley.org.uk> wrote:

+ # Remove any timestamp to force regeneration of all scripts.
+ rm -f /var/tmp/${DPKG_MAINTSCRIPT_PACKAGE}.stamp

This is a very predictable path. Normally those have security concerns as anybody on the system can create this file between here and where it's used. Were those considered? (I haven't checked the code, I only read the patch here).

I did think about it when I first used that path: only the mtime of the .stamp file is used (passed to find's -ctime option). I couldn't think of an adverse security implication. Although, maybe I am not sufficiently imaginative? What have I missed or not considered?

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul,

On Mon, Jul 21, 2025 at 06:27:33PM +0200, Paul Gevers wrote:

If the timestamp is put in the (far) future, the action you want to trigger might not happen. What is the timestamp used for?

To filter the list of systemd units that are reprocessed: only those modified more
recently than the timestamp are converted again to see if the generated output is different.

So, updating of already generated files could be prevented by changing the time.stamp file mtime. I saw that as pointless rather than a security issue.

If you think I have underestimated the significance and impact, the file could be moved under /var/lib/?

Thanks for your time with this.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)