Seed filesystem UUIDs with SOURCE_DATE_EPOCH + offset

[schaefi]

For reproducible builds the calculation of the filesystem UUID should be persistent with each rebuild of the image. To achieve this the UUID is calculated using the label name as seed. Only in case the filesystem has no label assigned the UUID stays random and changes with each rebuild. In addition to this change a new label attribute has been added to the <partition> section. This Fixes #2761

[schaefi]

waiting for integration tests to complete

[Conan-Kudo]

I'm confused? I think the idea was the control the PRNG, not use the label itself as a seed.

This creates some weird effects, particularly when images aren't intentionally doing this. For example, Fedora Asahi Remix systems all have the partition label "fedora" (as do Fedora Cloud images). Having a fixed UUID automatically derived from the label means that it's now impossible to produce disk images on those systems since the UUIDs and labels match, creating mount confusion.

[schaefi]

I'm confused? I think the idea was the control the PRNG, not use the label itself as a seed.

This creates some weird effects, particularly when images aren't intentionally doing this. For example, Fedora Asahi Remix systems all have the partition label "fedora" (as do Fedora Cloud images). Having a fixed UUID automatically derived from the label means that it's now impossible to produce disk images on those systems since the UUIDs and labels match, creating mount confusion.

Hmm, I can't follow you on this. label and uuids are not the same. For the calculation of the UUID the "randomness" is disabled by providing a seed, such that a rebuild of the image comes with the same UUID. The systemd provided standard UUID definitions for partitions are the same UUIDs for the same type of partition. This code now "standardize" the filesystem UUID according to its label. Example:

kiwi applies the label name 'ROOT' for the rootfs. This will then result in the following UUID for the rootfs

import random
import uuid
from functools import reduce
label='ROOT'
label_seed = reduce(lambda x, y: x + y, map(ord, label))
rd = random.Random()
rd.seed(label_seed)
print(uuid.UUID(int=rd.getrandbits(128)))

• dbbfa6df-b766-9114-2b15-e2da971029da

And it will be the same as long as the label is the same. For the custom partitions (those you specify yourself) you can specify a custom label which is used as the seed for the UUID. That way you create a connection between your label and your UUID but I don't see any conflict

If no label exists, we stay random

?

[schaefi]

All tests passing, but we need to clarify what we really want to achieve. Maybe also a topic for tomorrows community meeting

[schaefi]

I can imagine a device conflict for the following condition:

• you build two different images
• kiwi uses systemd defined partition UUIDs and with this change kiwi uses label defined filesystem UUIDs
• the two images are deployed on two disk of the same machine
• on boot it wouldn't be possible to differentiate the device from one or the other disk because /dev/disk/by-partuuid and /dev/disk/by-uuid would offer the same for both disks and by default by-uuid is used for booting.

How likely is this ? systemd is aware of this conflict when systems are setup to boot using the standard IDs

I believe we should at least add an opportunity to configure the seed for those filesystems where it is currently not possible (root, boot, swap)

[Conan-Kudo]

I think it's likely enough that I'd be concerned. The idea that @davide125 and @supakeen had was to allow setting a time-value seed for UUIDs (e.g. SOURCE_DATE_EPOCH variable if available).

[schaefi]

So then let's update the code to make use of SOURCE_DATE_EPOCH if available

[schaefi]

The problem here is that you can't use SOURCE_DATE_EPOCH for all filesystems because that would create UUID conflicts. So how do we want to differentiate them ?

SOURCE_DATE_EPOCH + 1
SOURCE_DATE_EPOCH + 2
...

and so on ?

[Conan-Kudo]

I would use -1 instead of +1 (it is a time signature), but otherwise yeah.

[davide125]

Yeah, I agree with @Conan-Kudo, it's not at all uncommon to deploy multiple images on the same system. Using SOURCE_DATE_EPOCH - offset seems reasonable to me.

[schaefi]

all right, so let's take SOURCE_DATE_EPOCH into account

[Conan-Kudo]

We currently cannot set the fliesystem label for the ESP (or even mount options), which is why we have this in Fedora's kiwi descriptions: https://pagure.io/fedora-kiwi-descriptions/blob/rawhide/f/root/etc/fstab.script

[schaefi]

We currently cannot set the fliesystem label for the ESP (or even mount options), which is why we have this in Fedora's kiwi descriptions: https://pagure.io/fedora-kiwi-descriptions/blob/rawhide/f/root/etc/fstab.script

Hmm, I don't get that part. So with this change here, the EFI filesystem will be created like this

[ INFO    ]: 09:39:20 | Using UUID seed SOURCE_DATE_EPOCH:42 + LABEL:EFI=212
...
[ DEBUG   ]: 09:39:20 | EXEC: [mkdosfs -F16 -I -n EFI -i 68FAD047 /dev/loop0p1]

So you are saying we have a problem here ?

[Conan-Kudo]

We need a way to set the shortname behavior and mount settings for the ESP because they affect the reproducibility of image. This should be a separate pull request, though.