Re: Feature request: improved build-id generation

ArOn 03/16/2018 11:37 AM, Cary Coutant wrote: Then I'm stating my case poorly. I want a way to inject additional data into the has computation. At one point, we proposed doing this via a linker- or assembler-oriented extra "salt" parameter, which would be hashed into the buildid. This would

Re: Feature request: improved build-id generation

On 03/15/2018 06:32 AM, Nick Clifton wrote: Hi Mark, That might be an interesting alternative. Could you use this for e.g. inserting a .comment section fragment with an unique (version) string? That would be stripped away, but should still count for the build-id hash calculation. If you know

Re: Feature request: improved build-id generation

On Thu, 2018-03-15 at 11:36 +, Nick Clifton wrote: > > > I think Fedora should be able to ask its tool chain to insert the > > > extra data rather than hacking it in after the fact. > > I'll just note that another way to insert data into a linked binary > is to use a linker script fragment

Re: Feature request: improved build-id generation

On Thu, 2018-03-15 at 00:45 -0700, Cary Coutant wrote: > > > 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

Re: Feature request: improved build-id generation

On Wed, Mar 14, 2018 at 6:46 PM, Linus Torvalds wrote: > > SHA1 with the known attack weakness fixed (aka "Hardened SHA1", the > way git already does) in a non-certificate environment is fine. .. don't get me wrong, git will migrate away, but the whole "it's not

Re: Feature request: improved build-id generation

On Wed, Mar 14, 2018 at 6:01 PM, Alan Modra wrote: > On Wed, Mar 14, 2018 at 04:40:25PM -0700, Andy Lutomirski wrote: >> >> 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