1
point
wiktor-k
Joined 184 karma
I work on cryptographic software and integration with hardware security modules (TPMs, PKCS#11...)
aspe:metacode.biz:CK7LM6VO32K2AGIDXC7LYFRBSA
https://github.com/wiktor-k
- As described in the post they did in the past: https://github.blog/news-insights/git-notes-display/
- > 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...
- > 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...
- 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 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.
- Yes! Something similar to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- Sadly the "source on github" links are broken on https://pretextbook.org/examples.html
- 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/
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.