[Bug remote/28489] Allow caching of remote objfiles

["simark at simark dot ca" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28489

--- Comment #5 from Simon Marchi <simark at simark dot ca> ---
(In reply to Tom Tromey from comment #4)
> (In reply to Simon Marchi from comment #2)
> 
> > Isn't the concept of build-id that we can assume they are always unique, for
> > all practical intents?  I don't understand what situation you imagine where
> > there would be a clash.
> 
> Just bad luck.  I wonder if there's ever been a clash.
> Shrug, maybe we don't have to worry about it.  That would make
> things simpler.

I think that many things in the stack use that assumption.  The concept of
build-id would not be very useful if we couldn't assume they are unique, it
means we couldn't use the build-id as the key for anything (for instance, for
the index-cache).

On my system, the build-ids are generated using the sha1 method, for instance:

$ file /bin/ls
/bin/ls: ... BuildID[sha1]=588ca812c340997ca8660ce0e15ee31a542568ad ...

So accidental collisions are not going to happen, for practical intents and
purposes. People will of course point out that there are known attacks on sha1
to create collisions, but then it's a producer problem, if they want to avoid
that they should move to a newer hashing algorithm.

Same thing if the producer fails to consider some important bits of executables
when generating the build-id, resulting in two different binaries having the
same build-id, then it's a producer bug that should be fixed.  I don't think we
should try to protect against that, otherwise we will always work in a
pessimistic fashion and won't be able to optimize anything.

-- 
You are receiving this mail because:
You are on the CC list for the bug.