Re: Feature request: improved build-id generation

[Alan Modra <amodra at gmail dot com>]

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