Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2024-06-11 Thread Christopher Schultz 

Michael,

On 6/7/24 10:18, Michael Osipov wrote:


On 2024/06/07 12:54:44 Christopher Schultz wrote:

Michael,

On 6/7/24 08:01, Michael Osipov wrote:

On 2024/06/07 08:05:34 Mark Thomas wrote:

On 06/06/2024 16:30, Christopher Schultz wrote:

All,

Resurrecting this thread from 2019.

I'd like to remove the SSI configuration from conf/web.xml and put it
into webapps/docs/ssi-howto.html.

Are there any objections?


None here.

Do we want to go further and consider removing it entirely for Tomcat 12
onwards. Maybe a question for the users list?


I need to admit that there are situations where SSI might be prefered over JSP.
Example: I needed limited flexibility for some Asciidoctor generated documents 
dependening whether it is QA or prod. I didn't want to generate multiple sets 
of documents (reduce complexity). Now some lines of SSI display a proper QA 
banner. Good enough for the job. Getting JSP or PHP output with Asciidoctor is 
almost impossible.


It's entirely possible to separate SSI into a different project. I
didn't do it because it uses helper-classes in Tomcat for certain things.

But if SSI is desirable, it can be packaged separately at the cost of
some additional support classes/methods being copied outside of Tomcat.

I don't want to support it anymore, but it should be easy *for someone
else* to extract and bundle separately :)


What is the pain having it off by default, but have the necessary classes still 
provided in the JARs? They do not require any maintenance. They just work, 
don't they?


They do "just work" but it's basically RCE as a feature which is just 
bad. The idea that Tomcat should be a Java-based replacement for httpd 
with all its features is never something I liked. CGI, SSI, 
RewriteValve, etc. are all vestiges of that idea. If you want CGI and 
SSI and rewrite, then use the right tool for that job which is a 
reverse-proxying web server. Let Tomcat deal with all the Java-related 
stuff and shed all that extra cruft.


-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2024-06-08 Thread Rémy Maucherat 
On Mon, Oct 7, 2019 at 4:46 PM Christopher Schultz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> 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.

The discussion and proposal we had was to propose removing and see the
feedback. If there was some use, keep it as it does not actually pose
a security risk unless enabled.

Given the feedback, I would now say we should keep it for Tomcat 12.

Rémy

