JetForce vs. Molly Brown Server: CGI-variable SCRIPT_NAME is not present

Hi everybody,

i am not sure if the author of the Molly-Brown server is reading this 
list, i tried to sign up on tildegit.org, but they won't accept my e-mail 
address there. I have created a perl-package to make the development of 
CGI programs for the gemini-space somewhat easier for perl-programmers, 
especially the handling of multiple parameters can be handled fully 
transparent for the application.

But that mechanism is based on the SCRIPT_NAME cgi-variable!

I started on my soon-to-be production server with an installation of the 
/JetForce-server/ and a CGI-program will find this (example) environment 
there, the important variables for cgi-programs are marked in bold:

GATEWAY_INTERFACE=CGI/1.1
*GEMINI_URL*=gemini://h2903872.stratoserver.net/cgi-bin/man/env
*HOSTNAME*=h2903872.stratoserver.net
*PATH_INFO*=/env
PWD=/opt/jetforce
*QUERY_STRING*=
REMOTE_ADDR=184.14.157.147
REMOTE_HOST=184.14.157.147
*SCRIPT_NAME*=/cgi-bin/man
SERVER_NAME=h2903872.stratoserver.net
SERVER_PORT=1965
SERVER_PROTOCOL=GEMINI
SERVER_SOFTWARE=jetforce/0.8.1
SHLVL=1
TLS_CIPHER=TLS_AES_256_GCM_SHA384
TLS_VERSION=TLSv1.3

On my development-VM i wasn't able to install JetForce (only python 3.6 is 
available and 3.7 is required!) so i decided to go with another software, 
the Molly-Brown server, so i would also be able to test for compatibility 
issues. Compared to ththe environment above, Molly literally starves CGI programs:

GATEWAY_INTERFACE=CGI/1.1
*PATH_INFO*=
PWD=/home/gemini/molly-brown
*QUERY_STRING*=man
REMOTE_ADDR=10.10.10.1
REQUEST_METHOD=
*SCRIPT_PATH*=/home/gemini/gemini/cgi-bin/man
SERVER_NAME=ffappsdev.solarsystem.space
SERVER_PORT=1965
SERVER_PROTOCOL=GEMINI
SERVER_SOFTWARE=MOLLY_BROWN
SHLVL=1

The super-duper important variable /SCRIPT_NAME/ is missing. As a 
workaround, i am using the /SCRIPT_PATH/ but that works only as long as 
the the cgi-directory is named /cgi-bin/ which is sub-optimal, especially 
because Molly-Brown supports multiple cgi-directories!

Is the Molly-Brown server still actively developed or am i riding a dead 
horse here? - The last changes on tildegit.org are ~8 months old…

Thank you very much in advance for your help.

Best regards from Charleston (WV),
     Frank/2

On Mon, Apr 12, 2021 at 10:59:57PM -0400,
 Frank Jüdes <Frank.Juedes@linux4specialists.com> wrote 
 a message of 182 lines which said:

> Is the Molly-Brown server still actively developed

I did not find a public issue tracker for MollyBrown, and the one patch
I sent to the author went unanswered.

April 13, 2021 1:53 PM, "Stephane Bortzmeyer" <stephane@sources.org> wrote:

> I did not find a public issue tracker for MollyBrown, and the one patch
> I sent to the author went unanswered.

from the list of software in gemini.circumlunar.space, links to:
https://tildegit.org/solderpunk/molly-brown (where the last commit as 3 months ago)

And there is a tracker
https://tildegit.org/solderpunk/molly-brown/issues

Stephane Bortzmeyer <stephane@sources.org> writes:

> I did not find a public issue tracker for MollyBrown, and the one patch
> I sent to the author went unanswered.

i.e. one you don't have to register for? Because otherwise:

   https://tildegit.org/solderpunk/molly-brown/issues

Still, yeah, Solderpunk isn't around much nowadays; i sent a patch for the 
telem BBS in September last year, and i believe it's not yet applied ....

