wiktor-k

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

As described in the post they did in the past: https://github.blog/news-insights/git-notes-display/

> Is adding them manually to the commit message functionally equivalent to using the `--trailer` flag?

Yes. The flag is perfect for scripts but it's exactly equivalent to adding the text manually.

> 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 have no idea how the 'parser'[1] works

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)

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

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.

It's interesting to hear because Samsung had a Linux feature previously: https://developer.samsung.com/sdp/blog/en/2017/10/18/samsung...

> In my opinion, the whole concept that a company can break the law but no human can be held responsible is insane.

Wait, isn't the board personally liable for their decisions? I'm not a lawyer, obviously.

> Eventually I couldn't justify buying the console version of a game that I was willing to play on Steam.

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

> now deprecated javascript `with` statement where `with foo; bar` will resolve to `bar` if it is in scope, otherwise it will resolve to `foo.bar`.

Technically, in JavaScript it's `with (foo) bar`.

Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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)

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

Exactly. I was surprised that this one doesn't support multi capture when available.

It's definitely an excellent example of complex but real typst code. Thanks for sharing!

I can wholeheartedly recommend them. Excellent introduction to the format, at least it was for me.

Thanks!

Just for completeness apparently Alloy is at version 6 now (http://alloytools.org/alloy6.html) and the book is based on version 4 (http://alloytools.org/book.html). There's another resource linked on the site: https://haslab.github.io/formal-software-design/

I've went through the TLA book of Lamport and it was quite approachable.

Do you have any specific resources recommendations for learning Alloy and TLA+?

> I read/worked through Freedman's Statistics a couple of years ago and I walked away from it a different person.

Wholeheartedly agree. It took me a year to slowly go through all chapters and this experience really influenced my way of thinking.

I wish other topics had books of that level of quality.

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

The standard is quite new but there are already libs with full support (e.g. the pure Rust OpenPGP: https://fosstodon.org/@hko/113198947595455844).

One interesting thing is that there's a test suite checking implementations developed alongside the spec (https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-...) so it's easy to see the conformance status.

That's exactly what's happening.

Yes! Something similar to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

> Not being able to flash the firmware is a feature, not a bug. :)

It is a feature only if they ship replacement devices in case of issues like this. If they don't and you're left with a broken device then I'd rather count it as a "bug".

Sadly the "source on github" links are broken on https://pretextbook.org/examples.html

> Something like `foo.bar[function]()` is perfectly valid JS,

A minor thing but `function` is a keyword in JS so technically it's not a "perfectly valid JS".

Just for completeness the html export issue is here: https://github.com/typst/typst/issues/721

> To be frank I quite like this idea. Can’t we standardize it somehow and add it to other email clients too?

Just copying what I said in the other thread: there actually is a standard for that already: https://datatracker.ietf.org/doc/html/rfc9078

Sadly, it seems it doesn't have broad adoption: https://bugzilla.mozilla.org/show_bug.cgi?id=1724363

> Surely there’s an RFC for that right?

Indeed, there is: https://datatracker.ietf.org/doc/html/rfc9078

It's used by Delta Chat (IM over email).

> I've always thought about just making a chat client app using email as the underlying standard.

I'm happy to report that this already exists: https://delta.chat/