>
> - -chris
>
>
> [1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
> at
> [2]
> https://lists.apache.org/thread.html/969a9d1b6e883a4017907c448292880624c
> c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org%3E
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bT78ACgkQHPApP6U8
> pFj9cQ/+Os1dBaXqqM3taTbqTzzCyLKCMz5q/66QreuH0ZMcqf/QjTGkxhsegelD
> 184cnAni2rWyV015yuqHvM/ZPn5BcH5pV31mEdJyGQiFIjvEfmZs37sGEoSOE584
> jutsktxcla7UEVMPfYU+YiVCapWRjWHNFusP2J/dP+UFYDg/cZJCoYDlMVjpfhmq
> UH6i/Sht3fpMfYYRHdgkP/r2wHLOD+qql/K8RNExhokwDZCiATmKA1uTuUHtQWQu
> rh71myzAqdzsEmLMRSLOnDY17XeG8Pd1W0JmcskdHNkZ/cYECLlMv5iqXLA3FbVM
> sLSd7PLJW1baFi9kqLTP4C44G8+j2tJAgjxkC+9nxFLB7Fy+abyV38Pt77zJ5NXS
> lIceS1jUIn4OBWFrMVnAii3slAl8WI0xknBBtJeObhw1uKtmRMJ2YtcefK89R/FR
> 9ZOAHghcYpkbTE8rO6z7HeyN/M+p972a7Pyr6nOH9XnanYBGuL/eg72/yAZpkofT
> k8AZe9VZ1SOK2TYBmNjHrzQDnodmvgtW3Q0RWY828CrOZ0x9vlQniKc/RWVa0HOR
> nv6l54oGGNoOezNnMKPRgOyUpzCtLCRkxMUVFkJJi2Hetf7QDo43MITgNNIz/VW8
> NEwTPtG/EUE98HQzl4MnV+I7MTBJK8kwwlIKYwtFFTnCy88QmOQ=
> =ap4d
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2024-06-07 Thread Michael Osipov 


On 2024/06/07 12:54:44 Christopher Schultz wrote:
> Michael,
> 
> On 6/7/24 08:01, Michael Osipov wrote:
> > On 2024/06/07 08:05:34 Mark Thomas wrote:
> >> On 06/06/2024 16:30, Christopher Schultz wrote:
> >>> All,
> >>>
> >>> Resurrecting this thread from 2019.
> >>>
> >>> I'd like to remove the SSI configuration from conf/web.xml and put it
> >>> into webapps/docs/ssi-howto.html.
> >>>
> >>> Are there any objections?
> >>
> >> None here.
> >>
> >> Do we want to go further and consider removing it entirely for Tomcat 12
> >> onwards. Maybe a question for the users list?
> > 
> > I need to admit that there are situations where SSI might be prefered over 
> > JSP.
> > Example: I needed limited flexibility for some Asciidoctor generated 
> > documents dependening whether it is QA or prod. I didn't want to generate 
> > multiple sets of documents (reduce complexity). Now some lines of SSI 
> > display a proper QA banner. Good enough for the job. Getting JSP or PHP 
> > output with Asciidoctor is almost impossible.
> 
> It's entirely possible to separate SSI into a different project. I 
> didn't do it because it uses helper-classes in Tomcat for certain things.
> 
> But if SSI is desirable, it can be packaged separately at the cost of 
> some additional support classes/methods being copied outside of Tomcat.
> 
> I don't want to support it anymore, but it should be easy *for someone 
> else* to extract and bundle separately :)

What is the pain having it off by default, but have the necessary classes still 
provided in the JARs? They do not require any maintenance. They just work, 
don't they?

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2024-06-07 Thread Christopher Schultz 

Michael,

On 6/7/24 08:01, Michael Osipov wrote:

On 2024/06/07 08:05:34 Mark Thomas wrote:

On 06/06/2024 16:30, Christopher Schultz wrote:

All,

Resurrecting this thread from 2019.

I'd like to remove the SSI configuration from conf/web.xml and put it
into webapps/docs/ssi-howto.html.

Are there any objections?


None here.

Do we want to go further and consider removing it entirely for Tomcat 12
onwards. Maybe a question for the users list?


I need to admit that there are situations where SSI might be prefered over JSP.
Example: I needed limited flexibility for some Asciidoctor generated documents 
dependening whether it is QA or prod. I didn't want to generate multiple sets 
of documents (reduce complexity). Now some lines of SSI display a proper QA 
banner. Good enough for the job. Getting JSP or PHP output with Asciidoctor is 
almost impossible.


It's entirely possible to separate SSI into a different project. I 
didn't do it because it uses helper-classes in Tomcat for certain things.


But if SSI is desirable, it can be packaged separately at the cost of 
some additional support classes/methods being copied outside of Tomcat.


I don't want to support it anymore, but it should be easy *for someone 
else* to extract and bundle separately :)


-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2024-06-07 Thread Michael Osipov 
On 2024/06/07 08:05:34 Mark Thomas wrote:
> On 06/06/2024 16:30, Christopher Schultz wrote:
> > All,
> > 
> > Resurrecting this thread from 2019.
> > 
> > I'd like to remove the SSI configuration from conf/web.xml and put it 
> > into webapps/docs/ssi-howto.html.
> > 
> > Are there any objections?
> 
> None here.
> 
> Do we want to go further and consider removing it entirely for Tomcat 12 
> onwards. Maybe a question for the users list?

I need to admit that there are situations where SSI might be prefered over JSP.
Example: I needed limited flexibility for some Asciidoctor generated documents 
dependening whether it is QA or prod. I didn't want to generate multiple sets 
of documents (reduce complexity). Now some lines of SSI display a proper QA 
banner. Good enough for the job. Getting JSP or PHP output with Asciidoctor is 
almost impossible.

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2024-06-07 Thread Mark Thomas 

