wiktor-k
Joined 7 years ago
Joined 7 years ago
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.
Yes. The flag is perfect for scripts but it's exactly equivalent to adding the text manually.
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.
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)
In Signstar we're using testresult which still panics under the hood (which is OK for tests) https://gitlab.archlinux.org/archlinux/signstar/-/blob/main/... but the rendered example looks a lot better: https://docs.rs/nethsm/latest/nethsm/enum.OpenPgpVersion.htm...
Note that I'm currently maintaining that crate but the design is described at https://www.bluxte.net/musings/2023/01/08/improving_failure_...
Wait, isn't the board personally liable for their decisions? I'm not a lawyer, obviously.
I do that too but doesn't the same rule apply to Steam, too? (that is if it goes down, you can't download the games anymore?).
Technically, in JavaScript it's `with (foo) bar`.
Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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)
- due to SSH keys being small the policy file is also small and readable, compare https://github.com/openssh/openssh-portable/blob/master/.git... with equivalent OpenPGP https://gitlab.com/sequoia-pgp/sequoia/-/blob/main/openpgp-p...
aspe:metacode.biz:CK7LM6VO32K2AGIDXC7LYFRBSA
https://github.com/wiktor-k