Disable zchunk and deltarpm before first template boot

[DemiMarie]

This disables zchunk as well as deltarpm, reducing DNF's attack surface. Since zchunk applies to metadata fetches, it must be turned off before the template is installed, as otherwise the template will use it when fetching metadata to check for updates.

This also ensures that users who install packages manually before using Qubes OS's updater get a hardened DNF configuration.

[marmarek]

PipelineRetry

[marmarek]

The description doesn't match the implementation. The implementation uses those options during template build (and also package builds with legacy builder - which isn't mentioned in the description), but does not set it in the dnf config of the built template.
I think the confusion is about prepare-chroot-builder script - it's only used by legacy builder. Template building scripts are in template_rpm dir (where 01_install_core.sh calls into prepare-chroot-base, but not prepare-chroot-builder).

Anyway, I don't like putting too much customization into template builder scripts. If anything, it should be done via some package (either by shipping some config file, if config drop-ins are supported, or by adjusting config in post-install script). This is to ensure uniform result regardless if the user got older template and updated or got newer template directly.

[DemiMarie]

The description doesn't match the implementation. The implementation uses those options during template build (and also package builds with legacy builder - which isn't mentioned in the description), but does not set it in the dnf config of the built template.

That’s a bug 😆.

I think the confusion is about prepare-chroot-builder script - it's only used by legacy builder. Template building scripts are in template_rpm dir (where 01_install_core.sh calls into prepare-chroot-base, but not prepare-chroot-builder).

Anyway, I don't like putting too much customization into template builder scripts. If anything, it should be done via some package (either by shipping some config file, if config drop-ins are supported, or by adjusting config in post-install script). This is to ensure uniform result regardless if the user got older template and updated or got newer template directly.

The purpose of this PR is to ensure that the customization is used during the template build itself.

[marmarek]

This reliably breaks building any non-minimal template (see CI), because it prevents installing package that ships rpmfusion key. Don't do that.

[marmarek]

On Tue, Jun 25, 2024 at 08:46:37PM -0700, Demi Marie Obenour wrote: Which package does this belong in? `core-agent-linux`?

Yes, I think this one.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab