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 most naturally be a n-v-r-a string, so the build is reproducible. Such a salt could be naturally injected via an environment variable set by rpmbuild.
https://bugzilla.redhat.com/show_bug.cgi?id=1002341 (salt!) https://bugzilla.redhat.com/show_bug.cgi?id=1550152 (life without salt)
I don't have a problem with adding a --build-id-salt="some arbitrary string" option, and I think "salt" is exactly the right term for this. I'd much prefer providing that than having you use a linker script. (I'm somewhat puzzled that you find the linker script option less objectionable than an object file with a note section.)
As Nick said earlier, it's not that we don't care about your feature request. I simply wanted to explore the options, and I gave you a couple of options that require no new features at all.
My other comments have been about the unnecessary conflating of a new option like --build-id-salt with the choice of hashing algorithm.
At least in the kernel we already have the infrastructure for customizations to linker scripts so it's fairly easy to expand on that. I have a prototype which should work, I just need to clean it up for review to see if it's feasible to merge vs. adding a --build-id-salt option.
Thanks, Laura
-cary
On 03/19/2018 02:56 PM, Laura Abbott wrote:
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 most naturally be a n-v-r-a string, so the build is reproducible. Such a salt could be naturally injected via an environment variable set by rpmbuild.
https://bugzilla.redhat.com/show_bug.cgi?id=1002341 (salt!) https://bugzilla.redhat.com/show_bug.cgi?id=1550152 (life without salt)
I don't have a problem with adding a --build-id-salt="some arbitrary string" option, and I think "salt" is exactly the right term for this. I'd much prefer providing that than having you use a linker script. (I'm somewhat puzzled that you find the linker script option less objectionable than an object file with a note section.)
As Nick said earlier, it's not that we don't care about your feature request. I simply wanted to explore the options, and I gave you a couple of options that require no new features at all.
My other comments have been about the unnecessary conflating of a new option like --build-id-salt with the choice of hashing algorithm.
At least in the kernel we already have the infrastructure for customizations to linker scripts so it's fairly easy to expand on that. I have a prototype which should work, I just need to clean it up for review to see if it's feasible to merge vs. adding a --build-id-salt option.
So while working through this and another packaging issue, I realized another reason why we might just want the --build-id-salt option in binutils. Because of how find-debuginfo.sh works, it finds and adds debuginfo for all binary files in the buildroot. We have to package several userspace utilities as part of the -devel package and those also get their debug information extracted and packaged at the same time as the rest of the kernel. The linker script trick doesn't work as easily. I can potentially work around this in packaging or find a way to link all userspace programs with an appropriate .o file but it's ugly. I'd much rather just have a unified approach so that all binaries have an a appropriate build-id.
Thanks, Laura
kernel@lists.fedoraproject.org