Feature request: improved build-id generation

Cary Coutant ccoutant@gmail.com
Thu Mar 15 07:45:00 GMT 2018


>> To inject explicit out-of-band data into the hash computation, you
>> could insert an object with nothing but a note section, or even use
>> --defsym to create a symbol table entry with your extra key(s).
>
> Fedora wants to insert extra data into the build-id of all packages in
> its repository, and it does so right now by post-processing the
> package.  This is ugly, and it flat-out doesn't work for the kernel,
> which is apparently breaking a legitimate debugging use case.
>
> I think Fedora should be able to ask its tool chain to insert the
> extra data rather than hacking it in after the fact.  Asking Fedora to
> use --defsym for this purpose is IMO a non-starter, as is asking
> Fedora to come up with some magic .o file and linking it into every
> object.

I understand your objection to the magic .o file, but why exactly is
--defsym a "non-starter"? It's pretty close to what you're asking for
(except for the spelling), it's already available, and it has the
advantage of adding the extra data to the binary in a form where it
can be easily extracted (e.g., with "nm").

I don't understand the need for forcing two otherwise-identical
binaries to have different build ids, simply because they're part of
different distributions. Perhaps it would help if you could explain
why you need that.

> This feature should be available on the command line, and, in
> particular, it should be usable the same way that the toolchain's
> hardening flags are available to rpm.

What does that mean? What makes an option usable the same way that
hardening flags are?

> Cryptography has nothing whatsoever to do with my request.  I think
> that the construction should be set up to make it exceedingly unlikely
> to generate *accidental* collisions, and, since it's so easy to make
> it effectively impossible to generate even intentional collisions, I
> think that's the right approach.  If the binutils crowd would prefer
> to add --build-it-key or equivalent without adding a new hash
> function, i'd be okay with that, but I think it would be silly.

You're making it sound like what you're asking for will require a new
from-the-ground-up feature, rather than just an option to inject
additional data into the hash computation. SHA-2 is 50% slower than
SHA-1 (it's even slower than MD-5 according to the benchmarks I've
seen), and, as far as I can tell, it provides no additional value for
our purposes. SHA-1 may not be the best or the fastest, but it seems
to be a good balance. As I said before, I wouldn't mind adding a new
hash function if it provides value, but that seems to be completely
orthogonal to your request.

-cary



More information about the Binutils mailing list