> ² 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)
> > When was the last time you had to debug an ancient codebase without documentation or help from a team?
> All the time.
I guess the minor difference was that it was part of your paid job instead of a huge time sink to get hired.
This is the biggest issue I have with all these tasks is that they take precious time that could be utilized better. In my case: working on real open-source software instead of throwaway made-up problems. (Source: I had to spend 3 days to write a transaction engine toy once and then I didn't get the job for another reason.)
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.