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]

Re: Feature request: improved build-id generation


On Thu, Mar 15, 2018 at 1:59 AM, Cary Coutant <ccoutant@gmail.com> wrote:
>>> > 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).
>

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.

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.

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.


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