💾 Archived View for gemi.dev › gemini-mailing-list › 000167.gmi captured on 2024-08-31 at 16:03:03. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Super excited to share this. I've been working on this for 2 weeks, and using it daily as my only Gemini browser. You need Testflight app, as it is still beta. Please submit bug reports or suggestions. https://testflight.apple.com/join/ln6yTtqK I used Firefox for iOS as a base, like many other browsers on the app store. All telemetry/tracking code has been removed, and UI simplified as much as possible. I would like to add support for client certificates, Gopher protocol, and a few other smaller things. Source is located here - https://github.com/pitr/gemini-ios - you can also find a screenshot there. Cheers!
I love how it renders images! ?? -- Typed on a tiny keyboard. Sorry for being terse. > On 31 May 2020, at 13:12, Peter Vernigorov <pitr.vern at gmail.com> wrote: > > ?Super excited to share this. I've been working on this for 2 weeks, > and using it daily as my only Gemini browser. > > You need Testflight app, as it is still beta. Please submit bug > reports or suggestions. > > https://testflight.apple.com/join/ln6yTtqK > > I used Firefox for iOS as a base, like many other browsers on the app > store. All telemetry/tracking code has been removed, and UI simplified > as much as possible. I would like to add support for client > certificates, Gopher protocol, and a few other smaller things. > > Source is located here - https://github.com/pitr/gemini-ios - you can > also find a screenshot there. > > Cheers!
Hi Peter This is very nice, I just tried it. Possible suggestion - to have an option to show or not show URLs on links. Preformatted text seems to be wrapping, might be better to have a scroll on it instead? Best wishes Luke > On 31 May 2020, at 12:12, Peter Vernigorov <pitr.vern at gmail.com> wrote: > > Super excited to share this. I've been working on this for 2 weeks, > and using it daily as my only Gemini browser. > > You need Testflight app, as it is still beta. Please submit bug > reports or suggestions. > > https://testflight.apple.com/join/ln6yTtqK > > I used Firefox for iOS as a base, like many other browsers on the app > store. All telemetry/tracking code has been removed, and UI simplified > as much as possible. I would like to add support for client > certificates, Gopher protocol, and a few other smaller things. > > Source is located here - https://github.com/pitr/gemini-ios - you can > also find a screenshot there. > > Cheers!
Thanks everyone for trying, and for suggestions. I implemented both, waiting now on Apple to approve the next build. Regarding showing URL, I preferred this duri early development, but showing just the title looks much better :) Question about client certificates: not sure how other clients implement this, but I was thinking of generating and using the same client cert for all sites, and giving an option to create a cert for specific domain. Does that make sense? Potential problem I see is that main certificate is something user could be identified by across websites. On Sun, May 31, 2020 at 16:25 Luke Emmet <luke.emmet at gmail.com> wrote: > Hi Peter > > This is very nice, I just tried it. > > Possible suggestion - to have an option to show or not show URLs on links. > > Preformatted text seems to be wrapping, might be better to have a scroll > on it instead? > > Best wishes > > Luke > > > On 31 May 2020, at 12:12, Peter Vernigorov <pitr.vern at gmail.com> wrote: > > > > Super excited to share this. I've been working on this for 2 weeks, > > and using it daily as my only Gemini browser. > > > > You need Testflight app, as it is still beta. Please submit bug > > reports or suggestions. > > > > https://testflight.apple.com/join/ln6yTtqK > > > > I used Firefox for iOS as a base, like many other browsers on the app > > store. All telemetry/tracking code has been removed, and UI simplified > > as much as possible. I would like to add support for client > > certificates, Gopher protocol, and a few other smaller things. > > > > Source is located here - https://github.com/pitr/gemini-ios - you can > > also find a screenshot there. > > > > Cheers! > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/0900 1fe2/attachment.htm>
Peter Vernigorov <pitr.vern at gmail.com> writes: > Question about client certificates: not sure how other clients > implement this, but I was thinking of generating and using the same > client cert for all sites, and giving an option to create a cert for > specific domain. Does that make sense? Potential problem I see is that > main certificate is something user could be identified by across > websites. Yeah, we've discussed previously the idea of a client having a default client cert it uses for every site, and decided that it's a bad idea, because it enables cross-site tracking. In general, you shouldn't send a client cert unless the page you're asking for needs one. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada |
On Tue, Jun 02, 2020 at 01:31:09AM +0200, Peter Vernigorov wrote: > Question about client certificates: not sure how other clients implement > this, but I was thinking of generating and using the same client cert for > all sites, and giving an option to create a cert for specific domain. Does > that make sense? Potential problem I see is that main certificate is > something user could be identified by across websites. It's not super clear to me what you're suggesting. If it's that the client generates a single self-signed client cert the first time it starts up and then just sends that cert to every single host as part of every single request: PLEASE DON'T DO THAT! This is about as wrong an implementation of Gemini's idea of client certificates as possible. The vast majority of URLs will not require or expect a client cert (which is why there's a way for servers to explicitly request one in the unusual circumstance it's needed), and any you send will just be ignored. You will be needlessly increasing the TLS overhead (which is already pretty heavy relative to typical text/gemini payload sizes) for no gain. Worse, admins of unrelated servers would be able to compare their logs and track you across Geminispace. If it's that you generate a single certificate the first time it starts up but only send it out in response to a status code of 62 that's a different matter (I assume it goes without saying you shouldn't ever use it in response to a status code of 61 because the behaviour for transient certs is extremely clearly specced and this would fly in the face of just about every part of it). I still think it's the wrong thing to do, but it's slightly less disasterous than the first option. Client certificates should be handled in a very deliberate manner - the user needs make the clear decision to opt in, on their own terms, to being identified to some server(s). It's an exceptional condition and should never be automated or hidden from the user for the sake of convenience. Sharing a single certificate across domains isn't something anybody should ever do lightly. Cheers, Solderpunk
On Tue, Jun 02, 2020 at 08:16:09AM -0400, Jason McBrayer wrote: > Yeah, we've discussed previously the idea of a client having a default > client cert it uses for every site, and decided that it's a bad idea, > because it enables cross-site tracking. In general, you shouldn't send a > client cert unless the page you're asking for needs one. Did we? I don't remember that! I hope everybody was pretty staunchly opposed to the idea... Cheers, Solderpunk
Thanks. These responses and re-reading the spec clarified my initial concern. Spec clearly states that transient certificates should not be shared across domains. And there is no point using permanent certificates across domains as it is assumed that these certificates have a special meaning for specific domains. I am still unclear as to what happens after a transient certificate has been created. Should browser automatically use it for the page that requested it and any other pages on that domain? I don?t see a good solution here. Either certificate is sent only when server requests it, which would double number of requests (assuming user stays in private section of the site), or certificate is always sent, which adds overhead to all requests. Should browser remember which pages need a certificate and always use it for them? And additionally, should browser ask user for every page that requires a certificate if existing one can be used? Thanks for replying to my earlier questions. I want to make sure that my support for certificates doesn?t violate the spec or creates a bad user experience. On Tue, Jun 2, 2020 at 20:31 solderpunk <solderpunk at sdf.org> wrote: > On Tue, Jun 02, 2020 at 01:31:09AM +0200, Peter Vernigorov wrote: > > > Question about client certificates: not sure how other clients implement > > this, but I was thinking of generating and using the same client cert for > > all sites, and giving an option to create a cert for specific domain. > Does > > that make sense? Potential problem I see is that main certificate is > > something user could be identified by across websites. > > It's not super clear to me what you're suggesting. > > If it's that the client generates a single self-signed client cert the > first time it starts up and then just sends that cert to every single > host as part of every single request: PLEASE DON'T DO THAT! This is > about as wrong an implementation of Gemini's idea of client certificates > as possible. The vast majority of URLs will not require or expect a > client cert (which is why there's a way for servers to explicitly > request one in the unusual circumstance it's needed), and any you send > will just be ignored. You will be needlessly increasing the TLS overhead > (which is already pretty heavy relative to typical text/gemini payload > sizes) for no gain. Worse, admins of unrelated servers would be able to > compare their logs and track you across Geminispace. > > If it's that you generate a single certificate the first time it starts > up but only send it out in response to a status code of 62 that's a > different matter (I assume it goes without saying you shouldn't ever use > it in response to a status code of 61 because the behaviour for > transient certs is extremely clearly specced and this would fly in the > face of just about every part of it). I still think it's the wrong > thing to do, but it's slightly less disasterous than the first option. > > Client certificates should be handled in a very deliberate manner - the > user needs make the clear decision to opt in, on their own terms, to > being identified to some server(s). It's an exceptional condition and > should never be automated or hidden from the user for the sake of > convenience. Sharing a single certificate across domains isn't > something anybody should ever do lightly. > > Cheers, > Solderpunk > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/597d 8546/attachment.htm>
I?ve added support for client certificates in the latest build, basing mostly on implementation of AV-98. There?s a weird bug when using gemini://astrobotany.mozz.us/ which requires restart of client for certificate to work (and for it be deactivated) but gemini://gemini.conman.org/private/ works properly. Are there any other servers requiring client certificates that I can test against? I also updated code to comply with updates to Gemini protocol. Looking forward to seeing status code 11 in the wild :) On Tue, Jun 2, 2020 at 21:44 Peter Vernigorov <pitr.vern at gmail.com> wrote: > Thanks. These responses and re-reading the spec clarified my initial > concern. Spec clearly states that transient certificates should not be > shared across domains. And there is no point using permanent certificates > across domains as it is assumed that these certificates have a special > meaning for specific domains. > > I am still unclear as to what happens after a transient certificate has > been created. Should browser automatically use it for the page that > requested it and any other pages on that domain? I don?t see a good > solution here. Either certificate is sent only when server requests it, > which would double number of requests (assuming user stays in private > section of the site), or certificate is always sent, which adds overhead to > all requests. Should browser remember which pages need a certificate and > always use it for them? > > And additionally, should browser ask user for every page that requires a > certificate if existing one can be used? > > Thanks for replying to my earlier questions. I want to make sure that my > support for certificates doesn?t violate the spec or creates a bad user > experience. > > On Tue, Jun 2, 2020 at 20:31 solderpunk <solderpunk at sdf.org> wrote: > >> On Tue, Jun 02, 2020 at 01:31:09AM +0200, Peter Vernigorov wrote: >> >> > Question about client certificates: not sure how other clients implement >> > this, but I was thinking of generating and using the same client cert >> for >> > all sites, and giving an option to create a cert for specific domain. >> Does >> > that make sense? Potential problem I see is that main certificate is >> > something user could be identified by across websites. >> >> It's not super clear to me what you're suggesting. >> >> If it's that the client generates a single self-signed client cert the >> first time it starts up and then just sends that cert to every single >> host as part of every single request: PLEASE DON'T DO THAT! This is >> about as wrong an implementation of Gemini's idea of client certificates >> as possible. The vast majority of URLs will not require or expect a >> client cert (which is why there's a way for servers to explicitly >> request one in the unusual circumstance it's needed), and any you send >> will just be ignored. You will be needlessly increasing the TLS overhead >> (which is already pretty heavy relative to typical text/gemini payload >> sizes) for no gain. Worse, admins of unrelated servers would be able to >> compare their logs and track you across Geminispace. >> >> If it's that you generate a single certificate the first time it starts >> up but only send it out in response to a status code of 62 that's a >> different matter (I assume it goes without saying you shouldn't ever use >> it in response to a status code of 61 because the behaviour for >> transient certs is extremely clearly specced and this would fly in the >> face of just about every part of it). I still think it's the wrong >> thing to do, but it's slightly less disasterous than the first option. >> >> Client certificates should be handled in a very deliberate manner - the >> user needs make the clear decision to opt in, on their own terms, to >> being identified to some server(s). It's an exceptional condition and >> should never be automated or hidden from the user for the sake of >> convenience. Sharing a single certificate across domains isn't >> something anybody should ever do lightly. >> >> Cheers, >> Solderpunk >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200608/e76c 5928/attachment-0001.htm>
On Mon, Jun 08, 2020 at 09:39:37AM +0200, Peter Vernigorov wrote: > Are there any other > servers requiring client certificates that I can test against? I don't think there are yet. But lately I've been working to add good CGI and SCGI support to Molly Brown, including passing information about client certs on to aps through the variables (following Sean's lead for now, although I need to bring up some points for discussion about this in the near future). Very soon I will take advantage of this to start experimenting pretty heavily with client cert stuff. I will probably put up implementations of various possible authentication workflows to help us test clients and ideas sometime in the next week or so. Cheers, Solderpunk
On Mon, 8 Jun 2020, solderpunk wrote: >> Are there any other >> servers requiring client certificates that I can test against? > > I don't think there are yet. But lately I've been working to add good Yes, blizanci supports enforcement of client certificates. You can try to get the URL: gemini://gemini.ucant.org/restricted/example.gemini and it'll give you a status 20 or status 60 as the case may be. > CGI and SCGI support to Molly Brown, including passing information about > client certs on to aps through the variables (following Sean's lead for > now, although I need to bring up some points for discussion about this > in the near future). Very soon I will take advantage of this to start My implementation is that $REMOTE_USER is set to the common name in the cert subject. I think this is a good idea, but I don't think it's common practice in the Gemini universe. (I remain skeptical about whether SSL is the right choice - I reckon Gemini's simplicity goal is going to run up against the practice of trying to reuse as much existing infrastructure as possible.) Mk -- Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
It was thus said that the Great Martin Keegan once stated:
> On Mon, 8 Jun 2020, solderpunk wrote:
>
> >CGI and SCGI support to Molly Brown, including passing information about
> >client certs on to aps through the variables (following Sean's lead for
> >now, although I need to bring up some points for discussion about this
> >in the near future). Very soon I will take advantage of this to start
>
> My implementation is that $REMOTE_USER is set to the common name in the
> cert subject. I think this is a good idea, but I don't think it's common
> practice in the Gemini universe.
Of the dozen Gemini servers (software) out there, five (a little under half)
support CGI. Out of those, blizanci, GLV-1.12556 and getforce (a little
over half) set REMOTE_USER to the common name of the certifiate. The other
two don't set REMOTE_USER at all.
The CGI standard (RFC-3875) states that REMOTE_USER is set only if
authentication is used. blizanci sets is reguardless ("" if not there),
GLV-1.12556 and jetforce only set it if a certificate is used.
MollyBrown does not set REMOTE_USER, but does set TLS_CLIENT_SUBJECT_CN if a
certificate is used. GLV-1.12556 will also set TLS_CLIENT_SUBJECT_CN if
TLS environment variables are enabled (and a certificate is used).
One open question---what if the certificate doesn't sent a common name? I
think a subject *is* required, but I'm unsure of the mandatory subfields of
the subject.
> (I remain skeptical about whether SSL is the right choice - I reckon
> Gemini's simplicity goal is going to run up against the practice of
> trying to reuse as much existing infrastructure as possible.)
Okay, what encryption system would you have us poor non-cryptographer
programmers who write servers use and poorly implement? Feel free to bring
to the table a working server and client to show us how easy it is [1].
-spc
[1] If this comes across as too snarky or mean, this has come up at
least twice on this list already. The proposers were not, to my
knowledge, professional cryptographers, yet were quite insistent on
their proposals were sound. I don't think anyone else on the list
is a professional cryptographer and thus, can't say if the proposals
were sound or not. And the conventional wisdom is "Don't roll your
own cryptography!" Using an existing and widely used solution is
better than any other option at this point in time.
Please keep this in mind when criticizing the choice of TLS.
On Mon, 8 Jun 2020, Sean Conner wrote:
>> My implementation is that $REMOTE_USER is set to the common name in the
>> cert subject. I think this is a good idea, but I don't think it's common
>> practice in the Gemini universe.
>
> Of the dozen Gemini servers (software) out there, five (a little under half)
> support CGI. Out of those, blizanci, GLV-1.12556 and getforce (a little
> over half) set REMOTE_USER to the common name of the certifiate. The other
> two don't set REMOTE_USER at all.
I stand corrected.
> The CGI standard (RFC-3875) states that REMOTE_USER is set only if
> authentication is used. blizanci sets is reguardless ("" if not there),
> GLV-1.12556 and jetforce only set it if a certificate is used.
I see no reason not to follow the spec on this point, so I have just
changed this behaviour.
>> (I remain skeptical about whether SSL is the right choice - I reckon
>> Gemini's simplicity goal is going to run up against the practice of
>> trying to reuse as much existing infrastructure as possible.)
>
> Okay, what encryption system would you have us poor non-cryptographer
> programmers who write servers use and poorly implement? Feel free to bring
> to the table a working server and client to show us how easy it is [1].
Something similar to CurveCP. I am loath to suggest it though, because it
associated with being a djb fanboy, which I am decidedly not. I don't have
a concrete proposal. What I'd say is that it'd be good not to hardwire SSL
too strongly into Gemini, in case the tooling around an alternative
improves sufficiently in the future and we'd like to swap.
> [1] If this comes across as too snarky or mean, this has come up at
Not a problem whatsoever. I'm fairly thick-skinned.
Mk
--
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
It was thus said that the Great solderpunk once stated: > > (following Sean's lead for now, although I need to bring up some points > for discussion about this in the near future). So I have two CGI scripts set up. Both are in a "protected" area of the server (on my development machine) that requires a client certificate. One receives *just* the RFC-3875 defined variables: AUTH_TYPE=Certificate GEMINI_DOCUMENT_ROOT=/home/spc/projects/gemini/non-checkin/cgi-bin GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2 GEMINI_URL_PATH=/cgi-bin/beta/foobar PATH_INFO=/foobar PATH_TRANSLATED=/home/spc/projects/gemini/non-checkin/cgi-bin/foobar QUERY_STRING=one=1&two=2 REMOTE_ADDR=::ffff:192.168.1.10 REMOTE_HOST=::ffff:192.168.1.10 REMOTE_USER=Sean Conner REQUEST_METHOD= SCRIPT_NAME=/home/spc/projects/gemini/non-checkin/cgi-bin/./beta SERVER_NAME=lucy.roswell.area51 SERVER_PORT=1965 SERVER_PROTOCOL=GEMINI SERVER_SOFTWARE=GLV-1.12556/1 The AUTH_TYPE is "Certificate". I choose that form because I'm following the form of HTTP (RFC-2617, updated by RFC-7616) which defines "Basic" and "Digest". I know of another Gemini server that sets this to "CERTIFICATE". The REMOTE_USER is taken from the Common Name of the certificate subject. Right now, if a common name is not supplied, it won't be set (quirk of the Lua language---I should probably do something about that). I suppose as a backup the certificate subject could be used, or perhaps the empty string (allowed by the RFC---I just checked). The rest of the variables I've discussed elsewhere. So here's what happens when I enable TLS variables to be set (it's an option for GLV-1.12556): AUTH_TYPE=Certificate GEMINI_DOCUMENT_ROOT=/home/spc/projects/gemini/non-checkin/cgi-bin GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/alpha/foobar?one=1&two=2 GEMINI_URL_PATH=/cgi-bin/alpha/foobar PATH_INFO=/foobar PATH_TRANSLATED=/home/spc/projects/gemini/non-checkin/cgi-bin/foobar QUERY_STRING=one=1&two=2 REMOTE_ADDR=::ffff:192.168.1.10 REMOTE_HOST=::ffff:192.168.1.10 REMOTE_USER=Sean Conner REQUEST_METHOD= SCRIPT_NAME=/home/spc/projects/gemini/non-checkin/cgi-bin/./alpha SERVER_NAME=lucy.roswell.area51 SERVER_PORT=1965 SERVER_PROTOCOL=GEMINI SERVER_SOFTWARE=GLV-1.12556/1 TLS_CIPHER=ECDHE-RSA-CHACHA20-POLY1305 TLS_CLIENT_HASH=SHA256:0eab5867fcb5b30046120e4c29562e31b88c51b167b091aee4b4e66221645a20 TLS_CLIENT_ISSUER=/C=US/ST=FL/O=Conman Laboratories/OU=Security Division/CN=Conman Laboratories CA/emailAddress=ca at conman.org TLS_CLIENT_ISSUER_C=US TLS_CLIENT_ISSUER_CN=Conman Laboratories CA TLS_CLIENT_ISSUER_O=Conman Laboratories TLS_CLIENT_ISSUER_OU=Security Division TLS_CLIENT_ISSUER_ST=FL TLS_CLIENT_ISSUER_emailAddress=ca at conman.org TLS_CLIENT_NOT_AFTER=2020-06-18T23:54:56Z TLS_CLIENT_NOT_BEFORE=2019-06-19T23:54:56Z TLS_CLIENT_REMAIN=9 TLS_CLIENT_SUBJECT=/C=US/ST=FL/L=Boca Raton/CN=Sean Conner/emailAddress=sean at conman.org TLS_CLIENT_SUBJECT_C=US TLS_CLIENT_SUBJECT_CN=Sean Conner TLS_CLIENT_SUBJECT_L=Boca Raton TLS_CLIENT_SUBJECT_ST=FL TLS_CLIENT_SUBJECT_emailAddress=sean at conman.org TLS_VERSION=TLSv1.2 I modeled this behavior from Apache. Apache uses the prefix "SSL_" for these, I decided to change them to "TLS_". I included most of what Apache sends, but decided against the following fields: SSL_CIPHER_ALGKEYSIZE no way to get this via libtls SSL_CIPHER_EXPORT " SSL_CIPHER_USERKEYSIZE " SSL_CLIENT_A_KEY " SSL_CLIENT_A_SIG " SSL_CLIENT_CERT a copy of the client certificate SSL_CLIENT_CERT_CHAIN_n one (of n) certificates in the client certificate chain SSL_CLIENT_M_SERIAL no way to get this via libtls SSL_CLIENT_M_VERSION " SSL_COMPRESS_METHOD " SSL_SECURE_RENEG " SSL_SERVER_A_KEY " SSL_SERVER_A_SIG " SSL_SERVER_CERT a copy of the server certificate SSL_SERVER_M_SERIAL no way to get this via libtls SSL_SERVER_M_VERSION " SSL_SESSION_RESUMED " SSL_TLS_SNI covered by SERVER_NAME SSL_VERSION_INTERFACE didn't care SSL_VERSION_LIBRARY didn't care I copied what I thought was most important, dropped what I didn't understand nor cared for, and that's that. Certainly most of what I suspect Gemini will be used for can probably be covered with just AUTH_TYPE and REMOTE_USER, which is why I made the TLS_ variables optional. This also applies to my SCGI implementation, as they both share the same code to generate the variables. I will not be upset if the TLS_ variables are deemed "off limits" and are not to be set at all. I just added them as a point of discussion. -spc
On Tue, Jun 9, 2020 at 7:14 PM Sean Conner <sean at conman.org> wrote: > > It was thus said that the Great solderpunk once stated: > > > > (following Sean's lead for now, although I need to bring up some points > > for discussion about this in the near future). > > So I have two CGI scripts set up. Both are in a "protected" area of the > server (on my development machine) that requires a client certificate. One > receives *just* the RFC-3875 defined variables: > > AUTH_TYPE=Certificate > GEMINI_DOCUMENT_ROOT=/home/spc/projects/gemini/non-checkin/cgi-bin > GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2 > GEMINI_URL_PATH=/cgi-bin/beta/foobar > PATH_INFO=/foobar > PATH_TRANSLATED=/home/spc/projects/gemini/non-checkin/cgi-bin/foobar > QUERY_STRING=one=1&two=2 > REMOTE_ADDR=::ffff:192.168.1.10 > REMOTE_HOST=::ffff:192.168.1.10 > REMOTE_USER=Sean Conner > REQUEST_METHOD= > SCRIPT_NAME=/home/spc/projects/gemini/non-checkin/cgi-bin/./beta > SERVER_NAME=lucy.roswell.area51 > SERVER_PORT=1965 > SERVER_PROTOCOL=GEMINI > SERVER_SOFTWARE=GLV-1.12556/1 I believe this is using SCRIPT_NAME incorrectly per RFC 3875. The SCRIPT_NAME should be the part of the URI path that comes before the PATH_INFO [1]. So in your example: GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2 SCRIPT_NAME=/cgi-bin/beta PATH_INFO=/foobar I'm also curious how you are handling URL-encoding in your CGI variables. For jetforce, I followed my best interpretation of the RFC 3875 guidelines: - GEMINI_URL: URL-encoded (not specified by the RFC, of course) - QUERY_STRING: URL-encoded - PATH_INFO: URL-decoded - SCRIPT_NAME: URL-decoded I have a CGI debug script setup here [2] if anybody wants to poke holes in my implementation. [1] https://tools.ietf.org/html/rfc3875#section-3.3 [2] gemini://mozz.us/cgi-bin/debug.cgi Best, Michael
It was thus said that the Great Michael Lazar once stated: > On Tue, Jun 9, 2020 at 7:14 PM Sean Conner <sean at conman.org> wrote: > > > > It was thus said that the Great solderpunk once stated: > > > > > > (following Sean's lead for now, although I need to bring up some points > > > for discussion about this in the near future). > > > > So I have two CGI scripts set up. Both are in a "protected" area of the > > server (on my development machine) that requires a client certificate. One > > receives *just* the RFC-3875 defined variables: > > > > AUTH_TYPE=Certificate > > GEMINI_DOCUMENT_ROOT=/home/spc/projects/gemini/non-checkin/cgi-bin > > GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2 > > GEMINI_URL_PATH=/cgi-bin/beta/foobar > > PATH_INFO=/foobar > > PATH_TRANSLATED=/home/spc/projects/gemini/non-checkin/cgi-bin/foobar > > QUERY_STRING=one=1&two=2 > > REMOTE_ADDR=::ffff:192.168.1.10 > > REMOTE_HOST=::ffff:192.168.1.10 > > REMOTE_USER=Sean Conner > > REQUEST_METHOD= > > SCRIPT_NAME=/home/spc/projects/gemini/non-checkin/cgi-bin/./beta > > SERVER_NAME=lucy.roswell.area51 > > SERVER_PORT=1965 > > SERVER_PROTOCOL=GEMINI > > SERVER_SOFTWARE=GLV-1.12556/1 > > I believe this is using SCRIPT_NAME incorrectly per RFC 3875. You are correct. Sigh. Off to fix it ... > I'm also curious how you are handling URL-encoding in your CGI variables. For > jetforce, I followed my best interpretation of the RFC 3875 guidelines: > > - GEMINI_URL: URL-encoded (not specified by the RFC, of course) I also URL-encode this. > - QUERY_STRING: URL-encoded I don't URL-decode the query, so what gets passed to the script is what was passed as the request. > - PATH_INFO: URL-decoded > - SCRIPT_NAME: URL-decoded Same here, modulo the incorrect SCRIPT_NAME in GLV-1.12556. -spc
It was thus said that the Great Michael Lazar once stated: > > I have a CGI debug script setup here [2] if anybody wants to poke holes in my > implementation. > > [1] https://tools.ietf.org/html/rfc3875#section-3.3 > [2] gemini://mozz.us/cgi-bin/debug.cgi I notice it doesn't set PATH_TRANSLATED, and it always sets TLS_CIPHER and TLS_VERSION. And why HOSTNAME when you also have SERVER_NAME? -spc
On Tue, Jun 9, 2020 at 10:09 PM Sean Conner <sean at conman.org> wrote: > > It was thus said that the Great Michael Lazar once stated: > > > > I have a CGI debug script setup here [2] if anybody wants to poke holes in my > > implementation. > > > > [1] https://tools.ietf.org/html/rfc3875#section-3.3 > > [2] gemini://mozz.us/cgi-bin/debug.cgi > I notice it doesn't set PATH_TRANSLATED I just didn't see a compelling reason to add it. > and it always sets TLS_CIPHER and TLS_VERSION. Why not? These are just as useful even if the client doesn't send a certificate. > And why HOSTNAME when you also have SERVER_NAME? I can't remember why I added this. I thought I saw HOSTNAME referenced somewhere... Some other differences in my server's CGI implementation (I used GLV as a reference implementation, so there are a lot of similarities too): TLS_CLIENT_HASH I'm using a base64-encoded representation of the hash. I like your notation of SHA256:<HEX> better, but it's too late now and I don't want to break backwards compatibility. TLS_CLIENT_SERIAL_NUMBER The client certificate serial number. I'm surprised that this isn't available in libtls. TLS_CLIENT_AUTHORISED Even though jetforce accepts unverified client certificates now, it will still check if the certificate is authorised anyway. This means both valid and trusted by the server's CA store. So this will be set to "1" for trusted and "0" for untrusted. I like this variable because it gives each CGI script the option to implement authentication however they want.
It was thus said that the Great Michael Lazar once stated: > On Tue, Jun 9, 2020 at 10:09 PM Sean Conner <sean at conman.org> wrote: > > > > It was thus said that the Great Michael Lazar once stated: > > > > > > I have a CGI debug script setup here [2] if anybody wants to poke holes in my > > > implementation. > > > > > > [1] https://tools.ietf.org/html/rfc3875#section-3.3 > > > [2] gemini://mozz.us/cgi-bin/debug.cgi > > > I notice it doesn't set PATH_TRANSLATED > > I just didn't see a compelling reason to add it. I think it may have something to do with Apache's rewrite rules. My blog [1] is run via a CGI script, and I make extensive use of it to hide the fact that I'm using a CGI script [2]. For example, the url: http://boston.conman.org/about/technical.html is routed through the following rewrite rule [3]: RewriteRule ^about/(.*) boston.cgi/about/$1 [L] to give the final (internal) path of: /boston.cgi/about/technical.html I then use PATH_TRANSLATED to find the actual file to display. No Gemini server supports rewriting rules, but I don't see a reason why one couldn't. > > and it always sets TLS_CIPHER and TLS_VERSION. > > Why not? These are just as useful even if the client doesn't send a > certificate. Fair enough. > Some other differences in my server's CGI implementation (I used GLV as a > reference implementation, so there are a lot of similarities too): > > TLS_CLIENT_HASH > > I'm using a base64-encoded representation of the hash. I like your notation of > SHA256:<HEX> better, but it's too late now and I don't want to break backwards > compatibility. The format I use is from libtls---it was not my choice. > TLS_CLIENT_SERIAL_NUMBER > > The client certificate serial number. I'm surprised that this isn't available > in libtls. I'm surprised too when I saw TLS_CLIENT_SERIAL_NUMBER for the first time. I may have to make an extention module to do some stuff that libtls can't do. > TLS_CLIENT_AUTHORISED > > Even though jetforce accepts unverified client certificates now, it will still > check if the certificate is authorised anyway. This means both valid and trusted > by the server's CA store. So this will be set to "1" for trusted and "0" for > untrusted. I like this variable because it gives each CGI script the option to > implement authentication however they want. That makes sense. That's another thing that libtls makes a bit difficult. -spc [1] http://boston.conman.org/ [2] Not for security reasons, but for aesthetic reasons. I could change the name of the CGI script and *none* of the URLs will change. [3] I'd have to look up what the '[L]' does---it's been *that* long since I've set this up.
> On Jun 10, 2020, at 01:14, Sean Conner <sean at conman.org> wrote: > > I copied what I thought was most important, dropped what I didn't > understand nor cared for, and that's that. Very cool. Lot of data. https://tlsfingerprint.io/static/frolov2019.pdf
On Wed, Jun 10, 2020 at 12:48:52PM +0200, Petite Abeille wrote: > > On Jun 10, 2020, at 01:14, Sean Conner <sean at conman.org> wrote: > > > > I copied what I thought was most important, dropped what I didn't > > understand nor cared for, and that's that. > > Very cool. > > Lot of data. https://tlsfingerprint.io/static/frolov2019.pdf Thanks a lot for sharing this! I printed it out for weekend reading. Cheers, Solderpunk
On Tue, Jun 09, 2020 at 11:53:19PM -0400, Michael Lazar wrote: > TLS_CLIENT_HASH > > I'm using a base64-encoded representation of the hash. I like your notation of > SHA256:<HEX> better, but it's too late now and I don't want to break backwards > compatibility. I am extremely interested in having a well-defined notion of "certificate fingerprints" in Geminispace, not just for CGI apps but in server configs too (Molly Brown will soon support being able to configure lists of authorised certs for accessing certain directories). It's a shame it's too late for you to make changes now, but for the sake of all future implementations we should agree on something. I was actually going to suggest base64-encoded SHA256 of the binary (PEM) certificate (mostly guided by OpenSSH's use of base64 in .authorized_keys), but I'm happy to hear thoughts on this. Cheers, Solderpunk
On Tue, Jun 09, 2020 at 11:53:19PM -0400, Michael Lazar wrote: > > > and it always sets TLS_CIPHER and TLS_VERSION. > > Why not? These are just as useful even if the client doesn't send a > certificate. Sorry if this is a silly question, but how *are* these useful in a CGI script? Cheers, Solderpunk
On Wed, Jun 10, 2020 at 08:49:57PM +0000, solderpunk wrote: > I was actually going to suggest base64-encoded SHA256 of the binary > (PEM) certificate (mostly guided by OpenSSH's use of base64 in > .authorized_keys), but I'm happy to hear thoughts on this. Forgot to mention: in the web browser world, using a hexadecimal encoding of a SHA-family hash with colons between each byte seems to be the norm. We could adopt that for familiarity / consistency as well. It's less compact, but it's also much easier to e.g. verify by eyeball. Cheers, Solderpunk
It was thus said that the Great solderpunk once stated: > On Tue, Jun 09, 2020 at 11:53:19PM -0400, Michael Lazar wrote: > > > TLS_CLIENT_HASH > > > > I'm using a base64-encoded representation of the hash. I like your notation of > > SHA256:<HEX> better, but it's too late now and I don't want to break backwards > > compatibility. > > I am extremely interested in having a well-defined notion of > "certificate fingerprints" in Geminispace, not just for CGI apps but in > server configs too (Molly Brown will soon support being able to > configure lists of authorised certs for accessing certain directories). > It's a shame it's too late for you to make changes now, but for the sake > of all future implementations we should agree on something. What? That it's too late for him to change the format he's using for TLS_CLIENT_HASH? On thinking on it, why does it matter what the format is? It's a hash value---an obstensibly binary blob. It's a computable unique identifier for a resource, so does it really matter if you use the binary format, or some textual format? Sure, the binary format is a bit more compact, but that's it. A CGI (SCGI, other) can still use it as a key---it may just not be portable between servers, that's all. -spc
On Wed, Jun 10, 2020 at 05:50:38PM -0400, Sean Conner wrote: > What? That it's too late for him to change the format he's using for > TLS_CLIENT_HASH? On thinking on it, why does it matter what the format is? > It's a hash value---an obstensibly binary blob. It's a computable unique > identifier for a resource, so does it really matter if you use the binary > format, or some textual format? Sure, the binary format is a bit more > compact, but that's it. A CGI (SCGI, other) can still use it as a key---it > may just not be portable between servers, that's all. Sure, but portability of a fingerprint between different servers and between different CGI apps is extremely desirable. If I need to calculate multiple different fingerprints of a given cert in order to whitelist it in different applications, that's a big barrier to adoption. Cheers, Solderpunk
On Wed, Jun 10, 2020 at 4:50 PM solderpunk <solderpunk at sdf.org> wrote: > > On Tue, Jun 09, 2020 at 11:53:19PM -0400, Michael Lazar wrote: > > > TLS_CLIENT_HASH > > > > I'm using a base64-encoded representation of the hash. I like your notation of > > SHA256:<HEX> better, but it's too late now and I don't want to break backwards > > compatibility. > > I am extremely interested in having a well-defined notion of > "certificate fingerprints" in Geminispace, not just for CGI apps but in > server configs too (Molly Brown will soon support being able to > configure lists of authorised certs for accessing certain directories). > It's a shame it's too late for you to make changes now, but for the sake > of all future implementations we should agree on something. Ok I'll walk that back. It's too late to make changes *unless* there's a good reason to do so. I don't want to break CGI variables on a whim anymore, but if we all agree on a standard then I will follow suit.
On Wed, Jun 10, 2020 at 06:58:38PM -0400, Michael Lazar wrote: > Ok I'll walk that back. It's too late to make changes *unless* there's a good > reason to do so. I don't want to break CGI variables on a whim anymore, but if > we all agree on a standard then I will follow suit. You're not storing these hashes in some kind of database for Astrobotany? Wouldn't changing how you calcultate the TLS_CLIENT_HASH variable break a lot of accounts? Cheers, Solderpunk
On Tue, Jun 09, 2020 at 09:02:24PM -0400, Michael Lazar wrote: > I believe this is using SCRIPT_NAME incorrectly per RFC 3875. The SCRIPT_NAME > should be the part of the URI path that comes before the PATH_INFO [1]. So in > your example: > > GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2 > SCRIPT_NAME=/cgi-bin/beta > PATH_INFO=/foobar Is this how cgi-bins are traditionally handled? If a URI paths's prefix matches the configured cgi-bin path, the standard mapping from URI paths to the filesystem is interrupted, and the first component of the URI path
> On Jun 11, 2020, at 19:58, solderpunk <solderpunk at SDF.ORG> wrote: > > Is this how cgi-bins are traditionally handled? Is there be any interest in D. J. Bernstein's ucspi-tcp [1] in this time and age? As a nimbler alternative to CGI perhaps? ucspi-tcp defines the following environment variables: $PROTO is the string TCP. $TCPLOCALIP is the IP address of the local host, in dotted-decimal form. $TCPLOCALPORT is the local TCP port number, in decimal. $TCPLOCALHOST is the name listed in DNS for the local host. If no name is available, $TCPLOCALHOST is not set. Beware that $TCPLOCALHOST can contain arbitrary characters. $TCPREMOTEIP is the IP address of the remote host, in dotted-decimal form. $TCPREMOTEPORT is the remote TCP port number, in decimal. $TCPREMOTEHOST is the name listed in DNS for the remote host. If no name is available, $TCPREMOTEHOST is not set. Beware that $TCPREMOTEHOST can contain arbitrary characters. $TCPREMOTEINFO is a connection-specific string supplied by the remote host via the 931/1413/IDENT/TAP protocol. If no information is available, $TCPREMOTEINFO is not set. Beware that $TCPREMOTEINFO can contain arbitrary characters. The TLS flavor [2] add these: SSL_PROTOCOL The TLS protocol version (SSLv3, TLSv1, ...). SSL_SESSION_ID The hex-encoded SSL session id. SSL_CIPHER The cipher specification name. SSL_CIPHER_USEKEYSIZE Number of cipher bits (actually used). SSL_CIPHER_ALGKEYSIZE Number of cipher bits (possible). SSL_VERSION_INTERFACE The mod_ssl program version. SSL_VERSION_LIBRARY The OpenSSL program version. SSL_CLIENT_M_VERSION The version of the client certificate. SSL_CLIENT_M_SERIAL The serial of the client certificate. SSL_CLIENT_S_DN Subject DN in client's certificate. SSL_CLIENT_S_DN_x509 Component of client's Subject DN. SSL_CLIENT_I_DN Issuer DN of client's certificate. SSL_CLIENT_I_DN_x509 Component of client's Issuer DN. SSL_CLIENT_V_START Validity of client's certificate (start time). SSL_CLIENT_VERIFY NONE, SUCCESS, GENEROUS or FAILED:reason. SSL_SERVER_M_SERIAL The serial of the server certificate. SSL_SERVER_S_DN Subject DN in server's certificate. SSL_SERVER_S_DN_x509 Component of server's Subject DN. SSL_SERVER_I_DN Issuer DN of server's certificate. SSL_SERVER_I_DN_x509 Component of server's Issuer DN. SSL_SERVER_V_START Validity of server's certificate (start time). SSL_SERVER_V_END Validity of server's certificate (end time). SSL_SERVER_A_SIG Algorithm used for the signature of server's certificate. SSL_SERVER_A_KEY Algorithm used for the public key of server's certificate. SSL_SERVER_CERT PEM-encoded server certificate. For $SSL_CLIENT_x_DN_x509 and $SSL_SERVER_x_DN_x509, x509 denotes a component of the DN: C, ST, L, O, OU, CN, T, I, G, S, D, UID, Email. [1] https://cr.yp.to/ucspi-tcp/ [2] https://www.fehcom.de/ipnet/ucspi-ssl.html
> On Jun 10, 2020, at 05:53, Michael Lazar <lazar.michael22 at gmail.com> wrote: > > TLS_CLIENT_AUTHORISED > > Even though jetforce accepts unverified client certificates now, it will still > check if the certificate is authorised anyway. This means both valid and trusted > by the server's CA store. So this will be set to "1" for trusted and "0" for > untrusted. I like this variable because it gives each CGI script the option to > implement authentication however they want. Is that the equivalent of SSL_CLIENT_VERIFY? E.g.: NONE: client has no cert SUCCESS = cert is valid GENEROUS = says only that some kind of certificate was sent at all FAILED:reason = auth with the cert failed
On Thu, Jun 11, 2020 at 1:58 PM solderpunk <solderpunk at sdf.org> wrote: > > On Tue, Jun 09, 2020 at 09:02:24PM -0400, Michael Lazar wrote: > > > I believe this is using SCRIPT_NAME incorrectly per RFC 3875. The SCRIPT_NAME > > should be the part of the URI path that comes before the PATH_INFO [1]. So in > > your example: > > > > GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2 > > SCRIPT_NAME=/cgi-bin/beta > > PATH_INFO=/foobar > > Is this how cgi-bins are traditionally handled? If a URI paths's prefix > matches the configured cgi-bin path, the standard mapping from URI paths > to the filesystem is interrupted, and the first component of the URI path > *after* the cgi-bin prefix (here `beta`) is the only think looked for on > the disk, with everything else passed along to PATH_INFO? If there is, > for example, a /var/gemini/cgi-bin/beta/ directory on the disk, the > server does not check for an executable named `foobar` in it? Yes, but it's not limited to only the first component after cgi-bin/. The way jetforce is implemented (thanks to a PR by arxcode [0]) is that it will walk through the URI path on the filesystem until it reaches an executable file. Then, anything left over is attached to the PATH_INFO. These two are both valid: gemini://mozz.us/cgi-bin/debug.cgi/extra/path/info -> /var/gemini/cgi-bin/debug.cgi gemini://mozz.us/cgi-bin/directory/debug.cgi/extra/path/info -> /var/gemini/cgi-bin/directory/debug.cgi [0] https://github.com/michael-lazar/jetforce/issues/16
On Thu, Jun 11, 2020 at 1:37 PM solderpunk <solderpunk at sdf.org> wrote: > > On Wed, Jun 10, 2020 at 06:58:38PM -0400, Michael Lazar wrote: > > > Ok I'll walk that back. It's too late to make changes *unless* there's a good > > reason to do so. I don't want to break CGI variables on a whim anymore, but if > > we all agree on a standard then I will follow suit. > > You're not storing these hashes in some kind of database for > Astrobotany? Wouldn't changing how you calcultate the TLS_CLIENT_HASH > variable break a lot of accounts? I am storing them in the database as base64-encoded strings. But it would not be hard to convert between the two text formats as long as the fingerprint bytes are the same. What we're discussing here (to my knowledge) is two different text representations of the same SHA256 digest of the public x509 certificate DER [0][1]. That's the standard way to do certificate fingerprinting from what I can tell. Even if we do pick a different hashing algorithm for the CGI variable, astrobotany is implemented as a jetforce "application" where the python code is invoked directly inside the server's interpreter. So it has full access to the raw client certificate and can generate whichever hash it needs. I think this is similar to what GLV-1.12556 does with allowing custom LUA "handlers". [0] https://github.com/michael-lazar/jetforce/blob/ea7d8c6f4cbc3db14f62c01b f12c375abfe98e7e/jetforce/tls.py#L25 [1] https://github.com/pyca/cryptography/blob/f5735cf25acd08222368a1db615bb f61d36b8007/src/cryptography/hazmat/backends/openssl/x509.py#L47
It was thus said that the Great solderpunk once stated:
> On Tue, Jun 09, 2020 at 09:02:24PM -0400, Michael Lazar wrote:
>
> > I believe this is using SCRIPT_NAME incorrectly per RFC 3875. The SCRIPT_NAME
> > should be the part of the URI path that comes before the PATH_INFO [1]. So in
> > your example:
> >
> > GEMINI_URL=gemini://lucy.roswell.area51/cgi-bin/beta/foobar?one=1&two=2
> > SCRIPT_NAME=/cgi-bin/beta
> > PATH_INFO=/foobar
>
> Is this how cgi-bins are traditionally handled?
Yes.
> If a URI paths's prefix
> matches the configured cgi-bin path, the standard mapping from URI paths
> to the filesystem is interrupted, and the first component of the URI path
> *after* the cgi-bin prefix (here `beta`) is the only think looked for on
> the disk, with everything else passed along to PATH_INFO? If there is,
> for example, a /var/gemini/cgi-bin/beta/ directory on the disk, the
> server does not check for an executable named `foobar` in it?
To answer that last question, no.
To explain, let me explain my setup. GLV-1.12556 allows one to use
multiple directories per virtual host for content. I have the following
set up on my development box:
{
path = "^(/cgi%-bin/)(.*)", -- [5]
module = "GLV-1.handlers.filesystem",
directory = "/home/spc/projects/gemini/non-checkin/cgi-bin",
-- ... there are some other directives, not important right now
},
{
path = ".*", -- [5]
module = "GLV-1.handlers.filesystem",
directory = "/home/spc/projects/gemini/non-checkin/lucy.roswell.area51",
-- ... more directives ...
}
Note that depending upon how things are configured, CGI [1] can be in any
directory or restricted to a single directory [2]. With GLV-1.12556, any
file with the 'execute' bit will be treated as a CGI script [3][4]. I just
added a CGI to my main Gemini server:
gemini://gemini.conman.org/test/a-script/foobar?one=1&two=2
the URL is broken up:
location =
{
host = "gemini.conman.org",
port = 1965.000000,
path = "/test/a-script/foobar",
scheme = "gemini",
query = "one=1&two=2",
}
the path is matched against each handler's path (in order, first match wins)
and the matching one is handed the request. Per the configuration, this
match result will be:
match =
{
"/",
"test/a-script/foobar",
}
The filesystem handler will breakdown the second match element (the first
is considered the "URL filesystem space"---remember, GLV-1.12556 supports
multiple directories per vhost) and check each segment (for permissions, CGI
script or SCGI script). So the first check is for:
<directory> .. "test"
This is a directory, so it continues, walking down the path. Next it
tries:
<directory> .. "test/" .. "a-script"
This is a file with the execute bit set, so it's run. The rest of the
match is used to construct the PATH_INFO
PATH_INFO="/foobar"
and PATH_TRANSLATED
PATH_TRANSLATED=<directory> .. "/foobar"
This does not imply that such a directory exists. If there is no more to
the path (say, the request was to "/test/a-script") then the PATH_INFO and
PATH_TRASLATED would not be set.
A Gemini server doesn't have to do what I do. It is certainly in line
with Apache to require CGI scripts to have a particular extension, look for
said extension and handle things that way without having to walk down the
filesystem checking each component. So hypothetically speaking, a request
like:
gemini://example.net/foo/bar.cgi
the server can scan for ".cgi", find it, know it's going to execute a CGI
script, but there is nothing more of the URL path, so not set PATH_INFO and
PATH_TRANSLATE. But for this:
gemini://example.net/foo/bar.cgi/baz
find the .cgi extension, extract the path up through the extension
("/foo/bar.cgi") and because there's more, set up PATH_INFO and
PATH_TRANSLATE. There's another message on this list where I give a real
life example where I use PATH_INFO and PATH_TRANSLATED here:
gemini://gemi.dev/gemini-mailing-list/messages/001485.gmi
> Semi-related: when the server forks off the CGI process, is it
> conventional to set that process' working directory to the CGI bin?
It would be conventional to set the working directory to the main
directory for the host. In my case, given that a host can have multiple
directories, I set the working directory to the handler's directory setting.
That value is also set in GEMINI_DOCUMENT_ROOT.
-spc
[1] And SCGI, I support this as well.
[2] That's why I have 'cgi-bin'---to test that configuration.
[3] I didn't bother with extensions for this. I felt that checking for
the 'execute' bit was more elegant than just an extension. Also, if
CGI has been disabled (server wide, host or directory---the
configuration is very fine grained) then I return an error to the
client.
[4] There's another method for SCGI.
[5] This is a Lua style regex. The patterns in () are groupings and the
filesystem handler wants two groups---the first is the leading
portion in URL space that doesn't map to a file system, the second
is the portion that does map to a filesystem. The original syntax
for this only required one match and I kept that---in that case, the
match is redone slightly so that the leading '/' from the URL
portion is the first match, then the rest. So the '.*' pattern
(which is basically "match all") becomes the pattern "^(/)(.*)".
This is an implementation detail of GLV-1.12556, but I thought I
should mention it.
On Thu, Jun 11, 2020 at 03:33:37PM -0400, Michael Lazar wrote: > I am storing them in the database as base64-encoded strings. But it would not > be hard to convert between the two text formats as long as the fingerprint > bytes are the same. What we're discussing here (to my knowledge) is two > different text representations of the same SHA256 digest of the public x509 > certificate DER [0][1]. That's the standard way to do certificate > fingerprinting from what I can tell. Ah, right, if everybody is already using SHA256 then, yes, we can stick to that and the different serialisations are convertible. And I don't see any reason not too. From what I can tell there (somewhat surprisingly) really isn't a standard notion of certificate fingerprinting, but SHA1 and SHA256 seem to be the most commonly used by web browsers. I will express a moderate preference for the "hexadecimal with colons between bytes" notation. It takes up more space than base64, but as a pubnix admin I have people mailing me ssh public keys all the time. Sometimes they attach them, and I'm happy, but other times they just paste 'em right into the email and either their mail client splits the key over several lines and I have to join them back together, or they are sent as one long line and then mutt wraps them on my end and inserts +s or =s or somesuch where it wraps, which blend right in with the actual key content. It's a fiddly thing. The hexadecimal colon format is way easier to work with via eyeball. Cheers, Solderpunk
It was thus said that the Great Michael Lazar once stated: > > Even if we do pick a different hashing algorithm for the CGI variable, > astrobotany is implemented as a jetforce "application" where the python code is > invoked directly inside the server's interpreter. So it has full access to the > raw client certificate and can generate whichever hash it needs. I think this > is similar to what GLV-1.12556 does with allowing custom LUA "handlers". Yes, exactly. -spc
It was thus said that the Great Petite Abeille once stated: > > Is there be any interest in D. J. Bernstein's ucspi-tcp [1] in this time > and age? As a nimbler alternative to CGI perhaps? I looked at it (the link you gave for [1] is incorrect by the way), and it seems more of a way to write a server than for a server to execute CGI programs. I suppose you could have a CGI implementation that uses the ucspi-tcp variables to pass information, but ... meh. > [1] https://cr.yp.to/ucspi-tcp/ Should be: https://cr.yp.to/ucspi-tcp.html -spc
On Thu, Jun 11, 2020 at 3:50 PM solderpunk <solderpunk at sdf.org> wrote: > > I will express a moderate preference for the "hexadecimal with colons > between bytes" notation. It takes up more space than base64, but as a > pubnix admin I have people mailing me ssh public keys all the time. > Sometimes they attach them, and I'm happy, but other times they just > paste 'em right into the email and either their mail client splits the > key over several lines and I have to join them back together, or they > are sent as one long line and then mutt wraps them on my end and inserts > +s or =s or somesuch where it wraps, which blend right in with the > actual key content. It's a fiddly thing. The hexadecimal colon format > is way easier to work with via eyeball. I have a slight preference towards not sticking the colons between bytes: - It's easier to generate from bytes without needing to insert the colons - It's easier to convert back to bytes without needing to remove the colons - It would have a marginally smaller footprint - It would look more like a UUID when displayed or inserted into a URL path
On Thu, Jun 11, 2020 at 04:18:37PM -0400, Michael Lazar wrote: > I have a slight preference towards not sticking the colons between bytes: > > - It's easier to generate from bytes without needing to insert the colons > - It's easier to convert back to bytes without needing to remove the colons > - It would have a marginally smaller footprint > - It would look more like a UUID when displayed or inserted into a URL path Actually, the marginally smaller footprint is a really good point which largely invalidates my arguments about making them easy to stick in emails. Without colons, a 256 bit hash formatted as hex is 64 characters long, which will fit in a single line. With colons, they'd be 96 characters which typically won't. So, let's not do them. Upper or lower case? Cheers, Solderpunk?
It was thus said that the Great solderpunk once stated: > On Thu, Jun 11, 2020 at 04:18:37PM -0400, Michael Lazar wrote: > > > I have a slight preference towards not sticking the colons between bytes: > > > > - It's easier to generate from bytes without needing to insert the colons > > - It's easier to convert back to bytes without needing to remove the colons > > - It would have a marginally smaller footprint > > - It would look more like a UUID when displayed or inserted into a URL path > > Actually, the marginally smaller footprint is a really good point which > largely invalidates my arguments about making them easy to stick in > emails. Without colons, a 256 bit hash formatted as hex is 64 > characters long, which will fit in a single line. With colons, they'd > be 96 characters which typically won't. So, let's not do them. > > Upper or lower case? Yes. -spc (Or mu. I'll accept both)
On Thu, Jun 11, 2020 at 07:50:18PM +0000, solderpunk wrote: > Ah, right, if everybody is already using SHA256 then, yes, we can stick > to that and the different serialisations are convertible. And I don't > see any reason not too. From what I can tell there (somewhat > surprisingly) really isn't a standard notion of certificate > fingerprinting, but SHA1 and SHA256 seem to be the most commonly used by > web browsers. At the risk of overthinking things, I was reading RFC6709 "Design Considerations for Protocol Extensions" for non-Gemini reasons recently and this section seems relevant: "4.5. Cryptographic Agility ... The ability to negotiate the use of a particular cryptographic algorithm provides resilience against compromise of a particular cryptographic algorithm.... This is usually accomplished by including an algorithm identifier and parameters in the protocol, and by specifying the algorithm requirements in the protocol specification." i.e. Instead of storing opaque bytes, also mention that it's SHA256 A stand-alone implementation of this concept: https://multiformats.io/multihash/ Cheers, Tom
On Fri, 12 Jun 2020, Thomas Karpiniec wrote:
> i.e. Instead of storing opaque bytes, also mention that it's SHA256
>
> A stand-alone implementation of this concept:
> https://multiformats.io/multihash/
Ah, I like this.
I'd also commend the Scuttlebutt approach to this (Scuttlebutt is a
"curate's egg" of good and bad examples), which is to include the type of
key in the canonical representation:
{
"author": "@FCX/tsDLpubCPKKfIrw4gc+SQkHcaD17s7GI6i/ziWY=.ed25519",
"content": {
"type": "pub",
"address": {
"host": "one.butt.nz",
"port": 8008,
"key": "@VJM7w1W19ZsKmG2KnfaoKIM66BRoreEkzaVm/J//wl8=.ed25519"
}
},
...
}
The ".ed25519" making it clear what we're dealing with. Instinctively I
like the multihash thing more, but the Scuttlebutt form has the merit of
much better legibility/obviousness.
Mk
--
Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/
Maybe adding version for whole gemini protocol ? ??????? Original Message ??????? On Friday 12 June 2020 01:39, Thomas Karpiniec <tkarpiniec at icloud.com> wrote: > On Thu, Jun 11, 2020 at 07:50:18PM +0000, solderpunk wrote: > > > Ah, right, if everybody is already using SHA256 then, yes, we can stick > > to that and the different serialisations are convertible. And I don't > > see any reason not too. From what I can tell there (somewhat > > surprisingly) really isn't a standard notion of certificate > > fingerprinting, but SHA1 and SHA256 seem to be the most commonly used by > > web browsers. > > At the risk of overthinking things, I was reading RFC6709 "Design > Considerations for Protocol Extensions" for non-Gemini reasons > recently and this section seems relevant: > > "4.5. Cryptographic Agility > > ... The ability to negotiate the use of a particular cryptographic > algorithm provides resilience against compromise of a particular > cryptographic algorithm.... This is usually accomplished by including > an algorithm identifier and parameters in the protocol, and by > specifying the algorithm requirements in the protocol specification." > > i.e. Instead of storing opaque bytes, also mention that it's SHA256 > > A stand-alone implementation of this concept: > https://multiformats.io/multihash/ > > Cheers, Tom
On Fri, Jun 12, 2020 at 08:13:28AM +0000, defdefred wrote: > Maybe adding version for whole gemini protocol ? I am fairly staunchly against this, and always have been. I'm not sure how popular a stance it is. In my mind, having protocol versions which are signalled in-band is just an invitation to endlessly upgrade over time, and completely defeats the point of all the efforts to limit extensibility. I strongly believe that the computing world in general could really benefit from a healthy dose of the attitude that "things should be allowed to be finished". I am hopeful that Gemini is simple enough that we can "get it right", or right enough, the first time and then just enjoy building stuff within whatever limitations it imposes forever after. Gopher is more than 25 years old and people are still using it with very few changes to the official spec. I don't see why we can't hope for similar longevity. Some of Gopher's biggest problems stem just from the fact that it was born very early - before URIs were invented and before internationalisation was taken seriously. Had Gopher been born just a little later (or had those early major disruptions happened just a little sooner), it might be being used *exactly* as specced today (well, the `i` item type would probably still have evolved). Gopher's item types have not aged well, but we are using MIME types instead, which are extensible and therefore likely to be usable for the forseeable future. Exciting new internet protocols might gain major traction in the future, but it's a very safe bet they will come with URI schemes, so Gemini will be able to link to them, no problem. If there are major happenings in the cryptographic landscape, it is reasonable to expect new versions of TLS to address that for the forseeable future, and Gemini will come along for the ride. At the end of the day, the basic problems we are trying to solve are not difficult and have not changed for a long time. Good solutions to these problems should have long lifespans. Constant upgrades are a sign of bad solutions, or excessive ambition / scope creep: HTTP/2 has only come along because people are convinced that viewing a document online needs to involve downloading 1,000 inter-connected components from 100 hosts. Gemini rejects that as obvious nonsense, so it's fine to design with no intention of that every working well. Cheers, Solderpunk > > ??????? Original Message ??????? > On Friday 12 June 2020 01:39, Thomas Karpiniec <tkarpiniec at icloud.com> wrote: > > > On Thu, Jun 11, 2020 at 07:50:18PM +0000, solderpunk wrote: > > > > > Ah, right, if everybody is already using SHA256 then, yes, we can stick > > > to that and the different serialisations are convertible. And I don't > > > see any reason not too. From what I can tell there (somewhat > > > surprisingly) really isn't a standard notion of certificate > > > fingerprinting, but SHA1 and SHA256 seem to be the most commonly used by > > > web browsers. > > > > At the risk of overthinking things, I was reading RFC6709 "Design > > Considerations for Protocol Extensions" for non-Gemini reasons > > recently and this section seems relevant: > > > > "4.5. Cryptographic Agility > > > > ... The ability to negotiate the use of a particular cryptographic > > algorithm provides resilience against compromise of a particular > > cryptographic algorithm.... This is usually accomplished by including > > an algorithm identifier and parameters in the protocol, and by > > specifying the algorithm requirements in the protocol specification." > > > > i.e. Instead of storing opaque bytes, also mention that it's SHA256 > > > > A stand-alone implementation of this concept: > > https://multiformats.io/multihash/ > > > > Cheers, Tom > > >
Last night I recorded a ~30min introduction to Gemini called "What is Gemini?" You can find it on peertube or youtube here: https://toobnix.org/videos/watch/8ee54700-971c-4da3-a8b4-7a78ed9ac42e https://www.youtube.com/watch?v=DoEI6VzybDk Please leave comments on anything I got wrong so others can benefit. I've also pushed up my "notes" slide with these links to my gemlog on tilde.black here: gemini://tilde.black/users/fox/journal/20200612-what-is-gemini.gmi
James Tomasino writes: > Last night I recorded a ~30min introduction to Gemini called "What is Gemini?" You can find it on peertube or youtube here: Cool! I'm digging your background rug. :-) Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200612/4ded 1cf6/attachment-0001.sig>
FYI: The youtube video will not play on my Mac desktop. It crashes within 5 seconds of start. I have never used toobnix, and I was unable to figure out how to start it. This is why simple text is the way to go! Terry Brennan On Jun 12, 2020, at 7:14 AM, James Tomasino <tomasino at lavabit.com> wrote: > Last night I recorded a ~30min introduction to Gemini called "What is Gemini?" You can find it on peertube or youtube here: > > https://toobnix.org/videos/watch/8ee54700-971c-4da3-a8b4-7a78ed9ac42e > > https://www.youtube.com/watch?v=DoEI6VzybDk > > Please leave comments on anything I got wrong so others can benefit. > > I've also pushed up my "notes" slide with these links to my gemlog on tilde.black here: > > gemini://tilde.black/users/fox/journal/20200612-what-is-gemini.gmi >
On 12-Jun-2020 12:14, James Tomasino wrote: > Last night I recorded a ~30min introduction to Gemini called "What is Gemini?" You can find it on peertube or youtube here: > > https://toobnix.org/videos/watch/8ee54700-971c-4da3-a8b4-7a78ed9ac42e > > https://www.youtube.com/watch?v=DoEI6VzybDk > > Please leave comments on anything I got wrong so others can benefit. > > I've also pushed up my "notes" slide with these links to my gemlog on tilde.black here: > > gemini://tilde.black/users/fox/journal/20200612-what-is-gemini.gmi > Hey Tomasino thanks for this - it is a nice overview and I enjoyed watching it. It is strange to hear someone actually talk about something I had only ever seen in written form, but sort of refreshing to know I didn't imagine all this... And I now have a link to send to all my "normal" friends who wonder what I am going on about :p Best wishes - Luke
It was thus said that the Great Terry Brennan once stated: > FYI: The youtube video will not play on my Mac desktop. It crashes within 5 seconds of start. > > I have never used toobnix, and I was unable to figure out how to start it. For what it's worth, I had no problems with playing either one on a Mac desktop. -spc
Apologies if I came across as arrogant. I was just reporting what (looked like) a problem. BTW, is there a user's guide or FAQ for toobnix? Terry Brennan On 06/13/2020 05:10 PM, Sean Conner wrote: > It was thus said that the Great Terry Brennan once stated: >> FYI: The youtube video will not play on my Mac desktop. It crashes within 5 seconds of start. >> >> I have never used toobnix, and I was unable to figure out how to start it. > For what it's worth, I had no problems with playing either one on a Mac > desktop. > > -spc >
On 6/14/20 2:58 PM, Terry Brennan wrote: > BTW, is there a user's guide or FAQ for toobnix? Toobnix is just a peertube instance managed by SDF. You can learn more about the platform here: https://joinpeertube.org/
> On Jun 12, 2020, at 01:39, Thomas Karpiniec <tkarpiniec at icloud.com> wrote: > > https://multiformats.io/multihash/ Which also sport multiaddr: https://multiformats.io/multiaddr/ How would one describe a gemini address? For example, given gemini://mozz.us/beer/, would the following be appropriate? /dns4/mozz.us/tcp/1965/tls/gemini/beer/ /ip4/174.138.124.169/tcp/1965/tls/gemini/beer/ Based on: https://github.com/multiformats/multiaddr/issues/63
---
Previous Thread: Ambiguity in unordered list item definition