💾 Archived View for gemi.dev › gemini-mailing-list › 000718.gmi captured on 2023-11-04 at 13:03:50. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hi all! Is there a way to set up pages that are signed with Gnupg? To allow basic clients to not see anything, the signature would be in a separate file. The purpose is to make pages downloadable along with their source code and signature. -- Christophe HENRY FR EO EN - https://sbgodin.fr
On Wed, Feb 17, 2021 at 10:35:02PM +0100, Christophe HENRY <listes at sbgodin.fr> wrote a message of 39 lines which said: > Is there a way to set up pages that are signed with Gnupg? Note that the Web does not have it. (Only channel security, through TLS, not actual object/data security.) It would be nice for Gemini to have features missing in the Web :-) > The purpose is to make pages downloadable along with their source > code and signature. May be a convention: $URL + ".asc" MAY give you access to a signature of $URL?
Le Fri, 19 Feb 2021 15:24:34 +0100, Stephane Bortzmeyer <stephane at sources.org> a ?crit : > On Wed, Feb 17, 2021 at 10:35:02PM +0100, > Christophe HENRY <listes at sbgodin.fr> wrote > a message of 39 lines which said: > > > Is there a way to set up pages that are signed with Gnupg? > > Note that the Web does not have it. (Only channel security, through > TLS, not actual object/data security.) It would be nice for Gemini to > have features missing in the Web :-) Clearly! In addition to this, even if it were possible, as web pages embed other things it would be of no use. > > The purpose is to make pages downloadable along with their source > > code and signature. > > May be a convention: > > $URL + ".asc" MAY give you access to a signature of $URL? Right ^^ So every browser would be able to render the page as usual. There may be several modes:
On Fri, Feb 19, 2021 at 11:33 AM Christophe HENRY <listes at sbgodin.fr> wrote:
> There may be several modes:
>
> * The browser is configured to not care about signature. Everything go
> as usual. Just like any non-aware browser.
>
> * The browser is configured to indicate that this file exists, but does
> nothing. It would display a special icon https-style.
>
The only way that can work is for the client to automatically request the
signature when a document is retrieved. This has two problems: (a) it is
an automatic network action, which clients are not supposed to do, and (b)
it will cause a lot of useless hits when signatures are rare, which is bad
considering that Gemini servers are often limited by either CPU or network
bandwidth.
I think the Right Thing is for browsers to have a command/menu option
"Check Signature", which appends ".asc" to the pathname of the current URI
(not to the whole URI), and attempts to retrieve that. If it succeeds and
the content matches the current document, all is well.
However, this assumes that the signature methodology is standardized across
all sites. So a simpler, more Gemini thing to do is to replace "Check
Signature" with "View Signature", which displays the signature and leaves
it to the user to determine the signature on the local copy of the document.
> * The user would ask the browser to check for a particular site or for
> all sites.
>
WI don't understand this: signatures are per-document, not per-site. And
hat does "all sites" even mean? Even "all documents on the site" does not
need to be a finite number, given the ability to generate documents at the
server.
The rest follow the spirit of "Trust on first use". For instance,
> storing the public key of the author in the website. Maybe a kinda
> web-of-trust among some websites gathered in rings?
>
The server can't assume that all documents have the same author, so servers
have to be per-document, not per-site. This adds complexity to the server,
as it has to maintain additional metadata as opposed to keeping either
signature files or a rewrite rule that requests signature files from a
different, more secure site. The latter is the Right Thing when mirroring
documents from elsewhere: if your server is hacked, the hacker will
certainly alter the signature as well, but if the signature is off site,
that is more difficult.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
It was dreary and wearisome. Cold clammy winter still held sway in this
forsaken country. The only green was the scum of livid weed on the dark
greasy surfaces of the sullen waters. Dead grasses and rotting reeds loomed
up in the mists like ragged shadows of long-forgotten summers.
--LOTR, "The Passage of the Marshes"
Le Fri, 19 Feb 2021 14:06:12 -0500, John Cowan <cowan at ccil.org> a ?crit : > On Fri, Feb 19, 2021 at 11:33 AM Christophe HENRY <listes at sbgodin.fr> > wrote: > > > There may be several modes: > > > > * The browser is configured to not care about signature. Everything > > go as usual. Just like any non-aware browser. > > > > * The browser is configured to indicate that this file exists, but > > does nothing. It would display a special icon https-style. > > The only way that can work is for the client to automatically request > the signature when a document is retrieved. This has two problems: > (a) it is an automatic network action, which clients are not supposed > to do, and (b) it will cause a lot of useless hits when signatures > are rare, which is bad considering that Gemini servers are often > limited by either CPU or network bandwidth. You are right. That's why the others way come. > I think the Right Thing is for browsers to have a command/menu option > "Check Signature", which appends ".asc" to the pathname of the > current URI (not to the whole URI), and attempts to retrieve that. If > it succeeds and the content matches the current document, all is well. That sounds good. > However, this assumes that the signature methodology is standardized > across all sites. So a simpler, more Gemini thing to do is to > replace "Check Signature" with "View Signature", which displays the > signature and leaves it to the user to determine the signature on the > local copy of the document. > > * The user would ask the browser to check for a particular site or > > for all sites. > > > > WI don't understand this: signatures are per-document, not per-site. > And hat does "all sites" even mean? Even "all documents on the site" > does not need to be a finite number, given the ability to generate > documents at the server. Each page would have the ".asc" file. I suppose this file would link to the certificate. Such certificate may be found somewhere in the server, publicly accessible. > The rest follow the spirit of "Trust on first use". For instance, > > storing the public key of the author in the website. Maybe a kinda > > web-of-trust among some websites gathered in rings? > > The server can't assume that all documents have the same author, so > servers have to be per-document, not per-site. This adds complexity > to the server, as it has to maintain additional metadata as opposed > to keeping either signature files or a rewrite rule that requests > signature files from a different, more secure site. The latter is > the Right Thing when mirroring documents from elsewhere: if your > server is hacked, the hacker will certainly alter the signature as > well, but if the signature is off site, that is more difficult. That's right, it's always security vs. functionality. At least, each page may be signed before publication by the uploader. -- Christophe HENRY FR EO EN - https://sbgodin.fr
Hello Christophe, Christophe HENRY writes: > Hi all! > > Is there a way to set up pages that are signed with Gnupg? To allow > basic clients to not see anything, the signature would be in a separate > file. > > The purpose is to make pages downloadable along with their source code > and signature. I thought about signing things as well (trying to confirm, that these posts were published by the owner of the corresponding private key). => gemini://gemini.circumlunar.space/~ew/2020/20201217-towards-a-proper-flightlog-4.gmi I went for a file, which holds all sha512sums of all posts and files, and sign only that. This seemed like a good idea at the time, because my average post was like 1500 Byte, and adding a clearsign signature would add something like 800 Bytes to every post. Now, a growing site will lead to a big sha512sums file, it is clearly not good for automated checking (by the browser). Currently I don't have better ideas other than to add such signature files per year (separate folder). Cheers, ~ew -- Keep it simple!
---
Previous Thread: "Spy pixels in emails have become endemic"
Next Thread: [tech] A Gemini client library for Common Lisp.