Hello,

I would  like to discuss the  possibility of improving (or  backing out)
the change introduced in:

[805c931479569576] https://www.fossil-scm.org/home/info/805c931479569576

As it stands, this interferes  with SSH servers that impose restrictions
on the client command that is sent.  For example, I have a Fossil server
that does something similar to:

------------------------------------------------------------------------
#!/bin/sh
REPO="${1:-}"
set -- $SSH_ORIGINAL_COMMAND
while [ $# -gt 1 ]; do shift; done
if [ x"$REPO" != "x" ]
then
  WHICH="$REPO"
else
  WHICH="$1"
fi
case $SSH_ORIGINAL_COMMAND in
  fossil*)
    exec /path/to/fossil http "$WHICH"
  ;;
esac
sleep 10
exec /usr/bin/false
------------------------------------------------------------------------


When I  try to  pull or  clone, the operation  fails because  the server
doesn't respond (failing to recognize the command):

$ fossil clone ssh://anonfsl@fossil.bradfords.org//fossil fossil.fossil
server did not reply
Clone done, wire bytes sent: 293  received: 0  remote: fossil.bradfords.org
server returned an error - clone aborted

This  is  because  the  case  statement no  longer  matches  on  "fossil
test-http ..."  as it used  to because the  Fossil client now  sends the
equivalent of:

PATH=$HOME/bin:$PATH fossil test-http ...

While  I appreciate  the  problem that  this is  trying  to solve,  e.g.
the  PATH  for  non-interactive  shells   is  not  set  correctly,  this
seems  more  like  a  local  configuration issue  than  a  problem  with
Fossil  proper. Either  the  server administrator  should configure  the
environment correctly, or the user  should be using Fossil's support for
?fossil=bin/fossil in  the query  parameter of the  clone URL  which has
been in Fossil since the dawn of time.

Furthermore, it  just seems  odd for  Fossil to be  trying to  alter the
remote environment  to accomplish  this---I certainly don't  want Fossil
trying to alter the remote environment  of my SSH shells. Using ?fossil=
does not alter  the environment as it only controls  what remote command
the client sends, which is really what the problem is here.

Having  Fossil send  the PATH  now  means that  everyone inspecting  the
SSH_ORIGINAL_COMMAND will  have to account  for that. Arguably I  may be
the only one doing this, but it  seems less clean to be sending the PATH
in the remote command than the alternatives.

There  are  many  ways  to  go  about  addressing  this  with  SSH.  SSH
has   the   AcceptEnv[1]   and  SetEnv[3][5]/SendEnv[4]   options,   the
PermitUserEnvironment[2] option,  and of  course Fossil has  support for
?fossil= as I already suggested.

The documentation already suggests using it here:

https://www.fossil-scm.org/home/help?cmd=clone

SSH protocol:

    ssh://[userid@]host[:port]/path/to/repo.fossil[?fossil=path/fossil.exe]


Any chance we can reconsider  this new PATH implementation? Perhaps make
it a  configurable thing that  the user is  able to enable  when desired
rather than sending it always? What if the user doesn't have a $HOME/bin
but has $HOME/altbin, or some other name?

Thoughts?

Andy

[1] http://man.openbsd.org/sshd_config#AcceptEnv
[2] http://man.openbsd.org/sshd_config#PermitUserEnvironment
[3] http://man.openbsd.org/sshd_config#SetEnv
[4] http://man.openbsd.org/ssh_config#SendEnv
[5] http://man.openbsd.org/ssh_config#SetEnv

Installing fossil where expected is certainly ideal, but if the user has
no control over that, then I think  giving the user some kind of knob is
alright. I  just don't  think a statically  configured PATH  override is
suitable.

That's what  the ?fossil=  query parameter  provides, however,  that may
"feel" somewhat clunky in some cases  so it may be preferable to provide
some kind  of "server  configuration" option that  either allows  one to
specify the  absolute path (e.g.  ssh-remote-command in the DB  could be
any of /home/user/bin/fossil, bin/fossil, /opt/fossil/bin/fossil, or any
other path that is appropriate). It may  not be obvious to some that one
can change  the execution path  on the  remote host using  ?fossil= even
though it's been this way for a long time.

This  line stuffs  in the  remote fossil  command, the  default is  just
"fossil" but it can be overridden by ?fossil= in the query parameters:

