This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Feature request: improved build-id generation


Hi all-

The current build-id generation algorithm choices are all problematic.

 --build-id=uuid: incompatible with reproducible builds

 --build-id=md5, sha1: MD5 and SHA1 are deprecated.  Also, having
identical input produce identical output is problematic for distros.
In particular, it's useful for distros to be able to guarantee that
the build-ids from different package versions are different even if
the relevant parts of the binaries are coincidentally identical.

--build-id=0xhexstring: avoiding accidental collisions is unpleasant,
and how is anyone supposed to come up with an intelligent choice for
0xhexstring?

I would like to request a new variant.

--build-id=sha512256: The build-id is
HMAC-SHA512/256("build-id-sha512256", relevant parts of output)  If
one of more --build-id-key options are specified, then it's
HMAC-SHA512/256("build-id-sha512256-keyed" + ("-" || decimal length of
key || key) for each --build-id-key option, output).

These have several benefits.  They are fully deterministic.  They give
distros the flexibility to differentiate their build-ids.  They use
only non-deprecated crypto (and SHA512/256, unlike SHA256, is
resistant to length-extension, which is of admittedly dubious value
here).

The reason to accept multiple --build-id-key options is to allow
programmers to use --build-id-key for their own purposes without
interfering with additional --build-id-key options added by the
distro.

(There's no real need for HMAC, but merely concatenating the two
arguments and using plain SHA256/512 would be slightly problematic.
There would need to a delimiter not in the set "-0123456789" or
something similar).

If you all think I should file a bug to request this feature, let me
know and I'd be glad to.

--Andy

P.S. This whole email is a response to a feature that Laura requested
in a separate private email.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]