Thanks David for the quick reply. There is probably a balance to find. I agree that the tradeoffs can hurt us more than the actual small settings to apply. They are pretty well documented and clear in the following page https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
-- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Sun, Mar 13, 2022 at 9:58 AM David Blevins <[email protected]> wrote: > > On Mar 12, 2022, at 11:34 PM, Jean-Louis Monteiro < > [email protected]> wrote: > > > > xpoweredBy giving the exact version of Tomcat for instance > > The error valve attributes are set to false so it does not display > Tomcat's > > version and does not discard exceptions. > > > > Should we somehow pre-configure TomEE to be a bit more secure? > > The downside is that in development, with Arquillian or TomEE Maven > plugin > > we lose some useful information to debug and understand what's going on. > > I think you raise a key point in that last sentence. If we do things like > have TomEE eat stacktraces and fail silently by default, that doesn't just > make it harder for people to write applications on TomEE, that also makes > it harder for us to develop TomEE. > > I think that would likely translate into fewer people making it out of the > development phase, which means fewer users, fewer contributors and fewer > resources. > > We'd also have to sweep through all our test cases and examples and ensure > that things like stacktraces are enabled, which would make tests and > examples more complicated. It could also reinforce people using the dev > settings in production if they're seeing them repeated in our 180+ > examples. They'd still be in the position of having to read a doc to undo > the settings before production. > > Not totally against, it just sounds very tricky. > > It's definitely a good conversation and there are likely specific things > we can do that could be palatable but don't completely sacrifice the dev > experience. > > > > -David > >
