The refactoring should be done or mostly done. We had talked about keeping a sync feature in derivative-maker-docker, but I ended up removing it entirely after all because it messes with a derivative-update feature that (sorta) removes the need for initial manual verification. Specifically, derivative-update will import GPG keys into the user’s main keyring, then use them to verify the repo’s current state in addition to the commit, branch, or tag the user is trying to update to. This provides trust-on-first-use (TOFU), which isn’t bulletproof but it a lot better than just never verifying at all. As long as the user is “lucky” enough to get an uncompromised repo the first time, future compromises should be guarded against. (This works in practice with SSH pretty well in a lot of scenarios, and while a high-risk user won’t want to stake their safety on it, it will at least provide lower-risk users an additional layer of safety.)
derivative-maker-docker uses a different keyring than the user’s normal keyring, which messes with this mechanism a bit. Depending on how the user does things, they may end up trusting unverified code more than once, which adds additional danger. (This would happen if a user cloned the repo, immediately ran derivative-maker-docker-run to do a build, then later used derivative-update manually to update. It would also happen again any time the user wiped the Docker key volume or moved it to a new location.)
There is an issue with derivative-maker-docker I’ve not been able to fix, which is that when building a VirtualBox VM image, the resulting image is only bootable when using UEFI firmware, not BIOS firmware. The problem is described in detail in amd64 images build under a Debian 12 Docker image end up with no BIOS bootloader due to `lsblk` malfunctioning · Issue #348 · grml/grml-debootstrap · GitHub and `lsblk` fails to report partition type UUIDs within a privileged Debian 12 container · Issue #50304 · moby/moby · GitHub. In summary, lsblk needs some bits of udev to be able to display partition type UUIDs. systemd-udevd.service needs to be running in the container, and we need to run udevadm trigger on loop devices at specific points in the build process (possibly within grml-debootstrap itself). I wasn’t able to solve this on my own yet, because I ran into weird issues with kpartx (it was able to recognize the partitions in a loop device, but it couldn’t make the device-mapper devices corresponding to each partition, probably due to user error on my part). If we want derivative-maker-docker to work fully in the near future, we’ll probably need to solve this. If we’re willing to wait a while, newer versions of lsblk should allow us to avoid the need for udev, so once Kicksecure ports to Trixie, this might be a lot easier to resolve.