On 06/06/2024 16:30, Christopher Schultz wrote:

All,

Resurrecting this thread from 2019.

I'd like to remove the SSI configuration from conf/web.xml and put it 
into webapps/docs/ssi-howto.html.


Are there any objections?


None here.

Do we want to go further and consider removing it entirely for Tomcat 12 
onwards. Maybe a question for the users list?


Mark



Thanks,
-chris

On 10/29/19 05:05, Konstantin Kolinko wrote:
пн, 28 окт. 2019 г. в 16:34, Christopher Schultz 
:


[...]

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.


The correct way to enable this feature is to copy those fragments into
one's own WEB-INF/web.xml.  Uncommenting them in the default web.xml
file will have [un]expected consequences.

Thus I am in favor of moving those configuration fragments to 
documentation.


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2024-06-06 Thread Christopher Schultz 

All,

Resurrecting this thread from 2019.

I'd like to remove the SSI configuration from conf/web.xml and put it 
into webapps/docs/ssi-howto.html.


Are there any objections?

Thanks,
-chris

On 10/29/19 05:05, Konstantin Kolinko wrote:

пн, 28 окт. 2019 г. в 16:34, Christopher Schultz :


[...]

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.


The correct way to enable this feature is to copy those fragments into
one's own WEB-INF/web.xml.  Uncommenting them in the default web.xml
file will have [un]expected consequences.

Thus I am in favor of moving those configuration fragments to documentation.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-29 Thread Konstantin Kolinko 
пн, 28 окт. 2019 г. в 16:34, Christopher Schultz :
>
> [...]
>
> 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.

The correct way to enable this feature is to copy those fragments into
one's own WEB-INF/web.xml.  Uncommenting them in the default web.xml
file will have [un]expected consequences.

Thus I am in favor of moving those configuration fragments to documentation.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/28/19 16:30, Mark Thomas wrote:
> On 28/10/2019 15:23, Christopher Schultz wrote:
> 
> 
> 
>>> i.  Modify files.catalina in build.xml to  the 
>>> org.apache.catalina.ssi package ii. Modify the "package" target
>>> in build.xml to  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.
>> 
>> This part was easy, but the MANIFEST.MF file claims it is
>> tomcat-trunk and not e.g. org.apache.tomcat-ssi. I'm trying to
>> figure out how we do it for Tribes, but I haven't been able to
>> find the mechanism. There are Maven-y things in the source tree
>> that contain the string org.apache.tomcat-tribes but I don't
>> think we are using them to generate our JAR files at
>> packaging-time.
>> 
>> Can anyone point me to the place(s) where Tribes gets it's 
>> META-INF/MANIFEST.MF values?
>> 
>> Also... will this take care of OSGi, or is there something else I
>> need to do in addition to addOSGi="true" when building the JAR?
> 
> It is res/bnd/catalina-tribes.jar.tmp.bnd
> 
> It sets the various bundle properties which are what OSGi looks for
> when the add-osgi task runs.

Awesome, thanks. I think this is all done, then.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl23Vn8ACgkQHPApP6U8
pFihDg/9Gq20qm3NrW0Nj9EZwmAav0m1jV+bLWtqsCOpwo095DfyUPsppMPLB9ua
cekqNo68CzQ+e+1lNOdYMjJR9GXRtttN44AkP5GaHvsv//mDxblfW8zRvDAaMdI1
znCspMAw4XSOHSezNUlMd7z0sHpWM+P3dNmZuK7U5Ug605CsSj9z56pzkSpPu1n9
NWUlaCT2Jdh+hktqwuxd+L9Ie9t0FZD8DNoBapzOZStJ4+L625yg9KOnGVq/GAQY
p+pL1HcvVQtA5lGDJQxZE3/vbUy1WNGwvXp/E6xZmHLjFSAs/3uJ+ykUH0dVmqUD
1P/p4uW04PWmgEZWmjugTxD/oKPrjsxcmHThP7Ylu7xbwhOhNPQQq+YesRdxYTWX
jUUeM5VEeGm9fZyzIkvfEGZmYXDf2CiasEFx0CAkno/APeDyL8e6PqiepWHKUeuq
EtK71dWSGWUfvnohoU+VpJKm4jldHMizavG5465gWuDxRWD59sAH7iOvzrKNtJY0
9/2Zct9+MZ9wtlrxiWQRdt9G/jHLBTkH8PcM77ctTLJfwwQcFOc21E5+d4PwnnLP
P4drouOTHUGPtOKX+iObs6fj/9FkHSCwqElH2/S7On5YU/Zp7fmFPXDwZuzyZVM6
b824rrUYsIhNzkPEngSTwB1ZK2BtCmQmcutWa18w734smsyzjTk=
=YoLX
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Mark Thomas 
On 28/10/2019 15:23, Christopher Schultz wrote:



>> i.  Modify files.catalina in build.xml to  the 
>> org.apache.catalina.ssi package ii. Modify the "package" target in
>> build.xml to  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.
> 
> This part was easy, but the MANIFEST.MF file claims it is tomcat-trunk
> and not e.g. org.apache.tomcat-ssi. I'm trying to figure out how we do
> it for Tribes, but I haven't been able to find the mechanism. There
> are Maven-y things in the source tree that contain the string
> org.apache.tomcat-tribes but I don't think we are using them to
> generate our JAR files at packaging-time.
> 
> Can anyone point me to the place(s) where Tribes gets it's
> META-INF/MANIFEST.MF values?
> 
> Also... will this take care of OSGi, or is there something else I need
> to do in addition to addOSGi="true" when building the JAR?

It is res/bnd/catalina-tribes.jar.tmp.bnd

It sets the various bundle properties which are what OSGi looks for when
the add-osgi task runs.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 10/28/19 09:34, Christopher Schultz wrote:
> 2. Separating the packaging should be easy. Note that I haven't 
> actually done this:
> 
> i.  Modify files.catalina in build.xml to  the 
> org.apache.catalina.ssi package ii. Modify the "package" target in
> build.xml to  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.

This part was easy, but the MANIFEST.MF file claims it is tomcat-trunk
and not e.g. org.apache.tomcat-ssi. I'm trying to figure out how we do
it for Tribes, but I haven't been able to find the mechanism. There
are Maven-y things in the source tree that contain the string
org.apache.tomcat-tribes but I don't think we are using them to
generate our JAR files at packaging-time.

Can anyone point me to the place(s) where Tribes gets it's
META-INF/MANIFEST.MF values?

Also... will this take care of OSGi, or is there something else I need
to do in addition to addOSGi="true" when building the JAR?

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl22+fcACgkQHPApP6U8
pFgc4RAAognVhphg2zIznYSnDQqRFu3NXgmd+EhvegyOGKgWWNS29P4Tt1A2WPNk
JGIEToGJ55r7HluwYqk4CZJ1JT8oGD5971CnZVYfwbMsvafO4c+RBirYRitnPdi7
uYpeOE4NTrek+LNK9N4d0rsMEQLCAESe5bBhfErBwV1G2zHe804sy/1RQavM3POr
RMAtzccmM1u2ixJaD6FBkiZutdrBx6nKGAh6yBVI6T7AXkPJas9xLhK8/cQfakRI
esqt2pVKpSJIPeuzQRFPn58gjmsEaztKtxoUj67Z2Z/GKtAMOOenbD6FkKlmlEtW
HMiSTGik7dIBM2lgNy8FPosz6a6Oj2ANDlVX7+3QexSciQwlRjSzYRFGP22aLvzS
k6wQTWcBiP+bdfFY12QxBnGrUMVfr3ln/wBgCTLTHdWO6iM1NElVWHzbVaSDDQ8u
u5sGwi1j5gXvsB4y+vUVw+dnbvtVwZV8peYNpRfkUGzER8VUxL8/Ln9TeUhyiIgJ
bzu6iGg/c7+gCCLLrNvfd+Z1pDeMGUmv+sW3DNlNQzrfqlf5a3qyqw/mFsQT4nnD
Wev9jZW40vGJjUHwnnPpT/VJhX1GLHeVzec9SlN91o62a/aH3XfSUQRBXbx//QN3
piVmxIysDxkfzmnkwlM93MfGkez2xDkNCF6Qmy2ZF/txFDQfS28=
=x1jq
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Christopher Schultz 
-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 
>  > 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  the 
> org.apache.catalina.ssi package ii. Modify the "package" target in
> build.xml to  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

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Rémy Maucherat 
On Mon, Oct 28, 2019 at 2:34 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> 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  the
> org.apache.catalina.ssi package
> ii. Modify the "package" target in build.xml to  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.

