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.)

[vszakats]

Backing out of this. It would be too much extra maintenance task to maintain an extra copy of these scripts. Recreating the keys should also be fairly trivial, and can be done in a much less complicated way than these scripts are doing it. They also don't solve the problem of "real" code signing.

The idea was to avoid having unknown binary blobs in the repo without scripts that reproduce them, but there doesn't seem to real interest in doing this. It's also fairly unrealistic that the few keys here could pose any harm due to their small sizes and the transparent scripts using them.

[vszakats]

Ended up merging this.