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://my.malicious.host/repo 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 means. I think a bigger problem that Fossil has is partially addressed here: http://www.fossil-scm.org/index.html/info/ce7baa9798de21aa 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. Thanks, Andy -- TAI64 timestamp: 40000000598f2d17 _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
