[gemini] redirect to absolute path #192

New Issue

nixo · 2020-10-24T08:56:31Z

nixo commented

2020-10-24 08:56:31 +00:00

Hi!

While testing my server implementation, I found a problem on either my specs implementation or on how redirects are managed by bombadillo.
I assume my understanding of the specs is right (since the expected behaviour works on elpher 2.10.0 and on kristall V0.3-69-gb684f94)

Bombadillo version: 2.3.1

I'm referring to the latest specs I could find: v0.14.2, July 2nd 2020

3.2.3 3x (REDIRECT)
"The URL may be absolute or relative."

Expected behaviour: a redirect "30 /test" sent by "server" should lead to "server/test"
Actual behaviour: Invalid system path: /test

Thanks!

Hi! While testing my server implementation, I found a problem on either my specs implementation or on how redirects are managed by bombadillo. I *assume* my understanding of the specs is right (since the expected behaviour works on elpher 2.10.0 and on kristall V0.3-69-gb684f94) Bombadillo version: 2.3.1 I'm referring to the latest specs I could find: v0.14.2, July 2nd 2020 3.2.3 3x (REDIRECT) "The URL may be absolute or relative." Expected behaviour: a redirect "30 /test" sent by "server" should lead to "server/test" Actual behaviour: Invalid system path: /test Thanks!

sloum commented

2020-10-24 16:50:36 +00:00

Interesting. On my current build (2.3.2) of Bombadillo this seems to be working correctly.

I have set up the following url:

gemini://rawtext.club/~sloum/cgi/rel_redirect_server

All it does is print 30 /spacewalk.gmi.

Now, rawtext.club does not have that file at its root so a [5] Permanent Failure. Not found! should be returned by the server. This is notably different from what you were seeing (Invalid system path).

I also set up this url:

gemini://rawtext.club/~sloum/cgi/rel_redirect_folder

All it does is print 30 ../spacewalk.gmi.

I had originally meant for it to just be no slash, thus the file name... but there was nothing good to link to in my cgi folder so I figured jump up a dir to spacewalk. It should load fine.

Following all of this I pulled master and built 2.3.1 and have verified it is an issue with that build. You mentioned updating the package for GUIX (which is awesome, thank you so much!); if you wanted to hold off a week I should have 2.3.3 done and that merged into master. That would be the best point to update as it will include some other good stuff (greatly improved error messaging for commands being a favorite. The new messages will actually tell you what the command should be structured like).

I'm going to leave this issue open as a reminder to me to get the release pushed out and once master reflects a fix to this I will close it. In the meantime, if you want to try building 2.3.3 it is currently on a release branch called release2.3.3.

Thanks again for the bug report!

Interesting. On my current build (2.3.2) of Bombadillo this seems to be working correctly. I have set up the following url: `gemini://rawtext.club/~sloum/cgi/rel_redirect_server` All it does is print `30 /spacewalk.gmi`. Now, `rawtext.club` does not have that file at its root so a `[5] Permanent Failure. Not found!` should be returned by the server. This is notably different from what you were seeing (`Invalid system path`). I also set up this url: `gemini://rawtext.club/~sloum/cgi/rel_redirect_folder` All it does is print `30 ../spacewalk.gmi`. I had originally meant for it to just be no slash, thus the file name... but there was nothing good to link to in my cgi folder so I figured jump up a dir to spacewalk. It should load fine. Following all of this I pulled `master` and built `2.3.1` and have verified it is an issue with that build. You mentioned updating the package for GUIX (which is _awesome_, thank you so much!); if you wanted to hold off a week I should have `2.3.3` done and that merged into `master`. That would be the best point to update as it will include some other good stuff (greatly improved error messaging for commands being a favorite. The new messages will actually tell you what the command should be structured like). I'm going to leave this issue open as a reminder to me to get the release pushed out and once master reflects a fix to this I will close it. In the meantime, if you want to try building `2.3.3` it is currently on a release branch called `release2.3.3`. Thanks again for the bug report!

sloum added the

bug

label 2020-10-24 16:51:13 +00:00

sloum self-assigned this 2020-10-24 16:51:16 +00:00

nixo commented

2020-10-24 16:58:32 +00:00

I'm on the latest tagged release, 2.3.1, and the same happens on your url.

