Hi everyone,

I've just issued a new release which includes the following
slightly-modified client certificate behaviour (relevant only to
gemini):

1. In previous versions, client certificates - when activated - were
associated with the current host, and were automatically disabled when
an address belonging to a different host was accessed.  In the current
version, client certificates are instead associated with a URL prefix,
meaning that they're automatically disabled when the URL corresponding
to the address doesn't match that prefix.  (I.e. enabling a certificate
for gemini://example.org/~userA/app won't automatically apply the same
certificate to requests for gemini://example.org/~userB/.)

2. A new customization variable, `elpher-certificate-map', is available
which can be given an alist of URL prefix -> certificate name mappings.
When a gemini site requests a client certificate and the page URL matches
a prefix in the alist, the associated persistent certificate is
automatically applied.

Let me know if I've broken anything, and have a good weekend.

Tim

p.s. I realised after posting the release that my use of string-prefix-p
to determine whether a given certificate should be applied to a gemini
address isn't perfect.  In particular, if a certificate is enabled for
gemini://example.org/~userA it will also be applied to
gemini://example.org/~userArgh.  I'll look into fixing this shortly.

Hi Tim,

i've been unable to get client certificates working for the purposes of
submitting links to cdg.thegonz.net. Selecting "Add link" always results
in a redirect loop prior to getting an input prompt.

i've tried both temporary and permanent certificates, in the latter case setting
elpher-certificate-map to e.g.

    (("gemini://cdg.thegonz.net/" . "flexibeast"))

where "flexibeast" is the name of the certificate and is (as shown by
stepping through the code with Edebug) found by Elpher.

i was able to add links using Lagrange.

Can you suggest any way(s) i might be able to track down what's going on?


Alexis.