On Oct 17, 2017, at 7:12 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:
>
> requiring JavaScript access has proven to be
> fatal for his project's usage of Fossil.
I noticed a complete lack of “me, too” in that thread. Usually when one of the
other VCSes does something different from Fossil, people are quick to jump on
it as a weakness of Fossil, but here…?
I think the no-JavaScript fight is long over, and I say that as a longtime user
of NoScript.
A great many of the old concerns about the security problems with Javascript
have gone away through various efforts, and atop that, the vast majority of web
sites and web apps now require JavaScript.
Furthermore, most of the sentiment about how web sites should run without JS
applies to content-providers, not to web apps. It is understood that web apps
work a whole lot better if you can do a lot of the processing on the client
side, rather than eat an HTTP round-trip every time any significant computation
must be done.
I do have one positive contribution to this, though it’s really too early for
me to be commenting seriously on it: Someone™ should run OWASP ZAP against
Fossil and see what it would take to placate it:
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Unlike the recent fight about compiler warnings on the SQLite mailing list, ZAP
tends to highlight actual problems. The more web apps that ship with stringent
Content-Security-Policy headers, the fewer arguments we’ll have for allowing JS
on web pages.
I suspect it would be fairly difficult to get Fossil to ship such a CSP. I
seem to recall that it uses a lot of inline CSS and JS, which are a problem
from a CSP standpoint, particularly for an app like Fossil which is all about
user-provided content.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
