💾 Archived View for rawtext.club › ~sloum › geminilist › 005585.gmi captured on 2023-11-14 at 09:59:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
nervuri nervuri at disroot.org
Wed Feb 24 19:59:52 GMT 2021
- - - - - - - - - - - - - - - - - - -
I really like what you're trying to achieve, but maybe we can find asolution than doesn't involve all those extra files / network requests.
Why not use a single SHA256SUMS file for all files on the capsule? Wecould put it in .well-known and sign it. To generate it, we only needa simple script that runs sha256sum recursively. We end up with:
.well-known/key.pub.well-known/SHA256SUMS.well-known/SHA256SUMS.sign
A proof-of-concept client can also be a relatively simple shell script:
./verify.sh gemini://capsule.org/~user/file
It would first download the 3 well-known files, check the signature ofSHA256SUMS and keep it locally, along with the key. Then it can verifyany file on gemini://capsule.org/~user/ without making additionalnetwork requests. On hash mismatch, it would check if SHA256SUMSchanged on the server. It would apply TOFU on key.pub. It could outputgemtext to stdout, to be piped into a client that renders it nicely.
Note that in this example, .well-known is under ~user, not directlyunder capsule.org. This is to account for multi-user systems(pubnixes/tilde communities).
The 3 files can be merged into one, because why not? So this systeminvolves one extra network request every once in a while, which makesthe client stand out fingerprinting-wise. This slight privacy trade-offis something to keep in mind when you use this feature - maybe only useit sparingly, when you need the extra security.
That's it, in short. It would work the same way on gemini, gopher andthe web. I'll probably code this if nobody does it before me.
I also want to explore the idea of a signed "key-sources" filecontaining links to the public key from multiple sources, forcross-checking in case the key changes. Not sure how this would workexactly, I need to give it more thought.
Instead of GPG, I recommend OpenBSD's signify [1], which gives us niceand short Ed25519 keys and signatures. It's also available on GNU/Linux(in Debian, `apt install signify-openbsd`).
There is already a good solution for page signing on the web [2], madeby the developer of EteSync (great guy). The problem of included filesis solved by subresource integrity [3].
[1] https://man.openbsd.org/signify[2] https://stosb.com/blog/signed-web-pages/[3] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Several signatures for one file
I don't think multiple signatures are worth the added complexity. ButI'm curious if you have arguments to the contrary.