[ANN] Gemini browser for iOS

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
*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?

Semi-related: when the server forks off the CGI process, is it
conventional to set that process' working directory to the CGI bin?

Cheers,
Solderpunk

> 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