https://www.fossil-scm.org/home/file?udc=1&ln=141&ci=trunk&name=src%2Fhttp_transport.c

It could just as easily, and alternatively, be derived from a DB setting.

Andy

> I'm on travel.

If you're on vacation hopefully you  ignore all this until you get back.
:-) By  no means is  this a fire  that needs to  be put out  urgently if
you're on vacation!

I just  wanted to start  a discussion since  I don't think  putting PATH
into every single invocation of Fossil is the best approach.

Thanks,

Andy

> include /usr/local/bin  here, where Fossil's  make install puts  it by
> default, when it evidently does not on your Mac?

Does your PATH have /usr/local/bin when you run:

ssh machost env

If so, I'm curious how you made that work.

[edit] I  see you already answered  the question... there's a  link that
you included which describes how.

Andy

>  but this method[1] should work. 

Is   this  the   method  that   *you*  used?   It  recommends   altering
PermitUserEnviromnent (which is one of  the options I actually suggested
in my first post on this thread).

Andy

[1] https://dev.to/spaceghost/fixing-macos-ssh-path-missing-usr-local-bin-ap

> The question then becomes, why doesn’t drh's Mac do that?

I suspect it has something to do with the difference in shells?

Some  here have  reported using  bash  or zsh.  Perhaps they  do read  a
profile for  non-interactive shells whereas  the shell he is  using does
not?

I know that on OpenBSD, the  default shell ksh(1) does not read .profile
for  non-interactive shells.  I'm  able  to make  it  work by  adjusting
login.conf(5) though.

Andy

> None of y'all use the ssh: remote method to Mac's, I'll bet....

You're absolutely  right that I don't  use Mac's very often,  however, I
completely understand the challenge and  problem. I've actually run into
it  myself and  in these  cases,  I usually  just fall  back onto  using
?fossil=, as an example, here's one of my projects that uses a different
bin directory to serve up fossil. One one of my remote hosts, I have the
Fossil binary  in a directory called  "altbin", so I end  up with things
like:

ssh://remotehost/fossils/nmh.fossil?fossil=altbin/fossil

I  also recognized  that  the  ?fossil query  paramter  may be  somewhat
clunky, which is why I suggested perhaps Fossil has some other mechanism
that  allows the  user to  override the  Fossil defaults.  One mechanism
could just be a setting stored in the DB that is the value of the remote
PATH.  Another mechanism,  which  doesn't actually  do anything  special
would be to just store what the  remote path to the Fossil binary should
be.  Maybe these  are all  just  as clunky  as using  the ?fossil  query
parameter?

Is it not possible to modify the  SSH configuration on Mac OS to provide
a sensible PATH to SSH?

Personally, I'm  fine with  the ?fossil query  parameter, it  has served
it's purpose,  but that doesn't mean  that there doesn't exist  a better
mechanism.

As for  the "it just works"  principle... well, in this  case it doesn't
always "just work". It works if you  happen to have the Fossil binary in
$HOME/bin, but that's  not where I have my Fossil  binaries. But it also
interferes  with other  uses of  the  SSH protocol,  thus limiting,  not
enhancing the experience,  so it "works" at the expense  of other things
that used to "just work".

Thanks,

Andy

> What  is the  error message  that your  system gives  when you  try to
> "fossil sync" using the ssh: method?

$ fossil sync -v -v --sshtrace
Sync with ssh://anonfsl@fossil//fossil
                Bytes      Cards  Artifacts     Deltas
RUN ssh -e none -T -- 'anonfsl@fossil' 'PATH=$HOME/bin:$PATH' fossil test-http /fossil
URL: ssh://anonfsl@fossil//fossil
Sending 182 byte header and 6698 byte payload
Got line: []
server did not reply
Sync done, wire bytes sent: 6880  received: 0  remote: fossil
Uncompressed payload sent: 0  received: 0
/***** Subprocess 16595 exit(0) *****/


When I use Fossil version b86d4da5a2 I get:

$ build/fossil-2.24 sync -v -v --sshtrace
Sync with ssh://anonfsl@fossil//fossil
                Bytes      Cards  Artifacts     Deltas