(i also submitted a couple of patches for Elpher seven months ago, adding 
link numbering, but Elpher's maintainer doesn't seem to be active either.)


Alexis.

On Tue, Apr 13, 2021 at 07:06:03AM +0000,
 hedy@tilde.cafe <hedy@tilde.cafe> wrote 
 a message of 6 lines which said:

> And there is a tracker
> https://tildegit.org/solderpunk/molly-brown/issues

Thanks. But I do not find a way to open an issue. It requires a tilde
account, which is not open to the public.

On Tue, Apr 13, 2021 at 05:09:54PM +1000,
 Alexis <flexibeast@gmail.com> wrote 
 a message of 21 lines which said:

> i.e. one you don't have to register for?

Registering is not a problem, I have an account at many gitlabs and
giteas :-} But, here, registration seems not open.

Hi Hedy,

I have both web-links, thank you very much! - The problem is, that 
tildegit.org won't allow you to sign up if you don't have an e-mail 
account in one of their white-listed domains and i have more than enough 
e-mail adresses already. So i won't be able to file an issue in the tracker.

On 2021-04-13 03:06, hedy@tilde.cafe wrote:
> April 13, 2021 1:53 PM, "Stephane Bortzmeyer" <stephane@sources.org> wrote:
> 
>> I did not find a public issue tracker for MollyBrown, and the one patch
>> I sent to the author went unanswered.
> from the list of software in gemini.circumlunar.space, links to:
> https://tildegit.org/solderpunk/molly-brown (where the last commit as 3 months ago)
> 
> And there is a tracker
> https://tildegit.org/solderpunk/molly-brown/issues
-- ------------------------------------------------------------------------
Frank Jüdes
2814 Four Mile Road
Charleston, WV 25312, USA
Cell: +1-713-885-4421
------------------------------------------------------------------------

April 13, 2021 3:52 AM, "Stephane Bortzmeyer" <stephane@sources.org> wrote:

> On Tue, Apr 13, 2021 at 05:09:54PM +1000,
> Alexis <flexibeast@gmail.com> wrote 
> a message of 21 lines which said:
> 
>> i.e. one you don't have to register for?
> 
> Registering is not a problem, I have an account at many gitlabs and
> giteas :-} But, here, registration seems not open.