Rémy


>
> - -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/969a9d1b6e883a4017907c44829288062
> 4c
> 
> >
> >
> c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org%3E
> >
> -BEGIN

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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  the
org.apache.catalina.ssi package
ii. Modify the "package" target in build.xml to  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.

- -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/969a9d1b6e883a4017907c44829288062
4c
>
> 
c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org%3E
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl227lQACgkQHPApP6U8
pFjvbg//W0fD5aokUYxmy7wbTS56RdPRhLo/OmB1DrN5lbjE1rIdpiNtQRkPi9qO
C0X5QJZjYBnbNUr4YMUOVcjKjv8TBUuL6EGbVIsQupYIO0usoLthLfllH6ARXgsB
pr9Wynx7mVCi/KiR+G1mYw4bHbbVuMgZpEKCPSiurK+ZJhW7J/FfQ5U0bfZBqWG9
gT27EapqA35xXt4hHNmCb65dtWRmeXgTXEXrnzeQr3lgtXy6wT/uXjQfxP6/12Lz
vOhmi7HVzkrM6yGETsz45QvzMaY+JwS2bKfg8wxWT8B0A+3DhuevusYCHXxGunRD
LbUomZOW3+l4mVjp85KWr7U0W8LZvA/GSgGaAueqyw5xcQ2de4VdFoefmUGdKRhZ
65gWtyrynDL7wksmx8CXOaXQbAQS0GwOXpEkpPCDqslvM/y9R0qYJdVuNqMnh6vY
7DlCovaS8hcHfOQRnWCBBtBPq2UbGWGIULk1bh8VYnFRpF8PdgGIXc/GiUlVA5cY
pmPLIQ5euJJyY0nvF1IXipVdLHY0asl7tG9fvafH2Gk9TjYMUiek/1zeiD1iTcNU

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-08 Thread Rainer Jung 

Am 07.10.2019 um 20:01 schrieb Rémy Maucherat:
On Mon, Oct 7, 2019 at 4:46 PM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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


+1


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.


Yes, basically I think we should remove both CGI and SSI, *but* actually 
keep them in a separate JAR. For CGI this is harder as it is directly in 
the servlets package, so it would have to be moved to servlets.cgi for 
Tomcat 10.


+1

Regards,

Rainer

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-07 Thread Emmanuel Bourg 


>> Yes, basically I think we should remove both CGI and SSI, *but* actually
>> keep them in a separate JAR. For CGI this is harder as it is directly in
>> the servlets package, so it would have to be moved to servlets.cgi for
>> Tomcat 10.

+1, these things could be modularized and shared between Tomcat
versions. Or even with other webapp containers if they don't really need
to leverage Tomcat internal code.

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-07 Thread Rémy Maucherat 
On Mon, Oct 7, 2019 at 4:46 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> 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.
>

Yes, basically I think we should remove both CGI and SSI, *but* actually
keep them in a separate JAR. For CGI this is harder as it is directly in
the servlets package, so it would have to be moved to servlets.cgi for
Tomcat 10.

Rémy


