On Wed, Jun 19, 2019 at 8:16 PM Brian C. Lane <[email protected]> wrote:
> According to comments in misc.c zeros could be mis-interpreted so it > would have to be something else, like the failure value for > generate_random_uint32 of 0xffffffff I think SOURCE_DATE_EPOCH (which is a uint32_t AFAIK) maybe could directly be used as long as it isn't a problem having the same rnd everywhere? > It looks like we're using uuid_generate everywhere so setting a seed > isn't possible as far as I know. It tries really hard to actually be > random :) Isn't uuid_generate using the seeded generator and shouldn't the values be the same if the same seed is used? For example, SOURCE_DATE_EPOCH? > Are partitions really part of the problem? When I've read about > reproducible builds it has been the binaries that have been the focus. In my case (proprietary) I have to deliver a disk image including a partition table (but apparently the filesystem contains a lot of unstable values anyway). > It may make sense to use an environmental variable instead of a switch, > that way it could be overridden without needing to change the tooling > that uses parted/libparted. Is there a standard for forcing a UUID value > like there is with SOURCE_DATE_EPOCH for time? FORCE_UUID or something > like that? If the UUID values should differ (to avoid that two file systems get the same one), couldn't seeding the RND to SOURCE_DATE_EPOCH be a way? The every UUID would be different within one run but each the same in the next. (I think there are details to consider, such as XOR some control vector / constant to avoid that two tools generate the same "rnd" values etc) Steffen