Registration for tildegit is open to any member of any tilde in the 
Tildeverse (tilde.town, tilde.team, etc.) The reason it's whitelisted is 
to help cut down on possible spam. All of the tildes in the Tildeverse 
have open account registration. (SDF might be whitelisted too? Don't quote me on that.)

Just my two cents,
Robert "khuxkm" Miles

Hi Stephane,

Thank you very much for the update. That leaves me with three options now:

1. Try again to install Pythron 3.7+ on my stubborn development machine
   (Oracle Lunix 7…)
2. Learn go really quickly and fork the Molly Brown server - i will
   call it »the sunken Molly Brown server« in that case
3. Write my own gemini server from scratch in perl

It really looks like only Molly Brown and JetForce have a usable 
CGI-implementation. We should call it GGI, btw: Gemini Gateway Interface 
to distinguish it from CGI.

Best regards from Charleston (WV),
     Frank/2


On 2021-04-13 03:09, Alexis wrote:
> 
> Stephane Bortzmeyer <stephane@sources.org> writes:
> 
>> I did not find a public issue tracker for MollyBrown, and the one patch
>> I sent to the author went unanswered.
> 
> i.e. one you don't have to register for? Because otherwise:
> 
>   https://tildegit.org/solderpunk/molly-brown/issues
> 
> Still, yeah, Solderpunk isn't around much nowadays; i sent a patch for 
the telem BBS in September last year, and i believe it's not yet applied ....
> 
> (i also submitted a couple of patches for Elpher seven months ago, 
adding link numbering, but Elpher's maintainer doesn't seem to be active either.)
> 
> 
> Alexis.
-- ------------------------------------------------------------------------
Frank Jüdes
2814 Four Mile Road
Charleston, WV 25312, USA
Cell: +1-713-885-4421
------------------------------------------------------------------------

On Mon, Apr 12, 2021 at 10:59:57PM -0400, Frank Jüdes said:
> i am not sure if the author of the Molly-Brown server is reading this list,
> i tried to sign up on tildegit.org, but they won't accept my e-mail address
> there. I have created a perl-package to make the development of CGI programs
> for the gemini-space somewhat easier for perl-programmers, especially the
> handling of multiple parameters can be handled fully transparent for the
> application.
> 
> But that mechanism is based on the SCRIPT_NAME cgi-variable!

In the hopes that you may find this useful, I have a light wrapper I use
to write CGIs for Molly Brown in Python.  It has served me fairly well with
fairly complex CGIs.

Module:
gemini://going-flying.com/git/cgi/gemini.git/tree/master/cgi-bin/gmicgi/__init__.py

Some demo code:
gemini://going-flying.com/git/cgi/gemini.git/tree/master/cgi-bin/test

All the CGIs I have at the moment:
gemini://going-flying.com/git/cgi/gemini.git/tree/master/cgi-bin/

--Matt

---
Matthew Ernisse
matt@going-flying.com
gemini://going-flying.com/

On Tue, Apr 13, 2021 at 10:28 AM Robert "khuxkm" Miles
<khuxkm@tilde.team> wrote:
>
> April 13, 2021 3:52 AM, "Stephane Bortzmeyer" <stephane@sources.org> wrote:
>
> > On Tue, Apr 13, 2021 at 05:09:54PM +1000,
> > Alexis <flexibeast@gmail.com> wrote
> > a message of 21 lines which said:
> >
> >> i.e. one you don't have to register for?
> >
> > Registering is not a problem, I have an account at many gitlabs and
> > giteas :-} But, here, registration seems not open.
>
> Registration for tildegit is open to any member of any tilde in the 
Tildeverse (tilde.town, tilde.team, etc.) The reason it's whitelisted is 
to help cut down on possible spam. All of the tildes in the Tildeverse 
have open account registration. (SDF might be whitelisted too? Don't quote me on that.)
>
> Just my two cents,
> Robert "khuxkm" Miles

If you go to the login page on tildegit [0], there are two buttons on
the bottom to sign in using oauth2 with either your github or twitter
account. The twitter link appears to be broken(?), but I can confirm
that the github integration works just fine and allows you to login
and interact with projects *without* having a special email address.

There's also some kind of openID integration [1] that I haven't tried
but it looks like an alternative login method if you are opposed to
having a github account for whatever reason.

- Michael

[0] https://tildegit.org/user/login
[1] https://tildegit.org/user/login/openid

Frank Jüdes <Frank.Juedes@linux4specialists.com> writes:

> Hi Stephane,
>
> Thank you very much for the update. That leaves me with three options now:
>
> 1. Try again to install Pythron 3.7+ on my stubborn development machine
>    (Oracle Lunix 7…)
> 2. Learn go really quickly and fork the Molly Brown server - i will
>    call it »the sunken Molly Brown server« in that case
> 3. Write my own gemini server from scratch in perl
>
> It really looks like only Molly Brown and JetForce have a usable
> CGI-implementation. We should call it GGI, btw: Gemini Gateway
> Interface to distinguish it from CGI.

They're definitely not the only one: GLV-1.12556 and gmid (disclaimer:
I'm the author) have a complete CGI support.  GLV-1.12556 has even more
things, such as SGCI support; and you may want to count vger in that
list too, even it's a little limited in this regard.

Also, why reinvent the wheel and find another name when the CGI
specification, modulo one or two environment variables (REQUEST_METHOD -
and is debatable), maps well to Gemini?

> Best regards from Charleston (WV),
>      Frank/2
>
>
> On 2021-04-13 03:09, Alexis wrote:
>>
>> Stephane Bortzmeyer <stephane@sources.org> writes:
>>
>>> I did not find a public issue tracker for MollyBrown, and the one patch
>>> I sent to the author went unanswered.
>>
>> i.e. one you don't have to register for? Because otherwise:
>>
>>   https://tildegit.org/solderpunk/molly-brown/issues
>>
>> Still, yeah, Solderpunk isn't around much nowadays; i sent a patch
>> for the telem BBS in September last year, and i believe it's not yet
>> applied ....
>>
>> (i also submitted a couple of patches for Elpher seven months ago,
>> adding link numbering, but Elpher's maintainer doesn't seem to be
>> active either.)
>>
>>
>> Alexis.

Hi Omar,

For GLV-1.12556 i would have to install lua, a language with which i am 
not comfortable at all. Also my Linux Distro doesn't include the LibreSSL… 
yes i know you can always configure, make and  make install, but just want 
to install a gemini-server and not make a phd.

GMID i actually had considered because it is written C meaning it is 
/fast/!  But i wasn't sure about the CGI capabilities, like which 
environment variables are available for CGI programs. If you can help me 
out here i will definitely consider gmid for both the production and my 
development box and gladly provide you with feedback.

As for the name GGI: For writing CGI programs /perl/ has been my favorite 
language since eons - no discussions about programming-languages 
necessary, you cannot master them all and over the years you develop your 
favorites - so in perl there is the "gold-standard" package for CGI 
programs with the name /CGI.pm/ therefore i could not use the same name 
for my package. So i named it /GGI.pm/ no evil intend, no re-inventing the 
wheel, sheer necessity for a good and short name.

On 2021-04-13 11:18, Omar Polo wrote:
> Frank Jüdes <Frank.Juedes@linux4specialists.com> writes:
> 
>> Hi Stephane,
>> 
>> Thank you very much for the update. That leaves me with three options now:
>> 
>> 1. Try again to install Pythron 3.7+ on my stubborn development machine
>>     (Oracle Lunix 7…)
>> 2. Learn go really quickly and fork the Molly Brown server - i will
>>     call it »the sunken Molly Brown server« in that case
>> 3. Write my own gemini server from scratch in perl
>> 
>> It really looks like only Molly Brown and JetForce have a usable
>> CGI-implementation. We should call it GGI, btw: Gemini Gateway
>> Interface to distinguish it from CGI.
> They're definitely not the only one: GLV-1.12556 and gmid (disclaimer:
> I'm the author) have a complete CGI support.  GLV-1.12556 has even more
> things, such as SGCI support; and you may want to count vger in that
> list too, even it's a little limited in this regard.
> 
> Also, why reinvent the wheel and find another name when the CGI
> specification, modulo one or two environment variables (REQUEST_METHOD -
> and is debatable), maps well to Gemini?
> 
>> Best regards from Charleston (WV),
>>       Frank/2
>> 
>> 
>> On 2021-04-13 03:09, Alexis wrote:
>>> Stephane Bortzmeyer <stephane@sources.org> writes:
>>> 
>>>> I did not find a public issue tracker for MollyBrown, and the one patch
>>>> I sent to the author went unanswered.
>>> i.e. one you don't have to register for? Because otherwise:
>>> 
>>>    https://tildegit.org/solderpunk/molly-brown/issues
>>> 
>>> Still, yeah, Solderpunk isn't around much nowadays; i sent a patch
>>> for the telem BBS in September last year, and i believe it's not yet
>>> applied ....
>>> 
>>> (i also submitted a couple of patches for Elpher seven months ago,
>>> adding link numbering, but Elpher's maintainer doesn't seem to be
>>> active either.)
>>> 
>>> 
>>> Alexis.

Hi Matthew,

nice job! some parts really do look similar to my perl-code - same problem 
generates similar programs…

I am able to read python-code, but have very little experience with the 
language. That "whitespace has a meaning" thing from the first version 
really kept me away…

My GGI-package goes a little further with automatic redirection:

 * if the variable QUERY_STRING is not empty, it will print a temporary
   re-direct with the content of tge query-string attached to the URL
   into the PATH-component (PATH_INFO) and exit.
 * This will change the url from for example:
   gemini://server.domain/cgi-bin/man?grep to
   gemini://server.domain/cgi-bin/man/grep, so that the next input can
   be requested from the client without overwriting the first value
 * All this happens transparent for the application without the
   developer to re-implement that re-direct in each program.

My gemini-capsule is not yet officially on-line, but you can find the 
GGI-package at gemini://h2903872.stratoserver.net/


On 2021-04-13 10:59, Matthew Ernisse wrote:
> On Mon, Apr 12, 2021 at 10:59:57PM -0400, Frank Jüdes said:
>> i am not sure if the author of the Molly-Brown server is reading this list,
>> i tried to sign up on tildegit.org, but they won't accept my e-mail address
>> there. I have created a perl-package to make the development of CGI programs
>> for the gemini-space somewhat easier for perl-programmers, especially the
>> handling of multiple parameters can be handled fully transparent for the
>> application.
>> 
>> But that mechanism is based on the SCRIPT_NAME cgi-variable!
> In the hopes that you may find this useful, I have a light wrapper I use
> to write CGIs for Molly Brown in Python.  It has served me fairly well with
> fairly complex CGIs.
> 
> Module:
> gemini://going-flying.com/git/cgi/gemini.git/tree/master/cgi-bin/gmicgi/__init__.py
> 
> Some demo code:
> gemini://going-flying.com/git/cgi/gemini.git/tree/master/cgi-bin/test
> 
> All the CGIs I have at the moment:
> gemini://going-flying.com/git/cgi/gemini.git/tree/master/cgi-bin/
> 
> --Matt
> 
> ---
> Matthew Ernisse
> matt@going-flying.com
> gemini://going-flying.com/
>

April 13, 2021 10:50 AM, "Frank Jüdes" <Frank.Juedes@linux4specialists.com> wrote:

> Hi Stephane,
> 
> Thank you very much for the update. That leaves me with three options now:

Actually there are four. :P

> 1. Try again to install Pythron 3.7+ on my stubborn development machine
> (Oracle Lunix 7…)
> 2. Learn go really quickly and fork the Molly Brown server - i will
> call it »the sunken Molly Brown server« in that case
> 3. Write my own gemini server from scratch in perl

4. Use literally any other Gemini server. gemserv[1], for instance, 
correctly implements PATH_INFO (which is actually the issue here, since 
SCRIPT_PATH -> SCRIPT_NAME is as simple as figuring out the base directory 
of the Gemini server) and SCRIPT_NAME (so you don't have to do the 
SCRIPT_PATH trickery). There are others as well.

> It really looks like only Molly Brown and JetForce have a usable CGI-implementation.

Again, gemserv and other servers have usable CGI implementations 
(including gemserv actually implementing SCRIPT_NAME and PATH_INFO).

> We should call it GGI, btw: Gemini Gateway Interface to distinguish it from CGI.

Why, exactly? I get the fact that you can't name your library CGI.pm, but 
that doesn't really warrant changing the name of an entire technology. :P

Just my two cents,
Robert "khuxkm" Miles

Just realized I forgot to link gemserv. My bad.

[1]: https://git.sr.ht/~int80h/gemserv

Just my two cents,
Robert "khuxkm" Miles

April 13, 2021 12:52 PM, "Robert "khuxkm" Miles" <khuxkm@tilde.team> wrote:

> April 13, 2021 10:50 AM, "Frank Jüdes" <Frank.Juedes@linux4specialists.com> wrote:
> 
>> Hi Stephane,
>> 
>> Thank you very much for the update. That leaves me with three options now:
> 
> Actually there are four. :P
> 
>> 1. Try again to install Pythron 3.7+ on my stubborn development machine
>> (Oracle Lunix 7…)
>> 2. Learn go really quickly and fork the Molly Brown server - i will
>> call it »the sunken Molly Brown server« in that case
>> 3. Write my own gemini server from scratch in perl
> 
> 4. Use literally any other Gemini server. gemserv[1], for instance, 
correctly implements PATH_INFO
> (which is actually the issue here, since SCRIPT_PATH -> SCRIPT_NAME is 
as simple as figuring out
> the base directory of the Gemini server) and SCRIPT_NAME (so you don't 
have to do the SCRIPT_PATH
> trickery). There are others as well.
> 
>> It really looks like only Molly Brown and JetForce have a usable CGI-implementation.
> 
> Again, gemserv and other servers have usable CGI implementations 
(including gemserv actually
> implementing SCRIPT_NAME and PATH_INFO).
> 
>> We should call it GGI, btw: Gemini Gateway Interface to distinguish it from CGI.
> 
> Why, exactly? I get the fact that you can't name your library CGI.pm, 
but that doesn't really
> warrant changing the name of an entire technology. :P
> 
> Just my two cents,
> Robert "khuxkm" Miles

Frank Jüdes <Frank.Juedes@linux4specialists.com> writes:

> Hi Omar,
>
> For GLV-1.12556 i would have to install lua, a language with which i
> am not comfortable at all. Also my Linux Distro doesn't include the
> LibreSSL… yes i know you can always configure, make and  make install,
> but just want to install a gemini-server and not make a phd.

I can sympathise with this.  I haven't really even tried to run
GLV-1.12556 because of the steps needed to run it!  I have only talked
with Sean some time ago, he pointed out some issues with the CGI
implementation in gmid, and so I took a look at how GLV implements them.

> GMID i actually had considered because it is written C meaning it is
> /fast/!  But i wasn't sure about the CGI capabilities, like which
> environment variables are available for CGI programs. If you can help
> me out here i will definitely consider gmid for both the production
> and my development box and gladly provide you with feedback.

gmid at the moment shares the same problem of GLV-1.12556: it has
LibreSSL as dependency (which I don't regret by the way, it has such a
clean API it's almost a joy to use: compare the code in server.c to the
OpenSSL-specific bits in utils.c!)

[ I've started to develop a library to write Gemini clients and server
  that, among other things, has an abstraction over the specific TLS
  library: this helps for testing and should help with portability
  across different systems I hope. ]

The details of the CGI variable available are documented in the manpage,
under the CGI section, but there is also a test page I'm serving at:

	gemini://gemini.omarpolo.com/cgi/env/

I should probably link it in the README.  Note: that demo page it's
lacking TLS_VERSION, TLS_CIPHER and TLS_CIPHER_STRENGTH that I committed
early this morning.

There is also a similar page for GLV-1.12556:

	gemini://gemini.conman.org/cgi

[ actually, my page is inspired from the GLV-1.12556 one, not the other
  way around of course! ]

> As for the name GGI: For writing CGI programs /perl/ has been my
> favorite language since eons - no discussions about
> programming-languages necessary, you cannot master them all and over
> the years you develop your favorites - so in perl there is the
> "gold-standard" package for CGI programs with the name /CGI.pm/
> therefore i could not use the same name for my package. So i named it
> /GGI.pm/ no evil intend, no re-inventing the wheel, sheer necessity
> for a good and short name.

I think I misunderstood your last mail then, apologies.

Anyway, talking about timing, earlier I was re-writing my `man' CGI
script from rc to Perl!  (I'm not familiar at all with the language, but
I'm slowly learning.)  If/when your module will be ready, I would like
to play with it.  I have a couple of CGI scripts written in different
languages, and I'm slowly re-writing the ones in shell/rc to perl.

> On 2021-04-13 11:18, Omar Polo wrote:
>> Frank Jüdes <Frank.Juedes@linux4specialists.com> writes:
>>
>>> Hi Stephane,
>>>
>>> Thank you very much for the update. That leaves me with three options now:
>>>
>>> 1. Try again to install Pythron 3.7+ on my stubborn development machine
>>>     (Oracle Lunix 7…)
>>> 2. Learn go really quickly and fork the Molly Brown server - i will
>>>     call it »the sunken Molly Brown server« in that case
>>> 3. Write my own gemini server from scratch in perl
>>>
>>> It really looks like only Molly Brown and JetForce have a usable
>>> CGI-implementation. We should call it GGI, btw: Gemini Gateway
>>> Interface to distinguish it from CGI.
>> They're definitely not the only one: GLV-1.12556 and gmid (disclaimer:
>> I'm the author) have a complete CGI support.  GLV-1.12556 has even more
>> things, such as SGCI support; and you may want to count vger in that
>> list too, even it's a little limited in this regard.
>>
>> Also, why reinvent the wheel and find another name when the CGI
>> specification, modulo one or two environment variables (REQUEST_METHOD -
>> and is debatable), maps well to Gemini?
>>
>>> Best regards from Charleston (WV),
>>>       Frank/2
>>>
>>>
>>> On 2021-04-13 03:09, Alexis wrote:
>>>> Stephane Bortzmeyer <stephane@sources.org> writes:
>>>>
>>>>> I did not find a public issue tracker for MollyBrown, and the one patch
>>>>> I sent to the author went unanswered.
>>>> i.e. one you don't have to register for? Because otherwise:
>>>>
>>>>    https://tildegit.org/solderpunk/molly-brown/issues
>>>>
>>>> Still, yeah, Solderpunk isn't around much nowadays; i sent a patch
>>>> for the telem BBS in September last year, and i believe it's not yet
>>>> applied ....
>>>>
>>>> (i also submitted a couple of patches for Elpher seven months ago,
>>>> adding link numbering, but Elpher's maintainer doesn't seem to be
>>>> active either.)
>>>>
>>>>
>>>> Alexis.

Thank you very much Robert!

The reason why i have not considered gemserv is that it is written in 
/rust/ another language to which my exposure is NULL!

And the instructions on your website scared me off: As said, i am not a 
rust developer and there are none of the rust tools installed on any of my 
machines, so i would have to install the basic rust toolchain first…


On 2021-04-13 12:54, Robert "khuxkm" Miles wrote:
> Just realized I forgot to link gemserv. My bad.
> 
> [1]: https://git.sr.ht/~int80h/gemserv
> 
> Just my two cents,
> Robert "khuxkm" Miles
> 
> April 13, 2021 12:52 PM, "Robert "khuxkm" Miles" <khuxkm@tilde.team> wrote:
> 
>> April 13, 2021 10:50 AM, "Frank Jüdes" <Frank.Juedes@linux4specialists.com> wrote:
>> 
>>> Hi Stephane,
>>> 
>>> Thank you very much for the update. That leaves me with three options now:
>> Actually there are four. :P
>> 
>>> 1. Try again to install Pythron 3.7+ on my stubborn development machine
>>> (Oracle Lunix 7…)
>>> 2. Learn go really quickly and fork the Molly Brown server - i will
>>> call it »the sunken Molly Brown server« in that case
>>> 3. Write my own gemini server from scratch in perl
>> 4. Use literally any other Gemini server. gemserv[1], for instance, 
correctly implements PATH_INFO
>> (which is actually the issue here, since SCRIPT_PATH -> SCRIPT_NAME is 
as simple as figuring out
>> the base directory of the Gemini server) and SCRIPT_NAME (so you don't 
have to do the SCRIPT_PATH
>> trickery). There are others as well.
>> 
>>> It really looks like only Molly Brown and JetForce have a usable CGI-implementation.
>> Again, gemserv and other servers have usable CGI implementations 
(including gemserv actually
>> implementing SCRIPT_NAME and PATH_INFO).
>> 
>>> We should call it GGI, btw: Gemini Gateway Interface to distinguish it from CGI.
>> Why, exactly? I get the fact that you can't name your library CGI.pm, 
but that doesn't really
>> warrant changing the name of an entire technology. :P
>> 
>> Just my two cents,
>> Robert "khuxkm" Miles
-- ------------------------------------------------------------------------
Frank Jüdes
2814 Four Mile Road
Charleston, WV 25312, USA
Cell: +1-713-885-4421
------------------------------------------------------------------------

It was thus said that the Great Frank Jüdes once stated:
> Hi Omar,
> 
> For GLV-1.12556 i would have to install lua, a language with which i am 
> not comfortable at all. Also my Linux Distro doesn't include the 
> LibreSSL… yes i know you can always configure, make and  make install, 
> but just want to install a gemini-server and not make a phd.

  Hmm, I see I need to update the README for GLV-1.12556.  I switched from
using LibreSSL to OpenSSL 1.1.1 and libretls, a libtls wrapper for OpenSSL. 
That requires the use of OpenSSL 1.1.1b or higher, but I feel it's worth it
just becauase libtls is so easy to use.

  Anyway, just thought I should mention it.

  -spc

If you're looking for an alternative to Molly Brown and Jetforce I'd like 
to plug my stargazer[1]. It should support all of the CGI vars you need as 
I pretty much copied Jetforce. If not, let me know. I can add tweak things.

[1]: https://sr.ht/~zethra/stargazer/

Hi Ben,

i already looked at your server and absolutely liked what i saw! The only 
concern i had was this:

> 
>         Know security issues
> 
> 
>           #
>           <https://sr.ht/~zethra/stargazer/#root-escape---pre-040>Root
>           escape - pre 0.4.0
> 
> Stargazer would serve files from anywhere on the file system if a path 
starting with // was requested.
> 
If that is fixed i am more than willing to give it a try. Which version of 
Python3 does it need? - Without going through the hassle of a manual 
python install on a production server all i have available is 3.6.8.

Best regards from Charleston (WV),
     Frank/2

On 2021-04-14 13:26, Ben Goldberg wrote:
> If you're looking for an alternative to Molly Brown and Jetforce I'd 
like to plug my stargazer[1]. It should support all of the CGI vars you 
need as I pretty much copied Jetforce. If not, let me know. I can add tweak things.
> 
> [1]: https://sr.ht/~zethra/stargazer/
-- ------------------------------------------------------------------------

On Tue, 2021-04-13, Robert "khuxkm" Miles wrote:
> April 13, 2021 3:52 AM, "Stephane Bortzmeyer" <stephane@sources.org> wrote:
>> Registering is not a problem, I have an account at many gitlabs and
>> giteas :-} But, here, registration seems not open.
> 
> Registration for tildegit is open to any member of any tilde in the
> Tildeverse (tilde.town, tilde.team, etc.) The reason it's whitelisted
> is to help cut down on possible spam. All of the tildes in the
> Tildeverse have open account registration. (SDF might be whitelisted
> too? Don't quote me on that.)

Allowed domains are here:
https://tildegit.org/allowed_domains.txt

They also accept outsiders:

> However, admins are happy to make an exception if you prove you're a
> real person. Stop by #helpdesk on IRC and look for ben or shoot an
> email to ben@tilde.team with your desired username and a short
> introduction.

So getting an account on tildegit is not a big deal.
https://tildegit.org/user/sign_up

Also see the GitHub and OpenID login options that Michael Lazar pointed
out:
https://tildegit.org/user/login
https://tildegit.org/user/login/openid

>>         Know security issues
>> 
>> 
>>           #
>>           <https://sr.ht/~zethra/stargazer/#root-escape---pre-040>Root
>>           escape - pre 0.4.0
>> 
>> Stargazer would serve files from anywhere on the file system if a path 
starting with // was requested.

Yes, that is fixed in the current version! (maybe I should make that more 
clear in the readme) An embarrassing bug, but better to be honest about it.

stargazer is written in Rust and doesn't have any runtime 
dependencies(including OpenSSL). If you're on Linux, you can grab a binary 
from here[1] or compile it yourself. The provided binary is compiled 
against musl so it *should* work regardless of distro. It should also work 
on other OSs but I haven't done much testing. If you run into any issues 
please send an email to the stargazer mailing list[2].

[1]: https://git.sr.ht/~zethra/stargazer/refs/download/0.4.0/stargazer-0.4.
0-x86_64-linux-musl.tar.xz
[2]: https://lists.sr.ht/~zethra/stargazer