I already sent a patch to to guix (https://issues.guix.gnu.org/44192) with the 2.3.1 version, I'll send an updated one once 2.3.2 or 2.3.3 is officially released!

I'll build latest master just to verify that my server is working, but I guess it will

Thanks!
I reported two alredy fixed bugs, I'm sorry!

I'm on the latest tagged release, 2.3.1, and the same happens on your url. I already sent a patch to to guix (https://issues.guix.gnu.org/44192) with the 2.3.1 version, I'll send an updated one once 2.3.2 or 2.3.3 is officially released! I'll build latest master just to verify that my server is working, but I guess it will Thanks! I reported two alredy fixed bugs, I'm sorry!

sloum commented

2020-10-24 17:14:44 +00:00

No worries at all! It is my fault for not getting the in-progress stuff released quicker. Thanks for submitting the patch to guix. I'll still leave this issue open and I'll ping you on it once the next release gets tagged and moved to master. That should resolve this issue (and provide lots of other goodies).

No worries at all! It is my fault for not getting the in-progress stuff released quicker. Thanks for submitting the patch to guix. I'll still leave this issue open and I'll ping you on it once the next release gets tagged and moved to master. That _should_ resolve this issue (and provide lots of other goodies).

nixo commented

2020-10-24 17:14:53 +00:00

Wait, is really 97b74ea767 the latest version?

Certificates are not working on it ( Client Certificate Required (Unsupported) )

I think I'll wait until 2.3.3/2.3.4 is officially tagged and try again then.

Thanks!

Wait, is really https://tildegit.org/sloum/bombadillo/commit/97b74ea7672f511855a5665ebff9334c9b5bd724 the latest version? Certificates are not working on it ( Client Certificate Required (Unsupported) ) I think I'll wait until 2.3.3/2.3.4 is officially tagged and try again then. Thanks!

sloum added the

gemini

in progress

labels 2020-10-24 17:15:10 +00:00

nixo commented

2020-10-24 17:17:05 +00:00

Maybe I don't understand how develop relates to master, what are the two releaseN branches and what is tagged (and shown under Releases)

makeworld commented

2020-10-24 18:18:50 +00:00

Certificates are not working on it ( Client Certificate Required (Unsupported) )

Certificate support has been removed from bombadillo to reduce complexity.

> Certificates are not working on it ( Client Certificate Required (Unsupported) ) Certificate support has been removed from bombadillo to reduce complexity.

nixo commented

2020-10-24 18:32:32 +00:00

Oh. Out of 18 status defined by the current protocol, 3 are about certificates. I don't think removing them from this client is the right choice, as it is the main advantage I see over HTTP. They are not even an optional part of the protocol, so not supporting them is not exactly a viable solution if you want a compliant client.

sloum commented

2020-10-24 21:30:44 +00:00

@nixo Bombadillo still recognizes and responds to all of the status codes. What was removed is Bombadillo support for client side certificates. Validation is absolutely still done for standard TLS handshake oriented certs/tofu, Bombadillo just will not send a custom client cert.

From the spec:

3.2.7 Notes

[...] Basic clients may also choose not to support client-certificate authentication [...]

A large part of removing client certs was that Bombadillo is not a gemini client (at least, not first and foremost). If anything, it is a gopher client (that also has gemini support). As gemini developed (work for supporting gemini in Bombadillo started before gemini had a name) things started to get more complex. That complexity has led to an outsized growth in both code to support gemini as well as the number of bug reports and feature requests I was getting. It got to the point that I was going to stop working on Bombadillo entirely, or drop gemini support from it entirely. Removing client certs, simplifying some other features, and deciding that Bombadillo does not need to be everything to everyone was a part of the compromise I made with myself to continue development. There are definitely a lot of clients out there and many do support client certificates, but for every client that supports everything there seem to be ten or more that dont even do any checks of the offered cert during the TLS handshake... so it is definitely a hodgepodge of client support at the moment.

I may revisit client certs in the future. I'm not saying they are out forever, but the implementation I had of them was generally agreed to be poor at best and a security problem at worst. I dont have the spoons to build it out right now, but maybe someday. :)

Sorry for the very long explanation.

@nixo Bombadillo still recognizes and responds to all of the status codes. What was removed is Bombadillo support for client side certificates. Validation is absolutely still done for standard TLS handshake oriented certs/tofu, Bombadillo just will not send a custom client cert. From the spec: > 3.2.7 Notes > > [...] **Basic clients may also choose not to support client-certificate authentication** [...] A large part of removing client certs was that Bombadillo is not a gemini client (at least, not first and foremost). If anything, it is a gopher client (that also has gemini support). As gemini developed (work for supporting gemini in Bombadillo started before gemini had a name) things started to get more complex. That complexity has led to an outsized growth in both code to support gemini as well as the number of bug reports and feature requests I was getting. It got to the point that I was going to stop working on Bombadillo entirely, or drop gemini support from it entirely. Removing client certs, simplifying some other features, and deciding that Bombadillo does not need to be everything to everyone was a part of the compromise I made with myself to continue development. There are definitely a lot of clients out there and many do support client certificates, but for every client that supports everything there seem to be ten or more that dont even do any checks of the offered cert during the TLS handshake... so it is definitely a hodgepodge of client support at the moment. I may revisit client certs in the future. I'm not saying they are out forever, but the implementation I had of them was generally agreed to be poor at best and a security problem at worst. I dont have the spoons to build it out right now, but maybe someday. :) Sorry for the very long explanation.

nixo commented

2020-10-24 22:45:33 +00:00

Thanks for the explanation!

I just recently come to gemini, and the first client I found out was bombadillo. I tried other clients so far (elpher and kristall), both supporting certificates, so wanting to develop some website on gemini, I thought I could take advantage of this feature.

Bombadillo works well enough, and support for certificates was already in place, I just thought it's a pity to drop it, but I sure understand your reasons.

Thanks! :)
Nicolò

Thanks for the explanation! I just recently come to gemini, and the first client I found out was bombadillo. I tried other clients so far (elpher and kristall), both supporting certificates, so wanting to develop some website on gemini, I thought I could take advantage of this feature. Bombadillo works well enough, and support for certificates was already in place, I just thought it's a pity to drop it, but I sure understand your reasons. Thanks! :) Nicolò

sloum closed this issue

2020-11-02 02:57:28 +00:00

Sign in to join this conversation.