-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Rémy,
On 10/28/19 09:51, Rémy Maucherat wrote: > On Mon, Oct 28, 2019 at 2:34 PM Christopher Schultz > <ch...@christopherschultz.net > <mailto:ch...@christopherschultz.net>> wrote: > > All, > > Note: this was not a vote. > > The consensus seems to be that SSIs should be moved into a > separate JAR file. > > I've done a *very* short investigation, and I have discovered the > following: > > 1. Tomcat builds fine after removing the entire > org.apache.catalina.ssi source package, so it's completely > isolated from the rest of Tomcat (which was entirely expected). > This suggests that releasing Tomcat without any of the SSI > components is practical and relatively easy. > > The stock conf/web.xml contains a sample configuration for the SSI > servlet. We will have to decide what to do with that. I can think > of at least two options: > > a. Remove it from the stock conf/web.xml entirely b. Add comments > to conf/web.xml indicating that the SSI component is a separate > download > > I think I like #2 better. > > 2. Separating the packaging should be easy. Note that I haven't > actually done this: > > i. Modify files.catalina in build.xml to <exclude> the > org.apache.catalina.ssi package ii. Modify the "package" target in > build.xml to <jarIt jarfile="catalina-ssi.jar" .../> with the > appropriate classes > > I think this is super simple to do and we should go ahead and do > this, /now/. For embedded clients who don't care about SSI, this > gives them a JAR today that they can simply remove from their > bundled clients to save a little space. > > 3. The SSI component uses a bunch of internal(ish) Tomcat/Catalina > APIs. This may complicate fully-extracting the SSI component and > making it a standalone product (e.g. cross-container): > > org.apache.catalina.connector.Connector; > org.apache.catalina.connector.Request; > org.apache.catalina.util.IOTools; > org.apache.catalina.util.Strftime; > org.apache.catalina.util.URLEncoder; org.apache.coyote.Constants; > org.apache.tomcat.util.buf.B2CConverter; > org.apache.tomcat.util.buf.UDecoder; > org.apache.tomcat.util.http.FastHttpDateFormat; > org.apache.tomcat.util.http.RequestUtil; > org.apache.tomcat.util.res.StringManager; > org.apache.tomcat.util.security.Escape; > > Some of them are simply for convenience -- e.g. UDecoder, > FastHttpDateFormat, etc. Those could easily be replaced with > alternatives or re-implementations. I haven't yet looked at how > much the org.apache.catalina.connector.Connector and > org.apache.catalina.connector.Request classes are used. It's > possible that these could be replaced with the generic versions of > themselves (e.g. HttpServletRequest and ... I'm not sure what we > get from the Connector but of course there is no direct replacement > for that in the public API). > > So I'd like to move-forward with the separation of the SSI > component into a separate JAR file and then see what can be > re-factored within SSI itself to divorce it from internal Tomcat > APIs. > > >> Personally I am in favor of a separate JAR, but maintain >> everything else unchanged. The use of utility classes reduces >> code duplication. If it becomes cross container then I think SSI >> should be moved elsewhere. Maybe something like the taglibs >> subproject. It's a rather significant effort to test and maintain >> compatibility with everything out there IMO. Thanks for the feedback. I wouldn't bother replacing the uses of utility classes unless we were expecting to spin the project off into a subproject as you say. If we did that, I would say that anyone wanting to run the SSIServlet/Filter on another container would be caveat downloader and that patches were always welcome; the subproject would only promise compatibility with Tomcat, at least at first. Who knows? Maybe there is a nascent community out there who wants to support CGI forever on all servlet containers and they'll get behind such a project. *shrug* - -chris > On 10/7/19 10:46, Christopher Schultz wrote: >> All, > >> I recently gave a presentation on locking-down Apache Tomcat[1] >> and I briefly discussed the "sharp edges" present in Tomcat. Some >> of them are unnecessarily sharp and may be actually unnecessary. >> I'm going to make a few proposals to remove functions from >> Tomcat. > >> Proposal: Remove Server-Side Includes > >> Justification: > >> The SSI module is a remote-code execution (RCE) vulnerability as >> a feature. My sense is that SSI is a little-used feature. A few >> years ago, markt[2] asked if anyone was using SSI. The only >> replies were from other Tomcat devs commenting on what to do with >> SSI if it's no longer in the main Tomcat distribution; there were >> no community members who responded saying that SSI was important >> to them. > >> If the packaging of Tomcat could be tweaked a bit to move the >> SSI components into a separate JAR file (e.g. move >> org/apache/catalina/ssi/* to catalina-ssi.jar) and if the SSI >> components don't rely on any Tomcat specific capabilities or >> internals, then the cattalina-ssi.jar file could be used between >> Tomcat versions. For example, a user of Tomcat 10 who still >> needs SSI could get the SSI module from a distribution of Tomcat >> 8.5.x or 9.x. > >> -chris > > >> [1] >> http://tomcat.apache.org/presentations.html#latest-locking-down-tomc > >> > > at >> [2] >> https://lists.apache.org/thread.html/969a9d1b6e883a4017907c4482928806 2 > >> 4c > <https://lists.apache.org/thread.html/969a9d1b6e883a4017907c4482928806 24c> > > > > c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org > <http://3Cusers.tomcat.apache.org>%3E > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > <mailto:dev-unsubscr...@tomcat.apache.org> For additional commands, > e-mail: dev-h...@tomcat.apache.org > <mailto:dev-h...@tomcat.apache.org> > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl229B8ACgkQHPApP6U8 pFjHcBAAwUSAv0RlJ8voEPcC/JpdmTHhp+WSlN1uZCiwD2TQjYtNlWJiFawpgJWm T0on7AcDQ/KGHJjckfk8pbyE938FWLfTpc/UWmsSfmfB2qQCmqc7vtYxdClWadmG jO+wNX2iH2ZW+mlme7e9zl/YM6cSlL5SxRlEaJ8p8WONoFt7Yf5oaSYHvwunEHu/ mLFK3/t9rjXfK5F09MT8+KXoCJQW9KVFo8c1J2flGEl1fSLwu63J1+ga6kToSZqV JGDoScrL2kong82ugHMdsVqUUXCDYm6b9uR6glGc2X8C9KRu7kxIe9X2lEr4th5e 9nm5IcDqFmaKvFeOOj/R4fptGFoYtztG45CXK4i/N+7sW2NJ7OCVFW6kWan8ao/j pTURcmPWiWKnujQhf0qAn9lBUm7Qh9/ghdC0H4chEpP+wPlP4LUfWb4ZtkL2/B/P EcdQnxkPI6TKO+lNB4WTue5xqjpsYNDt8XEyGoprb+Mf5qH7j/Hjpt9jSAmIqNmv XH97v8vvofGKyAooWlxe7FjnWnzbEz8q9pLzFvg+EBVQvl39kp04BB2bBcfBvPHf 4fAC5AQeMNSG9dDhvEN7xQNZqU05OhqEE8LVxFWzxEmelTkUnsW7qH2L08Ahb5wD bQAhgkTCKymN8lUlh3dNZtaA295KAuDWaIOo87Otm9GpBkNqL5A= =9e9A -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
