Signed binaries
pinkforest opened this issue · 10 comments
Would it be feasible to extend cargo-auditable to signed binaries ?
I would love to sign all the information and then use auditable also to check that the auditable information was signed correctly.
You can sign a binary after running cargo auditable the same way you sign a regular binary for the respective OS, right?
Correct you could post-auditable.
I was additionally thinking that auditable could provide a mechanism to inject a signatures of the dependencies.
Nonetheless I would be keen to have builder to have it's own signing information in auditable format as well.
Dependencies don't have signatures, right?
Not currently but those still get linked. Especially in repeatable builds one would expect to get the same dependency.
You mean including a hash of all compiled rlibs that are linked into the executable?
Yep.
Binaries compiled with cargo auditable certainly benefit from whole-binary signing, since it also makes the audit info impossible to tamper with after the binary is compiled.
I'm not sure how this proposal is different from regular binary signing, and why should it be handled by cargo auditable instead of a separate tool. Could you elaborate?
in zulip this Q also came up by @tarcieri :
what's the use case? if the intent is to publish the binary, it might be interesting to use something like Sigstore
My A:
yeah publish.
I would prefer it in the binary instead of separate signature text file that ~never gets checked due to convenience factor cargo-auditable and tooling could provide it.
The tooling would just provide convenience to both insert and check the opinionated checksums without separate sign & check -
I could just tell the users just to use to verify it came signed auditable with our sig with audit - also Sigstore sounds nice - does it support multisig flow or smth ?
Embedding the signature into the binary in a way that leaves the binary easy to check is not easy. You are literally modifying the data you wanted to sign after you signed it. The procedure to revert the injection of the signature data is both security-critical and non-trivial.
I agree that it would synergize nicely with cargo auditable, but that project is sufficiently non-trivial and orthogonal to deserve its own tool. I'm going to close this as out of scope for cargo auditable, but you're welcome to get a repo for cargo sig going.
I also proposed that the dependencies in reproducible builds could be signed separately not just the whole binary.
That would not require re-writing it. e.g. if I am doing a reproducible build I would expect the dependencies compile the same way unless bumped or featureset changes etc.