RUN ssh -e none -T -- 'anonfsl@fossil' fossil test-http /fossil
URL: ssh://anonfsl@fossil//fossil
Sending 182 byte header and 6695 byte payload
Got line: [Status: 200 OK]
Read: [Status: 200 OK]
Got line: [Cache-control: no-cache]
Read: [Cache-control: no-cache]
Got line: [X-Frame-Options: SAMEORIGIN]
Read: [X-Frame-Options: SAMEORIGIN]
Got line: [Content-Type: application/x-fossil]
Read: [Content-Type: application/x-fossil]
Got line: [Content-Length: 6686]
Read: [Content-Length: 6686]
Got line: []
Reading 6686 bytes with 0 on hand...  Got 6686 bytes
Sent:           12072        171          0          0
Received:       12024        172          0          0
Sync done, wire bytes sent: 6877  received: 6816  remote: fossil
Uncompressed payload sent: 12072  received: 12024
/***** Subprocess 34555 exit(0) *****/

Andy

> The "fossil sync -all" bug is preexisting.

It looks like this  bug was a latent bug that only  got exposed when the
"fossil sync  -all" functionality was  introduced. I've fixed it  on the
branch, though I suppose I should have  placed it on trunk since the bug
isn't really introduced in this branch:

https://www.fossil-scm.org/home/info/bcf6abe5b6e0cc7b

Andy

> The "fossil ui HOSTNAME:directory/of/checkout" command also uses ssh

Thanks, I wasn't even aware of this functionality.

> The following commands have been updated:

I believe  that this  list also  includes "fossil  clone" since  that is
the  most likely  place  that  people will  encounter  this.  I find  it
highly unlikely  that once someone  has successfully cloned from  an SSH
repository that the path on the remote host will change.

Thanks,

Andy

Thanks. I also  realized that while clone may be  the first interaction,
it's also  very possible  that after one  has successfully  cloned, that
this could be encountered after  adding, removing, or changing a "fossil
remote" (all intentional changes though).

Andy

> Post follow-ups if you discover otherwise.

Should Fossil not return the original error that the SSH server returns?

For example, when I login and mistype my password, I see:

$ ssh localhost
amb@localhost's password: 
Permission denied, please try again.
amb@localhost's password: 

But when I do the same with Fossil, I only see:

$ fossil clone ssh://localhost//tmp/new.fossil clone.fossil           
amb@localhost's password: 
amb@localhost's password: 

Only after I enable --sshtrace do I get to see the reason why it failed:

$ fossil clone --sshtrace ssh://localhost//tmp/new.fossil clone.fossil
RUN ssh -e none -T -- localhost fossil test-http /tmp/new.fossil
amb@localhost's password: 
Got line: [Permission denied, please try again.]
amb@localhost's password: 

Andy

> I changed that back. I don't know what this will break. Please test.

I tested a few scenarios (e.g. clone, sync, pull), including the new [to
me] "fossil ui HOSTNAME:" functionality and it seemed to work fine.

Andy

> As  soon as  I drop  the interactive  SSH connection  from the  second
> Terminal window, the command succeeds.

Are you  perhaps doing  anything with  ControlMaster and  ControlPath in
your ssh_config?  Maybe something was  misbehaving with SSH.  Given your
simple reproduction steps, I'm inclined to believe that it wasn't really
Fossil related at all. What happened when you ran something like:

ssh -e none -T hostname 'hostname'

Or any other commands while you had the first SSH into the remote?

I tried reproducing here and all I see is:

$ fossil ver
This is fossil version 2.24 [2304041e42] 2024-03-23 05:54:48 UTC

And now a remote 'fossil ver' while SSH is open in another terminal:

$ ssh -e none -T remote 'fossil ver'
This is fossil version 2.24 [d27cb05f6b] 2024-02-07 14:25:38 UTC

Seems like  it's working  fine at  least with  these versions  which are
perhaps slightly older than you have since I haven't had as much time to
work on Fossil lately.

> Please try it out and report problems.

Not necessarily a problem, but I  wonder why is it necessary to close(2)
here and redirect stderr to stdout?

https://www.fossil-scm.org/home/artifact?udc=1&ln=199&name=e6675fd982e390d4

Thanks,

Andy

> Otherwise, an  error about  "unknown command:  fossil" appears  on the
> output of the "fossil sync" command

I  don't  think  that's  necessarily  a bad  thing  as  Unix  users  are
accustomed to having  errors reported on stderr. Consider  that now they
will just get  prompted twice for the password  without realizing what's
going on. Previously they would get  an error, realize that fossil isn't
in an  appropriate PATH, fix it  by putting fossil where  it belongs [or
use ?fossil=] and then move on their merry way.

