On Sun, 5 July 2011, Matt McCutchen wrote: > On Sun, 2011-06-05 at 11:03 +0200, Jakub Narebski wrote: > > In the future however it might be better solution for gitweb to implement > > (as an option) support for CSP (Content Security Policy), which IIRC did > > not exists in 2009, in addition to current $prevent_xss. > > Sure. CSP is not a substitute for designing to prevent harmful HTML > injection, but a mitigation for some of its worst effects in case some > injection points are overlooked. There's no reason not to enable it by > default with $prevent_xss, though third parties adding functionality to > gitweb would need to know to disable it or modify the policy > accordingly. I propose CSP support _in addition to_ and not replacing $prevent_xss (which would be nice to have more fine-grained control over). Well, while we can whitelist HTML fragment from README.html, or render README.md / README.rs / README.pod etc. instead of blocking it like gitweb currently does if $prevent_xss is enabled, I don't think it would be feasible to do the same for text/html 'blob_plain' pages. Serving HTML pages etc. from 'blob_plain' view with path_info links is quite useful feature; this way one can use gitweb as a cheap and easy way to deploy web pages and web apps; or just test results of development. CSP would serve this purpose well; current $prevent_xss behavior of serving as attachment (forcing download), or serving them as text/plain as e.g. GitHub does simply remove this feature. -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html