Feature request: improved build-id generation

[Cary Coutant]

>> > You're confusing security with identification.  The use of these
>> > hashes for identification is fine.  If not, stop using git and rsync.
>>
>> I realize that the security issue here is barely relevant, but git’s use of SHA1 is *not* okay, and git is migrating away for a reason.
>
> Hmm, that's news to me.  Heh, I've always been a bit suspicious of
> git's reliability.  ;-)

I wouldn't mind adding a newer hash function, but I think you're still
overstating the urgency. I don't think the consequences of a build-id
collision would be earth-shattering or unrecoverable.

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).

-cary


On Wed, Mar 14, 2018 at 6:01 PM, Alan Modra <amodra@gmail.com> wrote:
> On Wed, Mar 14, 2018 at 04:40:25PM -0700, Andy Lutomirski wrote:
>>
>>
>> > On Mar 14, 2018, at 4:27 PM, Alan Modra <amodra@gmail.com> wrote:
>> >
>> >> On Wed, Mar 14, 2018 at 10:36:26PM +0000, Andy Lutomirski wrote:
>> >> --build-id=md5, sha1: MD5 and SHA1 are deprecated.
>> >
>> > You're confusing security with identification.  The use of these
>> > hashes for identification is fine.  If not, stop using git and rsync.
>>
>> I realize that the security issue here is barely relevant, but git’s use of SHA1 is *not* okay, and git is migrating away for a reason.
>
> Hmm, that's news to me.  Heh, I've always been a bit suspicious of
> git's reliability.  ;-)
>
>> I wouldn’t suggest that ld change its hash for its own sake, but if a new build-id format is being used anyway, the hash should be improved.
>>
>> >
>> >> --build-id=0xhexstring: avoiding accidental collisions is unpleasant,
>> >> and how is anyone supposed to come up with an intelligent choice for
>> >> 0xhexstring?
>> >
>> > By inserting the output of your hashing algorithm of choice.  For
>> > example
>> > --build-id=0x`sha256sum <file> | sed -e 's, .*,,'`
>> >
>>
>> I thought of that. I think that, if you try this, you’ll find that there is no useful thing that can be inserted where you have <file>. One could perhaps run ld *twice*, but that would be slow and disgusting.  In the context of, say, rpm building a Linux kernel, I think the resulting mess would be unworkable.
>
> Yeah, it's not elegant.  Another option might be to cat the object
> files being linked, and pipe that to sha256sum.  But that has
> drawbacks too.
>
>> Hence the feature request.
>
> Perhaps --build-id-pipe="user_supplied_pipeline" would be a better
> extension?  I'm not offerring to code it up, but I think we have all
> the basic infrastructure in place (libiberty/pex*.c) to make that
> feasible.
>
> --
> Alan Modra
> Australia Development Lab, IBM