>
> - -chris
>
>
> [1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
> at
> [2]
> https://lists.apache.org/thread.html/969a9d1b6e883a4017907c448292880624c
> c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org%3E
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bT78ACgkQHPApP6U8
> pFj9cQ/+Os1dBaXqqM3taTbqTzzCyLKCMz5q/66QreuH0ZMcqf/QjTGkxhsegelD
> 184cnAni2rWyV015yuqHvM/ZPn5BcH5pV31mEdJyGQiFIjvEfmZs37sGEoSOE584
> jutsktxcla7UEVMPfYU+YiVCapWRjWHNFusP2J/dP+UFYDg/cZJCoYDlMVjpfhmq
> UH6i/Sht3fpMfYYRHdgkP/r2wHLOD+qql/K8RNExhokwDZCiATmKA1uTuUHtQWQu
> rh71myzAqdzsEmLMRSLOnDY17XeG8Pd1W0JmcskdHNkZ/cYECLlMv5iqXLA3FbVM
> sLSd7PLJW1baFi9kqLTP4C44G8+j2tJAgjxkC+9nxFLB7Fy+abyV38Pt77zJ5NXS
> lIceS1jUIn4OBWFrMVnAii3slAl8WI0xknBBtJeObhw1uKtmRMJ2YtcefK89R/FR
> 9ZOAHghcYpkbTE8rO6z7HeyN/M+p972a7Pyr6nOH9XnanYBGuL/eg72/yAZpkofT
> k8AZe9VZ1SOK2TYBmNjHrzQDnodmvgtW3Q0RWY828CrOZ0x9vlQniKc/RWVa0HOR
> nv6l54oGGNoOezNnMKPRgOyUpzCtLCRkxMUVFkJJi2Hetf7QDo43MITgNNIz/VW8
> NEwTPtG/EUE98HQzl4MnV+I7MTBJK8kwwlIKYwtFFTnCy88QmOQ=
> =ap4d
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-07 Thread Igal Sapir 

On 10/7/2019 7:46 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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


+1

Igal



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-07 Thread Coty Sutherland 
On Mon, Oct 7, 2019 at 10:46 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> 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
>

+1


>
> 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/969a9d1b6e883a4017907c448292880624c
> c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org%3E
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bT78ACgkQHPApP6U8
> pFj9cQ/+Os1dBaXqqM3taTbqTzzCyLKCMz5q/66QreuH0ZMcqf/QjTGkxhsegelD
> 184cnAni2rWyV015yuqHvM/ZPn5BcH5pV31mEdJyGQiFIjvEfmZs37sGEoSOE584
> jutsktxcla7UEVMPfYU+YiVCapWRjWHNFusP2J/dP+UFYDg/cZJCoYDlMVjpfhmq
> UH6i/Sht3fpMfYYRHdgkP/r2wHLOD+qql/K8RNExhokwDZCiATmKA1uTuUHtQWQu
> rh71myzAqdzsEmLMRSLOnDY17XeG8Pd1W0JmcskdHNkZ/cYECLlMv5iqXLA3FbVM
> sLSd7PLJW1baFi9kqLTP4C44G8+j2tJAgjxkC+9nxFLB7Fy+abyV38Pt77zJ5NXS
> lIceS1jUIn4OBWFrMVnAii3slAl8WI0xknBBtJeObhw1uKtmRMJ2YtcefK89R/FR
> 9ZOAHghcYpkbTE8rO6z7HeyN/M+p972a7Pyr6nOH9XnanYBGuL/eg72/yAZpkofT
> k8AZe9VZ1SOK2TYBmNjHrzQDnodmvgtW3Q0RWY828CrOZ0x9vlQniKc/RWVa0HOR
> nv6l54oGGNoOezNnMKPRgOyUpzCtLCRkxMUVFkJJi2Hetf7QDo43MITgNNIz/VW8
> NEwTPtG/EUE98HQzl4MnV+I7MTBJK8kwwlIKYwtFFTnCy88QmOQ=
> =ap4d
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2019-10-07 Thread Mark Thomas 
> 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

+1

> 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.

Even if it depends on Tomcat internals, as long as those internals are
there in 10.0.x (and the same as 9.0.x) that would be an option. This is
something we could be looking at now.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org