$ fossil clone ssh://localhost//tmp/fossil.fossil clone.fossil
amb@localhost's password: 
ksh: fossil: not found
server did not reply
Clone done, wire bytes sent: 311  received: 0  remote: localhost
server returned an error - clone aborted


Now, they get prompted twice for a password and nothing explains to them
why:

$ fossil clone ssh://localhost//tmp/fossil.fossil clone.fossil           
amb@localhost's password: 
amb@localhost's password: 
Round-trips: 10   Artifacts sent: 0  received: 60191
Clone done, wire bytes sent: 3308  received: 43372599  remote: localhost
Rebuilding repository meta-data...
  100.1% complete...
Extra delta compression... 23 deltas save 107,146 bytes
Vacuuming the database... 
project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333
server-id:  7698daba523927c31017a456e9421126199b5c49
admin-user: amb (password is "Rtnish7QzM")


Would it not be better to let  them know what went wrong so they realize
that Fossil is performing some additional work on their behalf?

Here's what it looks like with popen left the way it is:

$ fossil clone ssh://localhost//tmp/fossil.fossil clone.fossil
amb@localhost's password: 
ksh: fossil: not found
amb@localhost's password: 

That  doesn't look  too  scary  to me,  though  arguably  this could  be
improved to say, "fossil not found in PATH, retrying with a new PATH".

Thanks,

Andy

>  It never  occurred to me  that anyone  would still be  using password
> authentication for SSH

Hard to believe, I  know, but I know many people  who could never really
be bothered  to use SSH keys,  despite how convenient and  flexible they
are [maybe  this is  because of  the "just  works" principle  applied to
passwords].  Personally, I  prefer to  use SSH  keys where  possible and
especially with Fossil.

Andy

> A diagnostic message  (less cryptic than "ksh: fossil:  not found") is
> now printed if the ssh command is retried.

Yep, looks great, thanks:

$ fossil clone ssh://localhost//tmp/fossil.fossil clone.fossil
amb@localhost's password: 
First attempt to run fossil on localhost using SSH failed.
Retrying with the PATH= argument.
amb@localhost's password: 
Round-trips: 10   Artifacts sent: 0  received: 60191
Clone done, wire bytes sent: 3277  received: 43372599  remote: localhost

This way when they do run into this scenario, they will not be surprised
and  think that  they entered  their password  incorrectly or  something
else.


After successfully cloning I now get other errors:

$ fossil sync
Sync with ssh://localhost//tmp/fossil.fossil
amb@localhost's password: 
Round-trips: 1   Artifacts sent: 0  received: 0
Error: bad command: igot fb156a12bfa2aefbca413f9b7affa2b299d5eefb28ab0d16e92e9c97e3e8a00a

Round-trips: 1   Artifacts sent: 0  received: 0
Sync done, wire bytes sent: 4330  received: 4195  remote: localhost


But that's because Fossil is now finding my $HOME/bin which has an older
version of Fossil  in it (instead of my $HOME/altbin)  and so it chooses
the PATH=  option. To fix  it I  have to update  my URL to  use ?fossil=
after which it  works (though without the new notice  about using PATH I
see):


$ fossil sync                                                            
Sync with ssh://localhost//tmp/fossil.fossil?fossil=altbin/fossil
amb@localhost's password: 
amb@localhost's password: 
Round-trips: 1   Artifacts sent: 0  received: 0
Sync done, wire bytes sent: 4335  received: 256  remote: localhost

Should "fossil  sync" also issue  the new  message, or is  it sufficient
that cloning does it?

Thanks,

Andy

> $ fossil sync                                                            
> Sync with ssh://localhost//tmp/fossil.fossil?fossil=altbin/fossil
> amb@localhost's password: 
> amb@localhost's password: 

Oddly enough I don't seem to be able to make this happen again. Not sure
why it  happened the first  time. It now just  seems to always  send the
PATH,  so  I  see  this  after  cloning,  opening,  updating  the  query
parameter, then syncing:

$ fossil sync                                                            
Sync with ssh://localhost//tmp/fossil.fossil?fossil=altbin/fossil
amb@localhost's password: 
Round-trips: 1   Artifacts sent: 0  received: 0
Sync done, wire bytes sent: 4839  received: 3320  remote: localhost

If I see it again, I'll give better steps.

Thanks,

Andy