Thus said Richard Hipp on Fri, 11 Aug 2017 11:41:09 -0400:

> I don't  feel a particular need  to rush out a  new release containing
> this fix.  But I  am open to  arguments to the  contrary, if  you feel
> differently.

I think  at a certain  point, users of any  software have to  take their
own  measures to  work  securely.  A malicious  user  could give  Fossil
instructions similar to:

fossil sync --ssh-command "ssh -malicious -options" ssh://

And if  an unsuspecting  user just blindly  acceepts that  command, what
should Fossil  do about  it? But  Fossil shouldn't make  it easy  by any

I think a bigger problem that Fossil has is partially addressed here:

which  is similar  to  the attack  vector that  you  just fixed,  though
perhaps worse because it allows remote execution of commands:

fossil clone "ssh://somehost//some/path;rm -rf /" clone.fossil

Again, the  attack surface  of this  is limited to  the access  that the
remote user has, but it's still pretty bad in my opinion.

I  don't have  a Windows  environment available,  so I  cannot test  the
changes I've made for Windows so I committed the code to a branch.

The safest way to use SSH is with ForceCommand.


TAI64 timestamp: 40000000598f2d17

fossil-dev mailing list

Reply via email to