💾 Archived View for gemi.dev › gemini-mailing-list › 000022.gmi captured on 2024-08-25 at 08:44:16. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
One downside of Gemini's support for redirection is that poorly written/configured servers can in principle get clients stuck in infinite loops of redirects, or just lead clients on long chains of many consecutive redirects. High quality Gemini clients should be able to recognise these conditions and escape, rather than just endlessly following redirects and appearing to "lock up" to the user. It occurs to me that, Sean, this kind of thing could be a very useful addition to your already very useful Gemini client "torture test". Do you have any interest in coding this up? I'm adding code to deal with this in AV-98 now, and I hope that others will follow suit. It would be nice for people to be able to easily confirm that their escape logic is working correctly. -Solderpunk
It was thus said that the Great solderpunk once stated:
> One downside of Gemini's support for redirection is that poorly
> written/configured servers can in principle get clients stuck in
> infinite loops of redirects, or just lead clients on long chains of many
> consecutive redirects. High quality Gemini clients should be able to
> recognise these conditions and escape, rather than just endlessly
> following redirects and appearing to "lock up" to the user.
>
> It occurs to me that, Sean, this kind of thing could be a very useful
> addition to your already very useful Gemini client "torture test". Do
> you have any interest in coding this up?
Already done. It took more time to write up the test page than it was to
write the code, which is just three lines:
function handler(_,_,loc)
return 31,uurl.toa(uurl.merge(loc,{ path = tostring(uuid()) })),""
end
And speaking of tests, have you finished the Gemini server torture test?
-spc
It was thus said that the Great Sean Conner once stated:
> It was thus said that the Great solderpunk once stated:
> > One downside of Gemini's support for redirection is that poorly
> > written/configured servers can in principle get clients stuck in
> > infinite loops of redirects, or just lead clients on long chains of many
> > consecutive redirects. High quality Gemini clients should be able to
> > recognise these conditions and escape, rather than just endlessly
> > following redirects and appearing to "lock up" to the user.
> >
> > It occurs to me that, Sean, this kind of thing could be a very useful
> > addition to your already very useful Gemini client "torture test". Do
> > you have any interest in coding this up?
>
> Already done. It took more time to write up the test page than it was to
> write the code, which is just three lines:
>
> function handler(_,_,loc)
> return 31,uurl.toa(uurl.merge(loc,{ path = tostring(uuid()) })),""
> end
>
> And speaking of tests, have you finished the Gemini server torture test?
Actually, let me amend that. I made three tests (and the handler doubled
in size)---one to send a series of continuous temporary redirects, one to
send a series of permanent redirects, and one that will continously send a
random type of redirect.
Anyway, have fun with the tests.
-spc
Solderpunk wrote: > High quality Gemini clients should be able to > recognise these conditions and escape, rather than just endlessly > following redirects and appearing to "lock up" to the user. I absolutely agree. Bombadillo, as a matter of transparency, notifies the user that a redirect has been requested and asks if they would like to follow it or not. This leaves it always in the user's hands whether or not to proceed. I also think this would be a good addition to the torture test, though I am unsure as a way to validate that a client behvaed correctly.
It was thus said that the Great Brian Evans once stated: > Solderpunk wrote: > > High quality Gemini clients should be able to > > recognise these conditions and escape, rather than just endlessly > > following redirects and appearing to "lock up" to the user. > > I absolutely agree. Bombadillo, as a matter of transparency, notifies the user that a redirect > has been requested and asks if they would like to follow it or not. This leaves it always in > the user's hands whether or not to proceed. > > I also think this would be a good addition to the torture test, though I am unsure as a way > to validate that a client behvaed correctly. Point the client to any of the following: gemini://gemini.conman.org/test/redirhell/ gemini://gemini.conman.org/test/redirhell2/ gemini://gemini.conman.org/test/redirhell3/ gemini://gemini.conman.org/test/redirhell4 gemini://gemini.conman.org/test/redirhell5 (NOTE: the links will continuously redirect) I suspect that most would expect the client to stop making requests after N redirects. What's N? That hasn't been decided yet. -spc
Sean Conner writes: > Point the client to any of the following: > > gemini://gemini.conman.org/test/redirhell/ > gemini://gemini.conman.org/test/redirhell2/ > gemini://gemini.conman.org/test/redirhell3/ > gemini://gemini.conman.org/test/redirhell4 > gemini://gemini.conman.org/test/redirhell5 > > (NOTE: the links will continuously redirect) Thanks Sean, this is great. > I suspect that most would expect the client to stop making requests after > N redirects. What's N? That hasn't been decided yet. In addition to a redirect threshold, it's of course also easy for clients to keep track of the addresses seen during a redirect sequence, in which case they can just abort on a redirect to a seen address. plugd
Hi Sean, Sean Conner writes: > Anyway, have fun with the tests. Thanks for these, they're very useful. I notice that you've added a sixth test at gemini://gemini.conman.org/test/torture/0027 which redirects to a non-gemini (gopher) URL. Unless my reading comprehension is failing me, the explanatory text suggests that correct handling of this redirect should be for the client to open the gopher URL. Is this behaviour really desirable? I vote for no. The text/gemini files already support links to non-gemini URLs. Allowing server-directed redirects to non-gemini URLs would simply mean that I could no longer be sure that a gemini:// URL would access a gemini resource. Meaning that I could no longer be sure that the transaction is encrypted. And that's just with gopher - the server could make all sorts of surprising things happen on my computer if the client happens to support other protocols. plugd
> Thanks Sean, this is great. It is, indeed, thanks very much. Happily, my AV-98 code worked as expected without any changes. > > I suspect that most would expect the client to stop making requests after > > N redirects. What's N? That hasn't been decided yet. I decided to set N to 5 for now, and was happily surprised to see at your test page that this very value was also (once) recommended for the same purpose in HTTP via an RFC. If nobody wants to argue strongly for a higher/lower value, I will recommend 5 in the new "best practices" document - this is exactly the kind of thing that I imagined that document being good for. > In addition to a redirect threshold, it's of course also easy for > clients to keep track of the addresses seen during a redirect sequence, > in which case they can just abort on a redirect to a seen address. AV-98 does precisely this, too. -Solderpunk
> > And speaking of tests, have you finished the Gemini server torture test? > Not only have I not finished them, it took me an embarrassingly long time to remember which tests you were talking about. Yikes! I'll try to get these published sometime soon - along, perhaps, with my long-stagnant 100 line Lua client, which I'm expecting you'll be able to improve substantially... -Solderpunk
> Is this behaviour really desirable? > > I vote for no. The text/gemini files already support links to > non-gemini URLs. Allowing server-directed redirects to non-gemini URLs > would simply mean that I could no longer be sure that a gemini:// URL > would access a gemini resource. Meaning that I could no longer be sure > that the transaction is encrypted. And that's just with gopher - the > server could make all sorts of surprising things happen on my computer > if the client happens to support other protocols. Hmm, good question! I share the intuition that cross-protocol redirects violate the principle of least surpise, and also make URLs non-transparent. I mean, redirects do that to some extent anyway, which is why some clients (like Bombadillo) request explicit confirmation before following any (I may add this as a user-specifiable option to AV-98), but cross-protocol redirects are arguably as bad as it gets. I think I'd be happy to explicitly forbid these in the spec, unless somebody can think of a compelling legitimate use case? -Solderpunk
It was thus said that the Great solderpunk once stated: > > > > And speaking of tests, have you finished the Gemini server torture test? > > > Not only have I not finished them, it took me an embarrassingly long > time to remember which tests you were talking about. Yikes! I'll > try to get these published sometime soon - along, perhaps, with my > long-stagnant 100 line Lua client, which I'm expecting you'll be able to > improve substantially... Well, my own very simplistic Lua client is 171 lines of code so ... -spc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/14/2019 8:45 AM, plugd wrote: > > Sean Conner writes: >> Anyway, have fun with the tests. > > Thanks for these, they're very useful. > > I notice that you've added a sixth test at > gemini://gemini.conman.org/test/torture/0027 which redirects to a > non-gemini (gopher) URL. Unless my reading comprehension is > failing me, the explanatory text suggests that correct handling of > this redirect should be for the client to open the gopher URL. > > Is this behaviour really desirable? > > I vote for no. The text/gemini files already support links to > non-gemini URLs. Allowing server-directed redirects to non-gemini > URLs would simply mean that I could no longer be sure that a > gemini:// URL would access a gemini resource. Meaning that I could > no longer be sure that the transaction is encrypted. And that's > just with gopher - the server could make all sorts of surprising > things happen on my computer if the client happens to support other > protocols. > I can't see any value in server redirects to other protocols, especially since many clients will not support other protocols, and of those, the one's that will actually be part of the effect that launches another client (i.e, Gopher client, Web browser, etc.) will likely be few and far between. The test itself is great but, given the potential to wreak havoc client side, don't think it's advisable too permit. Even in the case of Elpher, I'm not comfortable as a user visiting a Gemini site and encountering a server redirect to a Gopher resource even though the client does support that. I'm advocating 'shall not' or 'must not' in the curent Gemini specs. - -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268 -----BEGIN PGP SIGNATURE----- Comment: Find this cert at hkps://keys.openpgp.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQEzBAEBCAAdFiEENWT7St9Eg6sLyiLAuIw5wQytyEkFAl2k/rEACgkQuIw5wQyt yEl/qQf/f1QqohMMr8IcLtgdb+bVKqt6z/pJjNq5mTJtttogPlpzKkOT5al1CpFI PoxedbQqdqc9zwu5vakuf+q7CWt+67ERJEIRsY38WGdZtVOgXWyOMyCGkdsNJR8O 9x/Fw5tpgJULPiEWpbL0AfaE0Y8+I7VYOSlesZz7Ex6a6wcVGFh/dCTCwlbj9bI3 CWQ+D4naCoPCiBm3cVZoVuXJ94VMZnw4+5Ij3kD7ATYmhylfrNrWf3x41oSoXEEs bEs4Wgv7l5xX0gRa22yRcsaXLiOwbCJBDxHYkEwJNAWV/lJLc9Pi0Ky4A/q6qJfi +S4DcYVWQDno9hQE7ml1T9j229ubzQ== =fSFE -----END PGP SIGNATURE-----
It was thus said that the Great solderpunk once stated: > > Is this behaviour really desirable? > > > > I vote for no. The text/gemini files already support links to > > non-gemini URLs. Allowing server-directed redirects to non-gemini URLs > > would simply mean that I could no longer be sure that a gemini:// URL > > would access a gemini resource. Meaning that I could no longer be sure > > that the transaction is encrypted. And that's just with gopher - the > > server could make all sorts of surprising things happen on my computer > > if the client happens to support other protocols. > > Hmm, good question! > > I share the intuition that cross-protocol redirects violate the > principle of least surpise, and also make URLs non-transparent. I mean, > redirects do that to some extent anyway, which is why some clients (like > Bombadillo) request explicit confirmation before following any (I may > add this as a user-specifiable option to AV-98), but cross-protocol > redirects are arguably as bad as it gets. > > I think I'd be happy to explicitly forbid these in the spec, unless > somebody can think of a compelling legitimate use case? Possible actions: client denies the redirect client denies redirects to non TLS-protocols otherwise, redirects client asks to redirect or not client asks to redirect to non-TLS protocol, othersise redirects, client warns user about redirect client warns user about redirect to non-TLS protocol client does redirect I think that covers all possible actions. If it were left up to me, I would probably say "ask for redirect to non-TLS, otherwise, warn (or mention) about redirect". -spc
On Mon, Oct 14, 2019 at 07:24:59PM -0400, Sean Conner wrote: > Possible actions: > > client denies the redirect > client denies redirects to non TLS-protocols > otherwise, redirects > client asks to redirect or not > client asks to redirect to non-TLS protocol, > othersise redirects, > client warns user about redirect > client warns user about redirect to non-TLS protocol > client does redirect > Those seem to be all the sensible options. My initial instinct was to say something along the lines of: explicitly prohibiting the scariest possible kind of redirect in the spec permits client writers to take the easier route (both in terms of implementation effort and smoothness of user experience) of automatically following redirects with the understanding that the risk posed is minimal. But that's not quite true, actually. Just because the spec says cross-protocol redirects are forbidden doesn't mean malicious servers couldn't serve them up anyway. So well-written clients need to be on the lookout for this anyway, no matter what the spec says. I guess at the very least this point should be mentioned in the Best Practices doc so it's not overlooked by client iplementors. This is not to say it isn't still worthwhile forbidding them in the spec. I think I'm still inclined to do this if nobody comes forward with a compelling use case. -Solderpunk
It was thus said that the Great solderpunk once stated: > > But that's not quite true, actually. Just because the spec says > cross-protocol redirects are forbidden doesn't mean malicious servers > couldn't serve them up anyway. So well-written clients need to be on > the lookout for this anyway, no matter what the spec says. I guess at > the very least this point should be mentioned in the Best Practices doc > so it's not overlooked by client iplementors. > > This is not to say it isn't still worthwhile forbidding them in the > spec. I think I'm still inclined to do this if nobody comes forward > with a compelling use case. What about content being moved from Gemini to TOR? [1] Or an archive file that grew too big to be safely served from Gemini so a switch to HTTPS is in order? (and you don't want to break an existing link) I can see disuading people from doing that, but an ourright ban seems excessive (to me). -spc [1] I'm not sure how stuff is addressed with TOR.
Hi Sean, Sean Conner writes: > What about content being moved from Gemini to TOR? [1] Or an archive file > that grew too big to be safely served from Gemini so a switch to HTTPS is in > order? (and you don't want to break an existing link) In these edge cases, wouldn't it be preferable to simply serve up a text/gemini page with explicit information re the new link? plugd
On 10/17/2019 12:06 AM, plugd wrote: > Hi Sean, > > Sean Conner writes: >> What about content being moved from Gemini to TOR? [1] Or an archive file >> that grew too big to be safely served from Gemini so a switch to HTTPS is in >> order? (and you don't want to break an existing link) > > In these edge cases, wouldn't it be preferable to simply serve up a > text/gemini page with explicit information re the new link? > I think so. If the resource is a .gmi file that's been moved to say, a .html or .gophermap on another protocol then there's almost certainly a link pointing to the page that has been moved, and that link can be changed to provide the correct new URL. In the case of a link where a server redirect to the other protocol and resource would be performed, again, simply changing the link itself in the index.gmi would affect this change without having to hijack the users client, expecting it to be aware of different protocols itself. In the case where a resource has been moved and may have had outside referrers, a .gmi file with a link to the new URL will retain control over the action by the client. So for those, I still don't see a compelling use case for out of band server-side redirects. But what if the resource is say, an iso file, and that image has been moved somewhere else? I'm thinking an in-band server redirect to a .gmi file explaining the new location along with a link would be better than an out of band redirect to some other protocol. -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
---