https://bz.apache.org/bugzilla/show_bug.cgi?id=63905
--- Comment #15 from Michael Osipov <micha...@apache.org> --- (In reply to Christopher Schultz from comment #14) > (In reply to Michael Osipov from comment #13) > > I don't see how "securing the ErrorReportValve" is related to the served > > CSS. > > It's a *thin* argument related to fingerprinting the server's version. If > you modify the CSS in Tomcat 9.0.28, a client can request a page known to > produce this output, check the CSS, and determine if the version is > before/after that patch. Well, to some degree of certainty. This is likely, but the paranoid should swap the ErrorReportValve for a custom one. > > However, I have found a few more nits I am going through locally now where > > the CSS will now cleanly apply to the ErrorReportValve as well as the > > listing of DefaultServlet. > > This should all really be replaced by external stylesheets, for a few > reasons: > > 1. They are trivially changed by administrators instead of hacking Java code > 2. They can be completely blocked, replaced, etc. by a reverse proxy if > desired > 3. They are more compatible with a desire to reduce response entity byte > count > 4. They can be used with a "safe" CSF policies[1] I agree here, but this is far more work than I do now at the moment. A lot of stuff is hardcoded in Java, burried in static fields. All of our default apps would require a rewrite -- and all of them are optional! -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
