gen-keys: add scripts to generate secrets

[vszakats]

To make binary blobs (secret keys) stored in the repo transparent,
here are the scripts that can generate those.

code signature script sourced from:
https://gist.github.com/vszakats/7ef9e86506f5add961bae0412ecbe696

[vszakats]

Is this useful? Do we want this?

[Andarwinux]

This allows users to fork this repo and easily build their own signed binaries, which is very useful in my opinion. Then consider enable PE binary integritycheck (-Xlink=-integritycheck) by default.

[vszakats]

Speaking of -Xlink=-integritycheck, is it correct, that this option makes Windows force-check the code signature at every run? Would that work with the self-signed signatures out of the box? (meaning without installing our CA root)

[Andarwinux]

that this option makes Windows force-check the code signature at every run?

Yes, Windows will refuse to execute curl.exe and issue a warning if curl.exe has been maliciously or accidentally damaged.

Would that work with the self-signed signatures out of the box? (meaning without installing our CA root)

I obviously forgot about this. For self-signed certificates, the CA need to be installed. So integritycheck shouldn't be enabled by default, but I think curl-for-win should sign official builds with a recognized code signing certificate, and then users can choose to sign their own builds with self-signed certificates.

[vszakats]

I obviously forgot about this. For self-signed certificates, the CA need to be installed. So integritycheck shouldn't be enabled by default, but I think curl-for-win should sign official builds with a recognized code signing certificate, and then users can choose to sign their own builds with self-signed certificates.

It would be nice indeed, but non-self-signed certs have a few massive roadblocks:

• obtaining a "proper" cert needs a legal entity or a person willing to publish
  their identity (with every copy of the binary).
• this might even come with legal responsibilities, but IANAL.
• a hefty sum to be paid to the cert provider, yearly.
• manual administration procedure to renew, yearly.
• it may not be true anymore but last time it also needed an obsolete Windows
  machine configured with various insecure settings to make the certificate
  issuance work. To the point that we did not manage to make it work after days
  of trying.
• in case signed timestamps are required (I don't know if that's the case, but
  it was at least recommended/requested IIRC), it makes the final binaries
  non-reproducible. This would only be solved with a detached signature, and
  AFAIK this isn't supported by Windows. Perhaps there are other ways, that
  I'm not aware of.

I haven't read about this more than these two announcements, and some pain
points might be addressed by Microsoft's latest "Trusted Signing", cloud-based
solution, for $120/year (small tier):
https://learn.microsoft.com/en-us/azure/trusted-signing/

https://techcommunity.microsoft.com/t5/security-compliance-and-identity/trusted-signing-is-in-public-preview/ba-p/4103457

Legalese, money still required and the non-reproducibility issue likely remains.

Same / similar dance, with completely different actual steps with Apple/macOS.
(though we don't provide official macOS binaries for now.)