[parted-devel] reproducible output

[Steffen Dettmer]

Hi,

thanks again for your mail, and time.
Let me repeat that I don't have an actual issue, I solved mine
in another way, I just though it could maybe help others, but
probably it's much too specific and unrealistic as well
(creating a virtual machine appliance image).

On Wed, Jun 19, 2019 at 10:32 PM Brian C. Lane <bcl at redhat.com> wrote:
> > 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?
>
> We can't, it isn't enough bits for GPT UUIDs. We need 128 bits.

The disk GUID?
Beside of course 32 bits fit into 128, using for example XOR with
a constant 128 bit value could be a way.
The value probably constant for each "usage", not globally, what I
meant with "control vector" in my last mail, otherwise disk UUID
could be equal to filesystem UUID or such, and still clashes
could happen.

(I see issues and risks with that approach, sure, and in no way
I can oversee the impacts of such a change of course)

[citation block moved up from below]
> I don't see why you would want to do that -- it's better to just pass in
> a value to use and let the tools decide if they want to use a constant
> or whatever.

Well, because it is a kind of standard mechanism that may be
possible with less changes / impacts. For example, since environment
usually is inherited, it might not be required to change all tools
or the scripts that call these tools, for example to pass all possibly
needed UUIDs in a buildroot make or such. Let assume parted calls
several mkfs tools and some of them support SOURCE_DATE_EPOCH,
they probably automatically would work, without changing parted
to pass new command line options, and change parted to have new
command line options to define the values to be passed, and maybe
change tools calling parted (such as build scripts calling build scripts).

(I'd also prefer a defined and clear way, such as a command line option.
I see (and already met) problems with unexpected inherited env vars.
Using getenv("HTTP_PROXY") is a nice classic example.)

> > 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?
>
> No, uuid_generate uses /dev/urandom

OK, so we need to pass SOURCE_DATE_EPOCH as kernel boot parameter.

He he, no, just kidding :)

Steffen