> ² With S/MIME you need to keep your old certificates around to decrypt old mails, so having a new one frequently is not practical
You don't need to change your decryption key - the new certificate can use the same decryption keys as the old one (certbot even has a flag: --reuse-key). Whether this is a good idea or not is a separate question.
I think the biggest benefit would be ACME-like automatic certificate issuance. Currently getting a new certificate is just too much friction.
> I always felt unwrap is preferable for diagnosing issues, which makes it useful in tests. A failed unwrap will point you directly to the line of code which panics, which is much simpler than trying to trace an issue through many layers of Results.
Take a closer look at testresult since it also points directly at the exact line of failure (due to panics being used under hood) but looks nicer.
I think parsing there depends on the actual value of the current token. So if you assign send to another variable and use that the "parser" will still recognize that it takes 2 parameters.
It's an interesting design, definitely not something one sees frequently.
> That section briefly described that, broadly speaking, using unwrap() is okay if it’s in test/example code or when panicking indicates a bug.
I've come to the conclusion that even in tests unwraps look ugly. Especially in doc tests which serve as examples the code is better off using regular "?" that one would see in other parts of code. (that is: don't treat test code as a "worse" kind of code)
Key IDs are based on fingerprints and fingerprints are calculated by SHA-1 hashing the primary key's public key and the creation timestamp. A computationally easy way to influence the fingerprint is to tweak the creation timestamp which is a 32 bit Unix epoch value. Of course it needs to be in the past so the range is limited but it's faster to do it this way instead of recomputing the cryptographic key.
Oh yeah, SSH signing is incredible. I've also migrated to it and didn't look back.
A couple of differences:
- it's possible to specify signing keys in a file inside the repository, and configure git to verify on merge (https://github.com/wiktor-k/ssh-signing/). I'm using that for my dot config repo to make sure I'm pulling only stuff I committed on my machines.
- SSH has TPM key support via PKCS11 or external agents, this makes it possible to easily roll out hardware backed keys
- SSH signatures have context separation, that is it's not possible to take your SSH commit signature and repurpose it (unlike OpenPGP)
You don't need to change your decryption key - the new certificate can use the same decryption keys as the old one (certbot even has a flag: --reuse-key). Whether this is a good idea or not is a separate question.
I think the biggest benefit would be ACME-like automatic certificate issuance. Currently getting a new certificate is just too much friction.