💾 Archived View for rawtext.club › ~sloum › geminilist › 005718.gmi captured on 2023-12-28 at 16:29:15. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-

<-- back to the mailing list

[tech] Geminipg: using Gnupg to sign Gemini pages and directories

nervuri nervuri at disroot.org

Sat Feb 27 14:10:17 GMT 2021

- - - - - - - - - - - - - - - - - - - 

On Thu, Feb 25, 2021, Christophe HENRY wrote:

Nice to meet you :-)

Likewise.

Why not use a single SHA256SUMS file for all files on the capsule? We
Depending on the number of pages, it would become a huge file to
locally update if one file happens to be modified.

It would be about 1 MB per 10,000 files and it would be updatedselectively by the script. I think that's generally good enough."Premature optimization is the root of all evil." :)

Indeed, if it was only for me, I would sign the files inline
(--clear-sign). Or even would add dedicated headers… But, wait, it's
been discussed ;-)

Inline signatures would work well in some cases. They are ugly, butthey're otherwise the perfect solution: no extra network requests, clearindication of which file is signed...

I also want to explore the idea of a signed "key-sources" file
containing links to the public key from multiple sources, for
cross-checking in case the key changes. Not sure how this would work
exactly, I need to give it more thought.
Yes, I totally agree. The good news is that it's already part of the
Gnupg ecosystem.

You mean keyservers? They weren't doing so well, last I checked:https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

But it looks like keys.openpgp.org has remedied those issues:https://keys.openpgp.org/about/news#2019-06-12-launch

Still, it's only a single source. Are there any other such modernkeyservers?

Instead of GPG, I recommend OpenBSD's signify [1], which gives us nice
and short Ed25519 keys and signatures. It's also available on
GNU/Linux (in Debian, `apt install signify-openbsd`).
(…)
This way, we would lose the web of trust. Wouldn't we?

We would lose the PGP version of it, although there's nothing stoppingyou from signing someone else's signify key, to show that you trust it(and send that person your signature, to publish on his/her site). Thisgives us an ad-hoc web of trust.

I never had the chance to use the PGP web of trust. It sounds good intheory, but in practice the UI seriously hinders its adoption. It mightwork within projects like Debian, but if I want to verify a file on thenet made by someone I don't know (and whose PGP-friends I don't know),the only way for me to check if I have the right key is to get it frommultiple sources and/or network perspectives. This is what I've alwaysdone, the web of trust never entered the picture.

I don't think multiple signatures are worth the added complexity. But
I'm curious if you have arguments to the contrary.
It's a major piece of my thoughts. It's why I would like to keep
signatures on one file (or even in a header…). Say one famous person
publishes something great and signed it. On his capsule, there would be
"page.gmi" and "page.gmi.sig". If I want to keep this by my side or
want to reuse the page, I can also re-publish the two files.

Ah, ok. In this case, I would explain in a separate page: "this is theauthor's text and this is his signature" (links to both). Again, anad-hoc solution for a rare use case, no technical burden. This would bemy preference, at least.