Re: [PROPOSAL] Drop support for HTTP/2 server push

[Mark Thomas]

On 11/08/2023 07:47, Rémy Maucherat wrote:

On Thu, Aug 10, 2023 at 2:03 PM Mark Thomas  wrote:


Hi all,

HTTP/2 server push never really took off and has/is being dropped by the
major browsers. More details in this blog post:

https://developer.chrome.com/blog/removing-push/

I'd like to propose deprecating support for server push in Tomcat 10.1.x
and removing in Tomcat 11.

The current Servlet API allows us to always return null from
HttpServletRequest.newPushBuilder

Separately, I have proposed deprecating the push API in the servlet spec
for removal in a future version.

Any objections to this proposal?


Thanks for telling us about this. The usage numbers are impressively
low now. OTOH, maybe some of the most complex websites are the ones
using it. However, G says the performance benefits are not there, so I
trust them in that area.
So +1 for removing in 11.


There has been some initial push from the Jakarta Servlet project so 
this work is currently on pause until there is consensus on the way 
forward from the spec perspective.


My own preference remains removing server push support.

Mark

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

Re: [PROPOSAL] Drop support for HTTP/2 server push

[Rémy Maucherat]

On Thu, Aug 10, 2023 at 2:03 PM Mark Thomas  wrote:
>
> Hi all,
>
> HTTP/2 server push never really took off and has/is being dropped by the
> major browsers. More details in this blog post:
>
> https://developer.chrome.com/blog/removing-push/
>
> I'd like to propose deprecating support for server push in Tomcat 10.1.x
> and removing in Tomcat 11.
>
> The current Servlet API allows us to always return null from
> HttpServletRequest.newPushBuilder
>
> Separately, I have proposed deprecating the push API in the servlet spec
> for removal in a future version.
>
> Any objections to this proposal?

Thanks for telling us about this. The usage numbers are impressively
low now. OTOH, maybe some of the most complex websites are the ones
using it. However, G says the performance benefits are not there, so I
trust them in that area.
So +1 for removing in 11.

Remy

> Mark
>
> -
> 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] Drop support for HTTP/2 server push

[Han Li]

> On Aug 10, 2023, at 20:02, Mark Thomas  wrote:
> 
> Hi all,
> 
> HTTP/2 server push never really took off and has/is being dropped by the 
> major browsers. More details in this blog post:
> 
> https://developer.chrome.com/blog/removing-push/
> 
> I'd like to propose deprecating support for server push in Tomcat 10.1.x and 
> removing in Tomcat 11.
+1

Han
> 
> The current Servlet API allows us to always return null from 
> HttpServletRequest.newPushBuilder
> 
> Separately, I have proposed deprecating the push API in the servlet spec for 
> removal in a future version.
> 
> Any objections to this proposal?
> 
> Mark
> 
> -
> 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

[PROPOSAL] Drop support for HTTP/2 server push

[Mark Thomas]

Hi all,

HTTP/2 server push never really took off and has/is being dropped by the 
major browsers. More details in this blog post:


https://developer.chrome.com/blog/removing-push/

I'd like to propose deprecating support for server push in Tomcat 10.1.x 
and removing in Tomcat 11.


The current Servlet API allows us to always return null from 
HttpServletRequest.newPushBuilder


Separately, I have proposed deprecating the push API in the servlet spec 
for removal in a future version.


Any objections to this proposal?

Mark

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

Re: [PROPOSAL] Change default TLS protocol from "all" to "TLSv1.2,TLSv1.3" in Tomcat 10.1

[Igal Sapir]

On Mon, Feb 28, 2022 at 8:12 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> As the subject says.
>
> Or, perhaps, redefine "all" to be "TLSv1.2,TLSv1.3" similarly to what we
> did in the past when removing SSLv3 from the definition of "all".
>
> I think this should be done with Tomcat 10.1 (relatively new) to set a
> precedent moving forward, but not 8.5 or 9.0 to avoid disrupting
> production deployments.
>

+1

Igal



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

[PROPOSAL] Change default TLS protocol from "all" to "TLSv1.2,TLSv1.3" in Tomcat 10.1

[Christopher Schultz]

All,

As the subject says.

Or, perhaps, redefine "all" to be "TLSv1.2,TLSv1.3" similarly to what we 
did in the past when removing SSLv3 from the definition of "all".


I think this should be done with Tomcat 10.1 (relatively new) to set a 
precedent moving forward, but not 8.5 or 9.0 to avoid disrupting 
production deployments.


-chris

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

Re: ULRStreamHandlerFactory proposal

[Raymond Augé]

Lastly, I do agree that if fixed in Java that would be the best case
scenario. However, I am not hopeful.

On Thu, Feb 17, 2022 at 9:08 AM Raymond Augé 
wrote:

> Another small point is that the issue is with cleanup more than with
> registration. The Java 17 API has no way to remove factories. This tied to
> the lack of a coordination model means that you risk classloader pinning.
> Sure tomcat has a work around. But there is no portable API anywhere to do
> it. Each product has it's own design an quirks.
>
> On Thu, Feb 17, 2022 at 9:02 AM Raymond Augé 
> wrote:
>
>> I would like to clarify one small point which may have been missed in my
>> description.
>>
>> The issue is that there is not only tomcat. There are other frameworks in
>> the Java ecosystem having a desire to manage URLStreamHandlerFactories. The
>> problem is coordination between them when they are peers, or when they form
>> any type of hierarchy. The current API simply cannot cope with that. We
>> have an issue with tomcat as it is to be honest because we are downstream
>> from it, and if tomcat did it's binding we are screwed in our downstream
>> use case. The same if a framework were to do it and tomcat were downstream
>> of it (embedded).
>>
>> Anyhow, thank you for your consideration.
>>
>> Ray
>>
>>
>>
>> On Thu, Feb 17, 2022 at 6:10 AM Romain Manni-Bucau 
>> wrote:
>>
>>> Hi all
>>>
>>> It is a very valid point, since tomcat started to use this API it got
>>> worked around in all integrations (bypassed to disable war: url handling
>>> basically).
>>> I never fully got why tomcat integrated at that level since in standalone
>>> mode it owns the deployment so it does not need at all AFAIK so anything
>>> making it optional would be a +1 from me.
>>> That said I would avoid a shared lib which will create new issues and
>>> conflicts quite easily so I would probably encourage to implement the
>>> war:
>>> support different (likely testing the protocol only? should be sufficient
>>> in tomcat land).
>>>
>>>
>>> Anyway +1 to encourage Oracle to make the JVM support nicer and plural
>>> but
>>> I'm not sure it will happen tomorrow so there are still rooms to enhance
>>> tomcat "integrability" way before IMHO.
>>>
>>> Hope it makes sense.
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> >
>>>
>>>
>>> Le jeu. 17 févr. 2022 à 10:57, Rémy Maucherat  a écrit
>>> :
>>>
>>> > On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
>>> >  wrote:
>>> > >
>>> > > Hello all,
>>> > >
>>> > > There has been a long standing limitation in the JDK w.r.t. the
>>> handling
>>> > of
>>> > > URLStreamHandlerFactory. Beyond Java 17 this API becomes even more
>>> locked
>>> > > down making dynamic use cases or coordination among frameworks next
>>> to
>>> > > impossible. It appears unlikely to ever be resolved in the JDK.
>>> > >
>>> > > The OSGi community shares a desire [1] (with others in the wider Java
>>> > > community) to address this. We were thinking this might happen in a
>>> way
>>> > > that Tomcat may benefit from, since it appears to also have the same
>>> > issue
>>> > > [2].
>>> > >
>>> > > Here is the idea.
>>> > >
>>> > > We thought that a library could become the de facto implementation
>>> which,
>>> > > by acting as the primordial URLStreamHandlerFactory (which directly
>>> > > integrates with the JVM), provides the dynamism necessary for any
>>> number
>>> > of
>>> > > downstream consumers are able to orchestrate a set of protocol
>>> handlers
>>> > > without clobbering everyone else or worse failing outright in those
>>> > > scenarios where someone else beat you to the punch.
>>> > >
>>> > > How might this be accomplished? Tom Watson from IBM suggested that by
>>> > > providing a protocol of it's own which one could obtain by doing
>>> > something
>>> > > like `new URL("ushfm:").openConnection()` returning an instance
>>> which is
>>> > > castable (or used reflectively) to a management-like interface.
>>> > >
>>> > > We imagined that such a library could potentially replace the current
>>> > > implementation in tomcat, or at least help it to accomplish its
>>> goals.
>>> > This
>>> > > would enable scenarios where OSGi is embedded in a WAR (my company
>>> for
>>> > > instance), or where tomcat is embedded (and that env already has said
>>> > > library deployed) or any combination of those. Of course there is
>>> room
>>> > here
>>> > > for all fallbacks to kick in. If the "lookup" fails, then obviously
>>> there
>>> > > is no such implementation present and you keep doing what you were
>>> doing.
>>> > >
>>> > > Ideally such a library would live in an open source project where
>>> there
>>> > is
>>> > > credibility for a wide 

Re: ULRStreamHandlerFactory proposal

[Raymond Augé]

Another small point is that the issue is with cleanup more than with
registration. The Java 17 API has no way to remove factories. This tied to
the lack of a coordination model means that you risk classloader pinning.
Sure tomcat has a work around. But there is no portable API anywhere to do
it. Each product has it's own design an quirks.

On Thu, Feb 17, 2022 at 9:02 AM Raymond Augé 
wrote:

> I would like to clarify one small point which may have been missed in my
> description.
>
> The issue is that there is not only tomcat. There are other frameworks in
> the Java ecosystem having a desire to manage URLStreamHandlerFactories. The
> problem is coordination between them when they are peers, or when they form
> any type of hierarchy. The current API simply cannot cope with that. We
> have an issue with tomcat as it is to be honest because we are downstream
> from it, and if tomcat did it's binding we are screwed in our downstream
> use case. The same if a framework were to do it and tomcat were downstream
> of it (embedded).
>
> Anyhow, thank you for your consideration.
>
> Ray
>
>
>
> On Thu, Feb 17, 2022 at 6:10 AM Romain Manni-Bucau 
> wrote:
>
>> Hi all
>>
>> It is a very valid point, since tomcat started to use this API it got
>> worked around in all integrations (bypassed to disable war: url handling
>> basically).
>> I never fully got why tomcat integrated at that level since in standalone
>> mode it owns the deployment so it does not need at all AFAIK so anything
>> making it optional would be a +1 from me.
>> That said I would avoid a shared lib which will create new issues and
>> conflicts quite easily so I would probably encourage to implement the war:
>> support different (likely testing the protocol only? should be sufficient
>> in tomcat land).
>>
>>
>> Anyway +1 to encourage Oracle to make the JVM support nicer and plural but
>> I'm not sure it will happen tomorrow so there are still rooms to enhance
>> tomcat "integrability" way before IMHO.
>>
>> Hope it makes sense.
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le jeu. 17 févr. 2022 à 10:57, Rémy Maucherat  a écrit :
>>
>> > On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
>> >  wrote:
>> > >
>> > > Hello all,
>> > >
>> > > There has been a long standing limitation in the JDK w.r.t. the
>> handling
>> > of
>> > > URLStreamHandlerFactory. Beyond Java 17 this API becomes even more
>> locked
>> > > down making dynamic use cases or coordination among frameworks next to
>> > > impossible. It appears unlikely to ever be resolved in the JDK.
>> > >
>> > > The OSGi community shares a desire [1] (with others in the wider Java
>> > > community) to address this. We were thinking this might happen in a
>> way
>> > > that Tomcat may benefit from, since it appears to also have the same
>> > issue
>> > > [2].
>> > >
>> > > Here is the idea.
>> > >
>> > > We thought that a library could become the de facto implementation
>> which,
>> > > by acting as the primordial URLStreamHandlerFactory (which directly
>> > > integrates with the JVM), provides the dynamism necessary for any
>> number
>> > of
>> > > downstream consumers are able to orchestrate a set of protocol
>> handlers
>> > > without clobbering everyone else or worse failing outright in those
>> > > scenarios where someone else beat you to the punch.
>> > >
>> > > How might this be accomplished? Tom Watson from IBM suggested that by
>> > > providing a protocol of it's own which one could obtain by doing
>> > something
>> > > like `new URL("ushfm:").openConnection()` returning an instance which
>> is
>> > > castable (or used reflectively) to a management-like interface.
>> > >
>> > > We imagined that such a library could potentially replace the current
>> > > implementation in tomcat, or at least help it to accomplish its goals.
>> > This
>> > > would enable scenarios where OSGi is embedded in a WAR (my company for
>> > > instance), or where tomcat is embedded (and that env already has said
>> > > library deployed) or any combination of those. Of course there is room
>> > here
>> > > for all fallbacks to kick in. If the "lookup" fails, then obviously
>> there
>> > > is no such implementation present and you keep doing what you were
>> doing.
>> > >
>> > > Ideally such a library would live in an open source project where
>> there
>> > is
>> > > credibility for a wide audience, such as Apache.
>> > >
>> > > Thoughts?
>> >
>> > It should be fixed by the Java platform. How hard is it to add
>> > URL.setURLStreamHandlerFactory(String protocol,
>> > URLStreamHandlerFactory fac) ? I think the problem is that nobody was
>> > really asking, so Oracle did nothing. Given the amount of 

Re: ULRStreamHandlerFactory proposal

[Raymond Augé]

I would like to clarify one small point which may have been missed in my
description.

The issue is that there is not only tomcat. There are other frameworks in
the Java ecosystem having a desire to manage URLStreamHandlerFactories. The
problem is coordination between them when they are peers, or when they form
any type of hierarchy. The current API simply cannot cope with that. We
have an issue with tomcat as it is to be honest because we are downstream
from it, and if tomcat did it's binding we are screwed in our downstream
use case. The same if a framework were to do it and tomcat were downstream
of it (embedded).

Anyhow, thank you for your consideration.

Ray



On Thu, Feb 17, 2022 at 6:10 AM Romain Manni-Bucau 
wrote:

> Hi all
>
> It is a very valid point, since tomcat started to use this API it got
> worked around in all integrations (bypassed to disable war: url handling
> basically).
> I never fully got why tomcat integrated at that level since in standalone
> mode it owns the deployment so it does not need at all AFAIK so anything
> making it optional would be a +1 from me.
> That said I would avoid a shared lib which will create new issues and
> conflicts quite easily so I would probably encourage to implement the war:
> support different (likely testing the protocol only? should be sufficient
> in tomcat land).
>
>
> Anyway +1 to encourage Oracle to make the JVM support nicer and plural but
> I'm not sure it will happen tomorrow so there are still rooms to enhance
> tomcat "integrability" way before IMHO.
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 17 févr. 2022 à 10:57, Rémy Maucherat  a écrit :
>
> > On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
> >  wrote:
> > >
> > > Hello all,
> > >
> > > There has been a long standing limitation in the JDK w.r.t. the
> handling
> > of
> > > URLStreamHandlerFactory. Beyond Java 17 this API becomes even more
> locked
> > > down making dynamic use cases or coordination among frameworks next to
> > > impossible. It appears unlikely to ever be resolved in the JDK.
> > >
> > > The OSGi community shares a desire [1] (with others in the wider Java
> > > community) to address this. We were thinking this might happen in a way
> > > that Tomcat may benefit from, since it appears to also have the same
> > issue
> > > [2].
> > >
> > > Here is the idea.
> > >
> > > We thought that a library could become the de facto implementation
> which,
> > > by acting as the primordial URLStreamHandlerFactory (which directly
> > > integrates with the JVM), provides the dynamism necessary for any
> number
> > of
> > > downstream consumers are able to orchestrate a set of protocol handlers
> > > without clobbering everyone else or worse failing outright in those
> > > scenarios where someone else beat you to the punch.
> > >
> > > How might this be accomplished? Tom Watson from IBM suggested that by
> > > providing a protocol of it's own which one could obtain by doing
> > something
> > > like `new URL("ushfm:").openConnection()` returning an instance which
> is
> > > castable (or used reflectively) to a management-like interface.
> > >
> > > We imagined that such a library could potentially replace the current
> > > implementation in tomcat, or at least help it to accomplish its goals.
> > This
> > > would enable scenarios where OSGi is embedded in a WAR (my company for
> > > instance), or where tomcat is embedded (and that env already has said
> > > library deployed) or any combination of those. Of course there is room
> > here
> > > for all fallbacks to kick in. If the "lookup" fails, then obviously
> there
> > > is no such implementation present and you keep doing what you were
> doing.
> > >
> > > Ideally such a library would live in an open source project where there
> > is
> > > credibility for a wide audience, such as Apache.
> > >
> > > Thoughts?
> >
> > It should be fixed by the Java platform. How hard is it to add
> > URL.setURLStreamHandlerFactory(String protocol,
> > URLStreamHandlerFactory fac) ? I think the problem is that nobody was
> > really asking, so Oracle did nothing. Given the amount of improvements
> > and additions to the platform since the stagnation of Java 8, why
> > would they still refuse it ? They've even been rewriting NIO !
> >
> > Also, and more importantly, you can very very easily use
> > TomcatURLStreamHandlerFactory.addUserFactory (doing it through
> > reflection if needed) as all currently supported Tomcat versions have
> > this API. You're already integrating Tomcat using some integration
> > code, so your integration code should be using this.
> >
> > Rémy
> >
> > > Ray
> > >
> > > [1] 

Re: ULRStreamHandlerFactory proposal

[Romain Manni-Bucau]

Hi all

It is a very valid point, since tomcat started to use this API it got
worked around in all integrations (bypassed to disable war: url handling
basically).
I never fully got why tomcat integrated at that level since in standalone
mode it owns the deployment so it does not need at all AFAIK so anything
making it optional would be a +1 from me.
That said I would avoid a shared lib which will create new issues and
conflicts quite easily so I would probably encourage to implement the war:
support different (likely testing the protocol only? should be sufficient
in tomcat land).


Anyway +1 to encourage Oracle to make the JVM support nicer and plural but
I'm not sure it will happen tomorrow so there are still rooms to enhance
tomcat "integrability" way before IMHO.

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 17 févr. 2022 à 10:57, Rémy Maucherat  a écrit :

> On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
>  wrote:
> >
> > Hello all,
> >
> > There has been a long standing limitation in the JDK w.r.t. the handling
> of
> > URLStreamHandlerFactory. Beyond Java 17 this API becomes even more locked
> > down making dynamic use cases or coordination among frameworks next to
> > impossible. It appears unlikely to ever be resolved in the JDK.
> >
> > The OSGi community shares a desire [1] (with others in the wider Java
> > community) to address this. We were thinking this might happen in a way
> > that Tomcat may benefit from, since it appears to also have the same
> issue
> > [2].
> >
> > Here is the idea.
> >
> > We thought that a library could become the de facto implementation which,
> > by acting as the primordial URLStreamHandlerFactory (which directly
> > integrates with the JVM), provides the dynamism necessary for any number
> of
> > downstream consumers are able to orchestrate a set of protocol handlers
> > without clobbering everyone else or worse failing outright in those
> > scenarios where someone else beat you to the punch.
> >
> > How might this be accomplished? Tom Watson from IBM suggested that by
> > providing a protocol of it's own which one could obtain by doing
> something
> > like `new URL("ushfm:").openConnection()` returning an instance which is
> > castable (or used reflectively) to a management-like interface.
> >
> > We imagined that such a library could potentially replace the current
> > implementation in tomcat, or at least help it to accomplish its goals.
> This
> > would enable scenarios where OSGi is embedded in a WAR (my company for
> > instance), or where tomcat is embedded (and that env already has said
> > library deployed) or any combination of those. Of course there is room
> here
> > for all fallbacks to kick in. If the "lookup" fails, then obviously there
> > is no such implementation present and you keep doing what you were doing.
> >
> > Ideally such a library would live in an open source project where there
> is
> > credibility for a wide audience, such as Apache.
> >
> > Thoughts?
>
> It should be fixed by the Java platform. How hard is it to add
> URL.setURLStreamHandlerFactory(String protocol,
> URLStreamHandlerFactory fac) ? I think the problem is that nobody was
> really asking, so Oracle did nothing. Given the amount of improvements
> and additions to the platform since the stagnation of Java 8, why
> would they still refuse it ? They've even been rewriting NIO !
>
> Also, and more importantly, you can very very easily use
> TomcatURLStreamHandlerFactory.addUserFactory (doing it through
> reflection if needed) as all currently supported Tomcat versions have
> this API. You're already integrating Tomcat using some integration
> code, so your integration code should be using this.
>
> Rémy
>
> > Ray
> >
> > [1] https://github.com/osgi/osgi/issues/226
> > [2]
> >
> https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/webresources/TomcatURLStreamHandlerFactory.java
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: ULRStreamHandlerFactory proposal

[Rémy Maucherat]

On Thu, Feb 17, 2022 at 12:11 AM Raymond Augé
 wrote:
>
> Hello all,
>
> There has been a long standing limitation in the JDK w.r.t. the handling of
> URLStreamHandlerFactory. Beyond Java 17 this API becomes even more locked
> down making dynamic use cases or coordination among frameworks next to
> impossible. It appears unlikely to ever be resolved in the JDK.
>
> The OSGi community shares a desire [1] (with others in the wider Java
> community) to address this. We were thinking this might happen in a way
> that Tomcat may benefit from, since it appears to also have the same issue
> [2].
>
> Here is the idea.
>
> We thought that a library could become the de facto implementation which,
> by acting as the primordial URLStreamHandlerFactory (which directly
> integrates with the JVM), provides the dynamism necessary for any number of
> downstream consumers are able to orchestrate a set of protocol handlers
> without clobbering everyone else or worse failing outright in those
> scenarios where someone else beat you to the punch.
>
> How might this be accomplished? Tom Watson from IBM suggested that by
> providing a protocol of it's own which one could obtain by doing something
> like `new URL("ushfm:").openConnection()` returning an instance which is
> castable (or used reflectively) to a management-like interface.
>
> We imagined that such a library could potentially replace the current
> implementation in tomcat, or at least help it to accomplish its goals. This
> would enable scenarios where OSGi is embedded in a WAR (my company for
> instance), or where tomcat is embedded (and that env already has said
> library deployed) or any combination of those. Of course there is room here
> for all fallbacks to kick in. If the "lookup" fails, then obviously there
> is no such implementation present and you keep doing what you were doing.
>
> Ideally such a library would live in an open source project where there is
> credibility for a wide audience, such as Apache.
>
> Thoughts?

It should be fixed by the Java platform. How hard is it to add
URL.setURLStreamHandlerFactory(String protocol,
URLStreamHandlerFactory fac) ? I think the problem is that nobody was
really asking, so Oracle did nothing. Given the amount of improvements
and additions to the platform since the stagnation of Java 8, why
would they still refuse it ? They've even been rewriting NIO !

Also, and more importantly, you can very very easily use
TomcatURLStreamHandlerFactory.addUserFactory (doing it through
reflection if needed) as all currently supported Tomcat versions have
this API. You're already integrating Tomcat using some integration
code, so your integration code should be using this.

Rémy

> Ray
>
> [1] https://github.com/osgi/osgi/issues/226
> [2]
> https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/webresources/TomcatURLStreamHandlerFactory.java

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

ULRStreamHandlerFactory proposal

[Raymond Augé]

Hello all,

There has been a long standing limitation in the JDK w.r.t. the handling of
URLStreamHandlerFactory. Beyond Java 17 this API becomes even more locked
down making dynamic use cases or coordination among frameworks next to
impossible. It appears unlikely to ever be resolved in the JDK.

The OSGi community shares a desire [1] (with others in the wider Java
community) to address this. We were thinking this might happen in a way
that Tomcat may benefit from, since it appears to also have the same issue
[2].

Here is the idea.

We thought that a library could become the de facto implementation which,
by acting as the primordial URLStreamHandlerFactory (which directly
integrates with the JVM), provides the dynamism necessary for any number of
downstream consumers are able to orchestrate a set of protocol handlers
without clobbering everyone else or worse failing outright in those
scenarios where someone else beat you to the punch.

How might this be accomplished? Tom Watson from IBM suggested that by
providing a protocol of it's own which one could obtain by doing something
like `new URL("ushfm:").openConnection()` returning an instance which is
castable (or used reflectively) to a management-like interface.

We imagined that such a library could potentially replace the current
implementation in tomcat, or at least help it to accomplish its goals. This
would enable scenarios where OSGi is embedded in a WAR (my company for
instance), or where tomcat is embedded (and that env already has said
library deployed) or any combination of those. Of course there is room here
for all fallbacks to kick in. If the "lookup" fails, then obviously there
is no such implementation present and you keep doing what you were doing.

Ideally such a library would live in an open source project where there is
credibility for a wide audience, such as Apache.

Thoughts?

Ray

[1] https://github.com/osgi/osgi/issues/226
[2]
https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/webresources/TomcatURLStreamHandlerFactory.java

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Christopher Schultz]

Mark,

On 4/26/21 12:17, Mark Thomas wrote:
In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10 
repo I found the following:



JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
framework for J2EE v1.4, based on the href="https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification 
Request 196 to enhance container-managed security and promote 
'pluggable' authentication mechanisms whose implementations would be

container-independent.


JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.

Searching through the mailing lists I found the following references to 
usage of the JAASRealm (going back ~5 years).


[1] Tomcat 7 user using JAAS based auth to an LDAP server
[2] Tomcat 9 user using SPNEGO with the JAAS realm
[3] Tomcat 8.5 user using SPNEGO with the JAAS realm
[4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
[5] User wanting access to HttpServletRequest during auth

Most, if not all, of those have better solutions available than the JAAS 
Realm. And those wanting some form of custom auth do have the "proper" 
Jakarta Security API to work with.


Therefore, I'm not currently seeing a good reason to keep the JAASRealm. 
Any objections to immediate deprecation with removal planned for 10.1.x?


Only if someone gives a presentation at this year's ApacheCon @Home 
about JASPIC and its use by mere mortals. I'd love to see "how to use 
JASPIC to authenticate against my JDBC credential store" (aka 
"re-creating DataSourceRealm using JASPIC").


-chris

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

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Romain Manni-Bucau]

Thinking out loud: can't it become a jaspic jaas impl delivered on central
(this point is crucial), can be tomcat-jaas or so but not bundled by
default in the distribution?
Jaspic enables to do from the app so it becomes an option it seems which
enables the use case so limit a lot the required "glue" to compensate a
drop or is it still "too much" to maintain in your opinion?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 26 avr. 2021 à 21:46, Jean-Louis MONTEIRO  a
écrit :

> Le lun. 26 avr. 2021 à 20:48, Mark Thomas  a écrit :
>
> > On 26/04/2021 18:49, Jean-Louis MONTEIRO wrote:
> > > JAAS, JASPIC and Jakarta Security are all different.
> >
> > My mistake. I knew JASPIC had a slightly bigger rename than most specs
> > and incorrectly thought it became Jakarta Security. It actually became
> > Jakarta Authentication. All previous references from me in this thread
> > to "Jakarta Security" should be read as "Jakarta Authentication".
> >
>
> No problem.
>
>
> >
> > > Tomcat does not implement Jakarta Security so removing JAAS creates a
> gap
> > > in my opinion.
> > >
> > > I'd second Romain, JASPIC requires a SAM to be implemented by the
> > > application.
> > >
> > > Long story short, I'd probably deprecate for 10.x and target a removal
> > for
> > > 11.x
> >
> > In the normal course of things 10.1 would have been 11.0 but we are
> > taking the opportunity align Jakarta EE major version and Tomcat major
> > version as well as have a (much) shorter support lifespan for 10.0
> > (Jakarta EE 9) as that is seen as a transitional release.
> >
> > Tomcat 10.1 will implement the usual subset of specs from Jakarta EE 10.
> >
>
> Sorry I missed that information.
> So it appeared to be a bit too aggressive to deprecate and remove.
>
>
> >
> > Mark
> >
> >
> > > Le lun. 26 avr. 2021 à 18:17, Mark Thomas  a écrit :
> > >
> > >> In reviewing references to Java EE (and J2EE) remaining in the Tomcat
> 10
> > >> repo I found the following:
> > >>
> > >> 
> > >> JAASRealm is prototype for Tomcat of the JAAS-based J2EE
> authentication
> > >> framework for J2EE v1.4, based on the  > >> href="https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification
> > >> Request 196 to enhance container-managed security and promote
> > >> 'pluggable' authentication mechanisms whose implementations would be
> > >> container-independent.
> > >> 
> > >>
> > >> JSR became JASPIC (now Jakarta Security) and Tomcat has an
> > implementation.
> > >>
> > >> Searching through the mailing lists I found the following references
> to
> > >> usage of the JAASRealm (going back ~5 years).
> > >>
> > >> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> > >> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> > >> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> > >> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> > >> [5] User wanting access to HttpServletRequest during auth
> > >>
> > >> Most, if not all, of those have better solutions available than the
> JAAS
> > >> Realm. And those wanting some form of custom auth do have the "proper"
> > >> Jakarta Security API to work with.
> > >>
> > >> Therefore, I'm not currently seeing a good reason to keep the
> JAASRealm.
> > >> Any objections to immediate deprecation with removal planned for
> 10.1.x?
> > >>
> > >> Mark
> > >>
> > >>
> > >> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> > >> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> > >> [3] http://markmail.org/message/wki275i5yhlg3yyo
> > >> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> > >> [5] http://markmail.org/message/fm4ggo3ge4r47gar
> > >>
> > >> -
> > >> 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
> >
> >
>
> --
> Jean-Louis
>

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Jean-Louis MONTEIRO]

Le lun. 26 avr. 2021 à 20:48, Mark Thomas  a écrit :

> On 26/04/2021 18:49, Jean-Louis MONTEIRO wrote:
> > JAAS, JASPIC and Jakarta Security are all different.
>
> My mistake. I knew JASPIC had a slightly bigger rename than most specs
> and incorrectly thought it became Jakarta Security. It actually became
> Jakarta Authentication. All previous references from me in this thread
> to "Jakarta Security" should be read as "Jakarta Authentication".
>

No problem.


>
> > Tomcat does not implement Jakarta Security so removing JAAS creates a gap
> > in my opinion.
> >
> > I'd second Romain, JASPIC requires a SAM to be implemented by the
> > application.
> >
> > Long story short, I'd probably deprecate for 10.x and target a removal
> for
> > 11.x
>
> In the normal course of things 10.1 would have been 11.0 but we are
> taking the opportunity align Jakarta EE major version and Tomcat major
> version as well as have a (much) shorter support lifespan for 10.0
> (Jakarta EE 9) as that is seen as a transitional release.
>
> Tomcat 10.1 will implement the usual subset of specs from Jakarta EE 10.
>

Sorry I missed that information.
So it appeared to be a bit too aggressive to deprecate and remove.


>
> Mark
>
>
> > Le lun. 26 avr. 2021 à 18:17, Mark Thomas  a écrit :
> >
> >> In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> >> repo I found the following:
> >>
> >> 
> >> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> >> framework for J2EE v1.4, based on the  >> href="https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification
> >> Request 196 to enhance container-managed security and promote
> >> 'pluggable' authentication mechanisms whose implementations would be
> >> container-independent.
> >> 
> >>
> >> JSR became JASPIC (now Jakarta Security) and Tomcat has an
> implementation.
> >>
> >> Searching through the mailing lists I found the following references to
> >> usage of the JAASRealm (going back ~5 years).
> >>
> >> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> >> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> >> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> >> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> >> [5] User wanting access to HttpServletRequest during auth
> >>
> >> Most, if not all, of those have better solutions available than the JAAS
> >> Realm. And those wanting some form of custom auth do have the "proper"
> >> Jakarta Security API to work with.
> >>
> >> Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> >> Any objections to immediate deprecation with removal planned for 10.1.x?
> >>
> >> Mark
> >>
> >>
> >> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> >> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> >> [3] http://markmail.org/message/wki275i5yhlg3yyo
> >> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> >> [5] http://markmail.org/message/fm4ggo3ge4r47gar
> >>
> >> -
> >> 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
>
>

-- 
Jean-Louis

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Mark Thomas]

On 26/04/2021 18:49, Jean-Louis MONTEIRO wrote:

JAAS, JASPIC and Jakarta Security are all different.


My mistake. I knew JASPIC had a slightly bigger rename than most specs 
and incorrectly thought it became Jakarta Security. It actually became 
Jakarta Authentication. All previous references from me in this thread 
to "Jakarta Security" should be read as "Jakarta Authentication".



Tomcat does not implement Jakarta Security so removing JAAS creates a gap
in my opinion.

I'd second Romain, JASPIC requires a SAM to be implemented by the
application.

Long story short, I'd probably deprecate for 10.x and target a removal for
11.x


In the normal course of things 10.1 would have been 11.0 but we are 
taking the opportunity align Jakarta EE major version and Tomcat major 
version as well as have a (much) shorter support lifespan for 10.0 
(Jakarta EE 9) as that is seen as a transitional release.


Tomcat 10.1 will implement the usual subset of specs from Jakarta EE 10.

Mark



Le lun. 26 avr. 2021 à 18:17, Mark Thomas  a écrit :


In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
repo I found the following:


JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
framework for J2EE v1.4, based on the https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification
Request 196 to enhance container-managed security and promote
'pluggable' authentication mechanisms whose implementations would be
container-independent.


JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.

Searching through the mailing lists I found the following references to
usage of the JAASRealm (going back ~5 years).

[1] Tomcat 7 user using JAAS based auth to an LDAP server
[2] Tomcat 9 user using SPNEGO with the JAAS realm
[3] Tomcat 8.5 user using SPNEGO with the JAAS realm
[4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
[5] User wanting access to HttpServletRequest during auth

Most, if not all, of those have better solutions available than the JAAS
Realm. And those wanting some form of custom auth do have the "proper"
Jakarta Security API to work with.

Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
Any objections to immediate deprecation with removal planned for 10.1.x?

Mark


[1] http://markmail.org/message/ndvr5ilxovoo4ins
[2] http://markmail.org/message/5ocdnmqvvlvjsxas
[3] http://markmail.org/message/wki275i5yhlg3yyo
[4] http://markmail.org/message/av2sv6g4kgm6ouu4
[5] http://markmail.org/message/fm4ggo3ge4r47gar

-
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] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Jean-Louis MONTEIRO]

JAAS, JASPIC and Jakarta Security are all different.
Tomcat does not implement Jakarta Security so removing JAAS creates a gap
in my opinion.

I'd second Romain, JASPIC requires a SAM to be implemented by the
application.

Long story short, I'd probably deprecate for 10.x and target a removal for
11.x

Le lun. 26 avr. 2021 à 18:17, Mark Thomas  a écrit :

> In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> repo I found the following:
>
> 
> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> framework for J2EE v1.4, based on the  href="https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification
> Request 196 to enhance container-managed security and promote
> 'pluggable' authentication mechanisms whose implementations would be
> container-independent.
> 
>
> JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.
>
> Searching through the mailing lists I found the following references to
> usage of the JAASRealm (going back ~5 years).
>
> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> [5] User wanting access to HttpServletRequest during auth
>
> Most, if not all, of those have better solutions available than the JAAS
> Realm. And those wanting some form of custom auth do have the "proper"
> Jakarta Security API to work with.
>
> Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> Any objections to immediate deprecation with removal planned for 10.1.x?
>
> Mark
>
>
> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> [3] http://markmail.org/message/wki275i5yhlg3yyo
> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> [5] http://markmail.org/message/fm4ggo3ge4r47gar
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Romain Manni-Bucau]

Le lun. 26 avr. 2021 à 18:57, Mark Thomas  a écrit :

> On 26/04/2021 17:38, Romain Manni-Bucau wrote:
> > JAASRealm is quite commonly used whereas JASPIC is almost never used
>
> References?
>

Sadly not public but all project not using a custom valve/auth where using
jaas and some good part of it (Id say 35%) sharing a login module.



> In my trawl of the Tomcat archives those using the JAAS realm appeared
> to have better solutions available whereas those using JASPIC were doing
> so for the "right" reasons.
>
> If there is evidence that the JAAS realm is meeting a user need I'd like
> to see it (and understand why JAAS is a better solution than the
> alternatives).
>

Mainly cause it has impl and shareable modules between apps (karaf, tomcat,
standalone) whereas jaspic is not.

At least being able to enable jaas is important I'd say cause it reduces
cost compare to jaspic dev which must be redone for other env (not spread
enough).



> Mark
>
>
> > (and
> > not even speaking of Jakarta Security which has no link with two previous
> > ones).
> > Main difference is the fact JAAS is in the JVM (with some impl like OS
> one
> > which is not always trivial to do portably) whereas two others are not so
> > it means you easily find a JAAS login module implementation and you don't
> > find integrations for others so think it makes sense to keep JAAS
> > integration more than others in default delivery.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le lun. 26 avr. 2021 à 18:31, Filip Hanik  a écrit :
> >
> >> On Mon, Apr 26, 2021 at 09:17 Mark Thomas  wrote:
> >>
> >>> In reviewing references to Java EE (and J2EE) remaining in the Tomcat
> 10
> >>> repo I found the following:
> >>>
> >>> 
> >>> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> >>> framework for J2EE v1.4, based on the  >>> href="https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification
> >>> Request 196 to enhance container-managed security and promote
> >>> 'pluggable' authentication mechanisms whose implementations would be
> >>> container-independent.
> >>> 
> >>>
> >>> JSR became JASPIC (now Jakarta Security) and Tomcat has an
> >> implementation.
> >>>
> >>> Searching through the mailing lists I found the following references to
> >>> usage of the JAASRealm (going back ~5 years).
> >>>
> >>> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> >>> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> >>> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> >>> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> >>> [5] User wanting access to HttpServletRequest during auth
> >>>
> >>> Most, if not all, of those have better solutions available than the
> JAAS
> >>> Realm. And those wanting some form of custom auth do have the "proper"
> >>> Jakarta Security API to work with.
> >>>
> >>> Therefore, I'm not currently seeing a good reason to keep the
> JAASRealm.
> >>> Any objections to immediate deprecation with removal planned for
> 10.1.x?
> >>
> >>
> >> No objections,
> >> go for it
> >>
> >>
> >>>
> >>> Mark
> >>>
> >>>
> >>> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> >>> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> >>> [3] http://markmail.org/message/wki275i5yhlg3yyo
> >>> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> >>> [5] http://markmail.org/message/fm4ggo3ge4r47gar
> >>>
> >>> -
> >>> 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] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Mark Thomas]

On 26/04/2021 17:38, Romain Manni-Bucau wrote:

JAASRealm is quite commonly used whereas JASPIC is almost never used


References?

In my trawl of the Tomcat archives those using the JAAS realm appeared 
to have better solutions available whereas those using JASPIC were doing 
so for the "right" reasons.


If there is evidence that the JAAS realm is meeting a user need I'd like 
to see it (and understand why JAAS is a better solution than the 
alternatives).


Mark



(and
not even speaking of Jakarta Security which has no link with two previous
ones).
Main difference is the fact JAAS is in the JVM (with some impl like OS one
which is not always trivial to do portably) whereas two others are not so
it means you easily find a JAAS login module implementation and you don't
find integrations for others so think it makes sense to keep JAAS
integration more than others in default delivery.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 26 avr. 2021 à 18:31, Filip Hanik  a écrit :


On Mon, Apr 26, 2021 at 09:17 Mark Thomas  wrote:


In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
repo I found the following:


JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
framework for J2EE v1.4, based on the https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification
Request 196 to enhance container-managed security and promote
'pluggable' authentication mechanisms whose implementations would be
container-independent.


JSR became JASPIC (now Jakarta Security) and Tomcat has an

implementation.


Searching through the mailing lists I found the following references to
usage of the JAASRealm (going back ~5 years).

[1] Tomcat 7 user using JAAS based auth to an LDAP server
[2] Tomcat 9 user using SPNEGO with the JAAS realm
[3] Tomcat 8.5 user using SPNEGO with the JAAS realm
[4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
[5] User wanting access to HttpServletRequest during auth

Most, if not all, of those have better solutions available than the JAAS
Realm. And those wanting some form of custom auth do have the "proper"
Jakarta Security API to work with.

Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
Any objections to immediate deprecation with removal planned for 10.1.x?



No objections,
go for it




Mark


[1] http://markmail.org/message/ndvr5ilxovoo4ins
[2] http://markmail.org/message/5ocdnmqvvlvjsxas
[3] http://markmail.org/message/wki275i5yhlg3yyo
[4] http://markmail.org/message/av2sv6g4kgm6ouu4
[5] http://markmail.org/message/fm4ggo3ge4r47gar

-
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] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Romain Manni-Bucau]

JAASRealm is quite commonly used whereas JASPIC is almost never used (and
not even speaking of Jakarta Security which has no link with two previous
ones).
Main difference is the fact JAAS is in the JVM (with some impl like OS one
which is not always trivial to do portably) whereas two others are not so
it means you easily find a JAAS login module implementation and you don't
find integrations for others so think it makes sense to keep JAAS
integration more than others in default delivery.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 26 avr. 2021 à 18:31, Filip Hanik  a écrit :

> On Mon, Apr 26, 2021 at 09:17 Mark Thomas  wrote:
>
> > In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> > repo I found the following:
> >
> > 
> > JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> > framework for J2EE v1.4, based on the  > href="https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification
> > Request 196 to enhance container-managed security and promote
> > 'pluggable' authentication mechanisms whose implementations would be
> > container-independent.
> > 
> >
> > JSR became JASPIC (now Jakarta Security) and Tomcat has an
> implementation.
> >
> > Searching through the mailing lists I found the following references to
> > usage of the JAASRealm (going back ~5 years).
> >
> > [1] Tomcat 7 user using JAAS based auth to an LDAP server
> > [2] Tomcat 9 user using SPNEGO with the JAAS realm
> > [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> > [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> > [5] User wanting access to HttpServletRequest during auth
> >
> > Most, if not all, of those have better solutions available than the JAAS
> > Realm. And those wanting some form of custom auth do have the "proper"
> > Jakarta Security API to work with.
> >
> > Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> > Any objections to immediate deprecation with removal planned for 10.1.x?
>
>
> No objections,
> go for it
>
>
> >
> > Mark
> >
> >
> > [1] http://markmail.org/message/ndvr5ilxovoo4ins
> > [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> > [3] http://markmail.org/message/wki275i5yhlg3yyo
> > [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> > [5] http://markmail.org/message/fm4ggo3ge4r47gar
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Filip Hanik]

On Mon, Apr 26, 2021 at 09:17 Mark Thomas  wrote:

> In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> repo I found the following:
>
> 
> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> framework for J2EE v1.4, based on the  href="https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification
> Request 196 to enhance container-managed security and promote
> 'pluggable' authentication mechanisms whose implementations would be
> container-independent.
> 
>
> JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.
>
> Searching through the mailing lists I found the following references to
> usage of the JAASRealm (going back ~5 years).
>
> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> [5] User wanting access to HttpServletRequest during auth
>
> Most, if not all, of those have better solutions available than the JAAS
> Realm. And those wanting some form of custom auth do have the "proper"
> Jakarta Security API to work with.
>
> Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> Any objections to immediate deprecation with removal planned for 10.1.x?


No objections,
go for it


>
> Mark
>
>
> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> [3] http://markmail.org/message/wki275i5yhlg3yyo
> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> [5] http://markmail.org/message/fm4ggo3ge4r47gar
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Mark Thomas]

In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10 
repo I found the following:



JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
framework for J2EE v1.4, based on the href="https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification 
Request 196 to enhance container-managed security and promote 
'pluggable' authentication mechanisms whose implementations would be

container-independent.


JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.

Searching through the mailing lists I found the following references to 
usage of the JAASRealm (going back ~5 years).


[1] Tomcat 7 user using JAAS based auth to an LDAP server
[2] Tomcat 9 user using SPNEGO with the JAAS realm
[3] Tomcat 8.5 user using SPNEGO with the JAAS realm
[4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
[5] User wanting access to HttpServletRequest during auth

Most, if not all, of those have better solutions available than the JAAS 
Realm. And those wanting some form of custom auth do have the "proper" 
Jakarta Security API to work with.


Therefore, I'm not currently seeing a good reason to keep the JAASRealm. 
Any objections to immediate deprecation with removal planned for 10.1.x?


Mark


[1] http://markmail.org/message/ndvr5ilxovoo4ins
[2] http://markmail.org/message/5ocdnmqvvlvjsxas
[3] http://markmail.org/message/wki275i5yhlg3yyo
[4] http://markmail.org/message/av2sv6g4kgm6ouu4
[5] http://markmail.org/message/fm4ggo3ge4r47gar

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

[PROPOSAL] Change the way we present sslProtocol and sslEnabledProtocols config attributes

[Christopher Schultz]

All,

The sslProtocol and sslEnabledProtocols configuration attributes on 
 are potentially confusing to people, and there really isn't 
any reason for it.


There is really never any reason to change sslProtocol from the default 
which is "TLS" because:


1. "TLS" actually enables SSLv3 when SSLv3 is available (which is rare 
these days)

2. "TLS" covers all current and likely future versions of the protocol
3. sslEnabledProtocols exists to tweak exactly which of many 
protocol-versions are actually being used


The only reason we have sslProtocol vs sslEnabledProtocols is because of 
the Java API details; there is no need to present this complexity to users.


Initially, this was going to be a proposal to simply *remove* 
sslProtocol altogether and fix its value at "TLS" forever, and then 
treat both sslProtocol and sslEnabledProtocols as aliases for each 
other. Just choose the longer of the two non-default values assuming 
that "TLSv1.2" would be longer than "TLS", and so we would enable only 
TLSv1.2 if it were specified in sslProtocol and not sslEnabledProtocols.


But my guess is that there are some weird circumstances where someone 
might actually want to change that value.


So my proposal instead of to change the documentation for sslProtocol to 
simple say:


"This should always be left at the default value of 'TLS'."

Then, the documentation for sslEnabledProtocols can be changed to "list 
of protocol versions to enable e.g. SSLv3, TLSv1.2, etc.".


-chris

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

Re: [PROPOSAL] Explicitly-set the request character encoding when it has been committed

[Mark Thomas]

On 05/04/2021 13:19, Christopher Schultz wrote:



I'm happy with incremental changes. Making the first change will be an 
improvement for sure.


On the other hand, if code calls request.setCharacterEncoding(non-null) 
then it will overwrite whatever the request had previously sent 
(including null). So in that case, request.getCharacterEncoding isn't 
always returning "what the client sent".


Another place where there is scope to add further clarity to the spec.

Mark

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

Re: [PROPOSAL] Explicitly-set the request character encoding when it has been committed

[Christopher Schultz]

Mark,

On 4/1/21 16:00, Mark Thomas wrote:

On 01/04/2021 17:08, Christopher Schultz wrote:



The javadoc says that it must be called before reading any request 
parameters OR calling getReader() but there is only a check for the 
reader.


Maybe we should change the check to:

 if (usingReader || parametersParsed) {
 return;
 }


+1


And also, change Request.parseParameters to add:

 // getCharacterEncoding() may have been overridden to 
search for

 // hidden form field containing request encoding
 Charset charset = getCharset();

 // Add this line, here:
 coyoteRequest.setCharset(charset);


I'm less sure of this because of this line in the Javadoc for 
getCharacterEncoding():


@return ... null if the request does not specify a 
character encoding


It is at this point that the character set is truly committed, at 
least when parsing parameters.


In getReader, we have similar logic, where we set the character set 
for the request after determining what it actually is:


Which suggests the second of the above changes might be OK even if the 
spec suggests otherwise.


At the moment, I'm leaning towards just the first of your proposed 
changes but I'm open to arguments to do more.


I'm happy with incremental changes. Making the first change will be an 
improvement for sure.


On the other hand, if code calls request.setCharacterEncoding(non-null) 
then it will overwrite whatever the request had previously sent 
(including null). So in that case, request.getCharacterEncoding isn't 
always returning "what the client sent".


-chris

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

Re: [PROPOSAL] Explicitly-set the request character encoding when it has been committed

[Mark Thomas]

On 01/04/2021 17:08, Christopher Schultz wrote:



The javadoc says that it must be called before reading any request 
parameters OR calling getReader() but there is only a check for the reader.


Maybe we should change the check to:

     if (usingReader || parametersParsed) {
     return;
     }


+1


And also, change Request.parseParameters to add:

     // getCharacterEncoding() may have been overridden to 
search for

     // hidden form field containing request encoding
     Charset charset = getCharset();

     // Add this line, here:
     coyoteRequest.setCharset(charset);


I'm less sure of this because of this line in the Javadoc for 
getCharacterEncoding():


@return ... null if the request does not specify a 
character encoding


It is at this point that the character set is truly committed, at least 
when parsing parameters.


In getReader, we have similar logic, where we set the character set for 
the request after determining what it actually is:


Which suggests the second of the above changes might be OK even if the 
spec suggests otherwise.


At the moment, I'm leaning towards just the first of your proposed 
changes but I'm open to arguments to do more.


Mark

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

[PROPOSAL] Explicitly-set the request character encoding when it has been committed

[Christopher Schultz]

All,

Yesterday, I struggled to determine why my application was behaving 
differently than it had been in the past, and the problem turned out to 
be that I had inserted a  in the filter-chain before my 
CharacterEncodingFilter. My new  was reading a 
request-parameter. The CharacterEncodingFilter looks like this:


public void doFilter(ServletRequest request,
 ServletResponse response,
 FilterChain chain)
throws IOException, ServletException
{
request.setCharacterEncoding(getCharacterEncoding(request));

chain.doFilter(request, response);
}

protected String getCharacterEncoding(ServletRequest request)
{
String charset=request.getCharacterEncoding();

if(null == charset)
return this.getDefaultEncoding();
else
return charset;
}

The "default encoding" is essentially always UTF-8.

When looking at the request in my servlet, the character encoding 
reported by the request was "UTF-8", but the actual encoding used 
appeared to be ISO-8859-1 (the protocol default).


It looks like Tomcat is defaulting to ISO-8859-1 but continuing to 
return null for request.getCharacterEncoding().


My proposal is to have Tomcat set the request encoding field to 
"ISO-8859-1" in the following situation:


1. The character encoding is null
2. A method is called which requires that the character encoding be 
"committed"


Once that charset is determined, changing the request's charset has no 
effect whatsoever other than to confuse the application developer.


If Tomcat were to explicitly-set that encoding, my 
CharacterEncodingFilter wouldn't detect null and override that request 
charset with "UTF-8", thereby lying to the rest of the application.


I might even go so far as to propose that calling 
request.setCharacterEncoding() after the encoding has been committed 
should throw IllegalStateException. (This may be a violation of the 
spec, as the javadoc only declares UnsupportedEncodingException).


The javadoc state:

"
Overrides the name of the character encoding used in the body of this 
request. This method must be called prior to reading request parameters 
or reading input using getReader(). *Otherwise, it has no effect.*

"

(emphasis mine)

In Tomcat, if you call setCharacterEncoding("UTF-8") after request 
parameters have been read, there *is* an effect: you change the value of 
the charset field in the response.


This is the current implementation of setCharacterEncoding:

/**
 * Overrides the name of the character encoding used in the body of
 * this request.  This method must be called prior to reading request
 * parameters or reading input using getReader().
 *
 * @param enc The character encoding to be used
 *
 * @exception UnsupportedEncodingException if the specified encoding
 *  is not supported
 *
 * @since Servlet 2.3
 */
public void setCharacterEncoding(String enc) throws 
UnsupportedEncodingException {


if (usingReader) {
return;
}

// Confirm that the encoding name is valid
Charset charset = B2CConverter.getCharset(enc);

// Save the validated encoding
coyoteRequest.setCharset(charset);
}

The javadoc says that it must be called before reading any request 
parameters OR calling getReader() but there is only a check for the reader.


Maybe we should change the check to:

if (usingReader || parametersParsed) {
return;
}

And also, change Request.parseParameters to add:

// getCharacterEncoding() may have been overridden to 
search for

// hidden form field containing request encoding
Charset charset = getCharset();

// Add this line, here:
coyoteRequest.setCharset(charset);

It is at this point that the character set is truly committed, at least 
when parsing parameters.


In getReader, we have similar logic, where we set the character set for 
the request after determining what it actually is:


if (coyoteRequest.getCharacterEncoding() == null) {
// Nothing currently set explicitly.
// Check the content
Context context = getContext();
if (context != null) {
String enc = context.getRequestCharacterEncoding();
if (enc != null) {
// Explicitly set the context default so it is 
visible to

// InputBuffer when creating the Reader.
setCharacterEncoding(enc);
}
}
}

I'm open to any or all of the above, but I think something should be 
done. It was surprising to see that the request's charset was "UTF-8" 
and yet the UTF-8 bytes sent to the container were coming out mangled in 
the application.


If the app

Re: [PROPOSAL] Change default SSLHostConfig.protocols

[Mark Thomas]

On 12/01/2021 19:31, Christopher Schultz wrote:
> All,
> 
> For Tomcat 10 (only), I propose we change the default SSLHostConfig
> protocols attribute from the current "SSLv2Hello, TLSv1, TLSv1.1,
> TLSv1.2, TLSv1.3" to SSLv2Hello, TLSv1.2, TLSv1.3".
> 
> (That is, remove TLSv1 and TLSv1.1 from the default list.)
> 
> Any objections?

None here.

Mark

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

[PROPOSAL] Change default SSLHostConfig.protocols

[Christopher Schultz]

All,

For Tomcat 10 (only), I propose we change the default SSLHostConfig 
protocols attribute from the current "SSLv2Hello, TLSv1, TLSv1.1, 
TLSv1.2, TLSv1.3" to SSLv2Hello, TLSv1.2, TLSv1.3".


(That is, remove TLSv1 and TLSv1.1 from the default list.)

Any objections?

-chris

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

Re: [PROPOSAL]

[Christopher Schultz]

Rémy,

On 10/30/20 12:40, Rémy Maucherat wrote:

On Fri, Oct 30, 2020 at 5:34 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Rémy,

On 10/30/20 10:21, Rémy Maucherat wrote:

On Fri, Oct 30, 2020 at 2:41 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

I propose that we enable RECYCLE_FACADES by default in Tomcat 10.



It has already been refactored.


Oh, right. So maybe I need to amend by proposal:

I propose that we enable discardFacades="true" on  in Tomcat
10. That could be done in one of two ways:

1. The default value for discardFacades is "true"

2. The default s in server.xml ship with discardFacades="true"



But that's also the case (except it's not in server.xml like most
parameters). It's in the changelog for 10.0.0-M1.


LOL. I read the changelog but completely ignored the very end of the 
sentence.


PROPOSAL ACCEPTED! :)

Thanks,
-chris

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

Re: [PROPOSAL]

[Rémy Maucherat]

On Fri, Oct 30, 2020 at 5:34 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Rémy,
>
> On 10/30/20 10:21, Rémy Maucherat wrote:
> > On Fri, Oct 30, 2020 at 2:41 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> All,
> >>
> >> I propose that we enable RECYCLE_FACADES by default in Tomcat 10.
> >>
> >
> > It has already been refactored.
>
> Oh, right. So maybe I need to amend by proposal:
>
> I propose that we enable discardFacades="true" on  in Tomcat
> 10. That could be done in one of two ways:
>
> 1. The default value for discardFacades is "true"
>
> 2. The default s in server.xml ship with discardFacades="true"
>

But that's also the case (except it's not in server.xml like most
parameters). It's in the changelog for 10.0.0-M1.

Rémy


>
> -chris
>
> >> Reasons:
> >>
> >> 1. It is "safer"
> >>
> >> When running untrusted applications, a malicious application can
> >> potentially spy on others.
> >>
> >> Application bugs can cause request/response confusion.
> >>
> >> 2. It reduces the number of false bug reports
> >>
> >> Anytime something odd is happening with an application running on
> >> Tomcat, the application owner usually emails users@ and/or reports a
> bug
> >> against Tomcat. The first thing we say is "enable RECYCLE_FACADES to be
> >> sure it's not your application".
> >>
> >> 3. Performance hit is probably minimal
> >>
> >> I have no data on this, but I'm assuming that GC isn't an issue at all:
> >> most requests/responses will be created and die all inside of the young
> >> generation (or whatever it's called these days).
> >>
> >> I'm not sure how expensive creating a new request/response is. Perhaps
> >> we could look into some targeted performance optimizations in this area.
> >>
> >> 4. Re-enabling RECYCLE_FACADES is trivial
> >>
> >> Just put it in setenv.sh/setenv.bat/catalina.policy
> >>
> >> I do not think we should change the default in Tomcat <10 as this might
> >> be a surprise to a lot of users.
> >>
> >> -chris
> >>
> >> -
> >> 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]

[Christopher Schultz]

Rémy,

On 10/30/20 10:21, Rémy Maucherat wrote:

On Fri, Oct 30, 2020 at 2:41 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

I propose that we enable RECYCLE_FACADES by default in Tomcat 10.



It has already been refactored.


Oh, right. So maybe I need to amend by proposal:

I propose that we enable discardFacades="true" on  in Tomcat 
10. That could be done in one of two ways:


1. The default value for discardFacades is "true"

2. The default s in server.xml ship with discardFacades="true"

-chris


Reasons:

1. It is "safer"

When running untrusted applications, a malicious application can
potentially spy on others.

Application bugs can cause request/response confusion.

2. It reduces the number of false bug reports

Anytime something odd is happening with an application running on
Tomcat, the application owner usually emails users@ and/or reports a bug
against Tomcat. The first thing we say is "enable RECYCLE_FACADES to be
sure it's not your application".

3. Performance hit is probably minimal

I have no data on this, but I'm assuming that GC isn't an issue at all:
most requests/responses will be created and die all inside of the young
generation (or whatever it's called these days).

I'm not sure how expensive creating a new request/response is. Perhaps
we could look into some targeted performance optimizations in this area.

4. Re-enabling RECYCLE_FACADES is trivial

Just put it in setenv.sh/setenv.bat/catalina.policy

I do not think we should change the default in Tomcat <10 as this might
be a surprise to a lot of users.

-chris

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

[Rémy Maucherat]

On Fri, Oct 30, 2020 at 2:41 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> I propose that we enable RECYCLE_FACADES by default in Tomcat 10.
>

It has already been refactored.

Rémy


>
> Reasons:
>
> 1. It is "safer"
>
> When running untrusted applications, a malicious application can
> potentially spy on others.
>
> Application bugs can cause request/response confusion.
>
> 2. It reduces the number of false bug reports
>
> Anytime something odd is happening with an application running on
> Tomcat, the application owner usually emails users@ and/or reports a bug
> against Tomcat. The first thing we say is "enable RECYCLE_FACADES to be
> sure it's not your application".
>
> 3. Performance hit is probably minimal
>
> I have no data on this, but I'm assuming that GC isn't an issue at all:
> most requests/responses will be created and die all inside of the young
> generation (or whatever it's called these days).
>
> I'm not sure how expensive creating a new request/response is. Perhaps
> we could look into some targeted performance optimizations in this area.
>
> 4. Re-enabling RECYCLE_FACADES is trivial
>
> Just put it in setenv.sh/setenv.bat/catalina.policy
>
> I do not think we should change the default in Tomcat <10 as this might
> be a surprise to a lot of users.
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[PROPOSAL]

[Christopher Schultz]

All,

I propose that we enable RECYCLE_FACADES by default in Tomcat 10.

Reasons:

1. It is "safer"

When running untrusted applications, a malicious application can 
potentially spy on others.


Application bugs can cause request/response confusion.

2. It reduces the number of false bug reports

Anytime something odd is happening with an application running on 
Tomcat, the application owner usually emails users@ and/or reports a bug 
against Tomcat. The first thing we say is "enable RECYCLE_FACADES to be 
sure it's not your application".


3. Performance hit is probably minimal

I have no data on this, but I'm assuming that GC isn't an issue at all: 
most requests/responses will be created and die all inside of the young 
generation (or whatever it's called these days).


I'm not sure how expensive creating a new request/response is. Perhaps 
we could look into some targeted performance optimizations in this area.


4. Re-enabling RECYCLE_FACADES is trivial

Just put it in setenv.sh/setenv.bat/catalina.policy

I do not think we should change the default in Tomcat <10 as this might 
be a surprise to a lot of users.


-chris

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

Re: [PROPOSAL] Remove the functional specs from docs webapp

[Coty Sutherland]

On Mon, Aug 10, 2020 at 11:46 AM Mark Thomas  wrote:

> Hi all,
>
> I'd like to propose removing all the functional spec pages from the
> documentation web application.
>
> My reasoning for this proposal is, in short, that we aren't using or
> maintaining these pages.
>
> I don't recall any discussion of these docs on the dev list, proposals
> to change them, proposals for additions etc.
>
> There have been changes but going back over the changes from the last 10
> years (and there are very few of them) they each appear to be part of a
> wider global change that is updating something or removing references to
> a feature that has been removed.
>
> Should someone want to revive these pages, or more likely a subset of
> them, they'll always be in the history.
>
> Thoughts?
>

+1 to remove


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

Re: [PROPOSAL] Remove the functional specs from docs webapp

[Keiichi Fujino]

+1

2020年8月11日(火) 0:46 Mark Thomas :

> Hi all,
>
> I'd like to propose removing all the functional spec pages from the
> documentation web application.
>
> My reasoning for this proposal is, in short, that we aren't using or
> maintaining these pages.
>
> I don't recall any discussion of these docs on the dev list, proposals
> to change them, proposals for additions etc.
>
> There have been changes but going back over the changes from the last 10
> years (and there are very few of them) they each appear to be part of a
> wider global change that is updating something or removing references to
> a feature that has been removed.
>
> Should someone want to revive these pages, or more likely a subset of
> them, they'll always be in the history.
>
> Thoughts?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Keiichi.Fujino

Re: [PROPOSAL] Remove the functional specs from docs webapp

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/11/20 15:04, Mark Thomas wrote:
> On 11/08/2020 17:30, Michael Osipov wrote:
>> Am 2020-08-10 um 17:46 schrieb Mark Thomas:
>>> Hi all,
>>>
>>> I'd like to propose removing all the functional spec pages from
>>> the documentation web application.
>
> 
>
>> +1
>>
>> Can you list them specifically? I am a bit lost which you exactly
>> mean.
>
> Everything under:
>
> https://tomcat.apache.org/tomcat-10.0-doc/funcspecs/

Yeah... it seems like most of this stuff is covered under the Users
Guide and the Configuration guide.

+1 to removing them

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8z7jQACgkQHPApP6U8
pFj1Fw/+KlhG63peGtQyWhPoaQHtzRbnq1XqS9AxYveP7aqCskB24SApniZvd693
WjQmM9okoOMhoSqDWyg0ztvss3anL/jUDSDK3mkJSZ03/i21BnbwHUxJDa2we8AK
wScNkUpvneRxMXyMT5hx14ZSCp6BXe2Zeg2Y0431Su/eeHVAOYyGMrMNEXHWFtup
kVoJ2X0rfwmg12yyOsfvxcbqXFxDnueKX2hsQut6KC7UfyEz//C78AE49HJjrQNx
0Tap7Nz/OlUZ9t/GfHe+6WBQVX8H1q686EqMSiVvPrpmRlWkx67hP7C0eDWgfVty
Y2TWr/qvTQ0OUJXKjlciPnj/KVVLGm4tdFHnf/d+d7fJ6++2DiwTtXuGD0mZc+/W
5xiQFM3PZhqmB3MaP90vvE44rT+M4HMcwkTLWc+UdQlmpPLwPQE+gxwCSkvBnBfu
f8gpIREwPhlDEgwl0E0X9hblVMdEFKJtFZDj+cgv3qfTCm2530oDCucfd0LDzl0t
X294YuovyF1b0rvKRIf+zIVUDOrXOWwvsNZQIeWjdGYnkQdv2Kb4kFL0LjmjB+rl
QffseMDBzjikY2wN4cXXVTjEjfuabNe8vs3x9LuJypOWNyfmqrMV7f8kud+99IHY
G+QYoKc0Wjs3gvKHhYw9fFYEGqiUZirNkQxbhKbkTVjVIlqfpxQ=
=b53b
-END PGP SIGNATURE-

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

Re: [PROPOSAL] Remove the functional specs from docs webapp

[Michael Osipov]

Am 2020-08-11 um 21:04 schrieb Mark Thomas:

On 11/08/2020 17:30, Michael Osipov wrote:

Am 2020-08-10 um 17:46 schrieb Mark Thomas:

Hi all,

I'd like to propose removing all the functional spec pages from the
documentation web application.





+1

Can you list them specifically? I am a bit lost which you exactly mean.


Everything under:

https://tomcat.apache.org/tomcat-10.0-doc/funcspecs/


Thanks, I hav never seen these pages before.

A lot of information would be gone, but I prefer rather no information 
than outdated -- even worse wrong information.


M

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

Re: [PROPOSAL] Remove the functional specs from docs webapp

[Mark Thomas]

On 11/08/2020 17:30, Michael Osipov wrote:
> Am 2020-08-10 um 17:46 schrieb Mark Thomas:
>> Hi all,
>>
>> I'd like to propose removing all the functional spec pages from the
>> documentation web application.



> +1
> 
> Can you list them specifically? I am a bit lost which you exactly mean.

Everything under:

https://tomcat.apache.org/tomcat-10.0-doc/funcspecs/

Mark

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

Re: [PROPOSAL] Remove the functional specs from docs webapp

[Michael Osipov]

Am 2020-08-10 um 17:46 schrieb Mark Thomas:

Hi all,

I'd like to propose removing all the functional spec pages from the
documentation web application.

My reasoning for this proposal is, in short, that we aren't using or
maintaining these pages.

I don't recall any discussion of these docs on the dev list, proposals
to change them, proposals for additions etc.

There have been changes but going back over the changes from the last 10
years (and there are very few of them) they each appear to be part of a
wider global change that is updating something or removing references to
a feature that has been removed.

Should someone want to revive these pages, or more likely a subset of
them, they'll always be in the history.

Thoughts?


+1

Can you list them specifically? I am a bit lost which you exactly mean.

M

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

Re: [PROPOSAL] Remove the functional specs from docs webapp

[Filip Hanik]

+1

On Mon, Aug 10, 2020 at 08:46 Mark Thomas  wrote:

> Hi all,
>
> I'd like to propose removing all the functional spec pages from the
> documentation web application.
>
> My reasoning for this proposal is, in short, that we aren't using or
> maintaining these pages.
>
> I don't recall any discussion of these docs on the dev list, proposals
> to change them, proposals for additions etc.
>
> There have been changes but going back over the changes from the last 10
> years (and there are very few of them) they each appear to be part of a
> wider global change that is updating something or removing references to
> a feature that has been removed.
>
> Should someone want to revive these pages, or more likely a subset of
> them, they'll always be in the history.
>
> Thoughts?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [PROPOSAL] Remove the functional specs from docs webapp

[Martin Grigorov]

On Mon, Aug 10, 2020 at 6:46 PM Mark Thomas  wrote:

> Hi all,
>
> I'd like to propose removing all the functional spec pages from the
> documentation web application.
>
> My reasoning for this proposal is, in short, that we aren't using or
> maintaining these pages.
>
> I don't recall any discussion of these docs on the dev list, proposals
> to change them, proposals for additions etc.
>
> There have been changes but going back over the changes from the last 10
> years (and there are very few of them) they each appear to be part of a
> wider global change that is updating something or removing references to
> a feature that has been removed.
>
> Should someone want to revive these pages, or more likely a subset of
> them, they'll always be in the history.
>
> Thoughts?
>

+1


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

[PROPOSAL] Remove the functional specs from docs webapp

[Mark Thomas]

Hi all,

I'd like to propose removing all the functional spec pages from the
documentation web application.

My reasoning for this proposal is, in short, that we aren't using or
maintaining these pages.

I don't recall any discussion of these docs on the dev list, proposals
to change them, proposals for additions etc.

There have been changes but going back over the changes from the last 10
years (and there are very few of them) they each appear to be part of a
wider global change that is updating something or removing references to
a feature that has been removed.

Should someone want to revive these pages, or more likely a subset of
them, they'll always be in the history.

Thoughts?

Mark

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

Re: [PROPOSAL] Tomcat 10: rename language bundles

[Rémy Maucherat]

On Mon, Feb 3, 2020 at 10:13 AM Konstantin Kolinko 
wrote:

> сб, 1 февр. 2020 г. в 16:31, Michael Osipov :
> >
> > Am 2020-01-30 um 18:41 schrieb Konstantin Kolinko:
> > > ср, 29 янв. 2020 г. в 00:08, Michael Osipov :
> > >
> > > [...]
> > >
> > > (Being too strict about language is a barrier that may reject people.)
> >
> > For those who don't know both, they don't care. For those who know care
> > to make it right/consistent. I see no downsides to make it right.
> >
> > This has nothing to do with American, British, You Name It English. It
> > is simply about consistent naming.
>
> I see no positive sides in the proposed renaming,
> and I do not feel it to be a right thing.
>

It's hard to argue the usefulness of the fix is limited. I'm not going to
-1 it though since the problem might be my fault (can't remember, that's
convenient :) ).

Rémy


>
> Some downsides were already mentioned by others. I will write down a
> more complete list below.
>
> > For those who don't know both, they don't care.
>
> "i18n" is a more widely known and widely used word.
>
> Familiar words make people feel more comfortable.
>
> > > 2. In multi-module projects built with Apache Maven, one widely used
> > > naming convention is to name artifacts produced by the nested modules
> > > as -.
> > >
> > > E.g., a discussion:
> > >
> https://stackoverflow.com/questions/9435460/maven-naming-conventions-for-hierarchical-multiple-module-projects
> > >
> > > I mean that the current artifact names of "tomcat-i18n-" can
> > > be interpreted as module "" in a parent project "tomcat-i18n".
> > > It means that those artifacts are part of internationalization effort
> > > in Tomcat.
> >
> > I don't see how this is related?! Nor did I bring up to do any migration
> > to Maven or its naming scheme.
>
> I mean that "tomcat-i18n" is the base name.
>
> It is not "tomcat" + "-i18n-de",  but "tomcat-i18n" + "-de", as an example.
>
> The current names are not wrong.
>
>
> > > 3. Overall, my vote for this proposal is -0.5.
> > >
> > > It is not a veto, but I do not like it.
> >
> > So you generally do not object, but don't see a need for?
>
> I really object.
> I just do not veto, I do not end the discussion here at once.
>
>
> If there were other reasons to justify the change (e.g. some
> reorganization of packaging), ...
>
> (E.g. all translation files could be packaged into a single jar.)
>
> > I see no downsides ...
>
> To make it clear, the following are externally visible consequences of
> such a change:
>
> 1. Renaming of artifacts in Maven
> 2. Renaming of libraries in ${catalina.base}/lib
> 3. Change of configuration in conf/catalina.properties file (the
> libraries are mentioned in a jarsToSkip pattern).
>
> The following are internal changes:
> 4. Changes in build procedure (in build.xml, res/maven/mvn-pub.xml).
> 5. Changes in documentation (class-loader-howto.xml mentions the files).
>
> ##1-3 are the downsides that downstream consumers of Tomcat would have
> to adapt to.
>
> I certainly would have to change some of my scripts that I use with
> Tomcat and some configuration settings.
>
> ##4-5 are our internal matter.
>
> 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: rename language bundles

[Konstantin Kolinko]

сб, 1 февр. 2020 г. в 16:31, Michael Osipov :
>
> Am 2020-01-30 um 18:41 schrieb Konstantin Kolinko:
> > ср, 29 янв. 2020 г. в 00:08, Michael Osipov :
> >
> > [...]
> >
> > (Being too strict about language is a barrier that may reject people.)
>
> For those who don't know both, they don't care. For those who know care
> to make it right/consistent. I see no downsides to make it right.
>
> This has nothing to do with American, British, You Name It English. It
> is simply about consistent naming.

I see no positive sides in the proposed renaming,
and I do not feel it to be a right thing.

Some downsides were already mentioned by others. I will write down a
more complete list below.

> For those who don't know both, they don't care.

"i18n" is a more widely known and widely used word.

Familiar words make people feel more comfortable.

> > 2. In multi-module projects built with Apache Maven, one widely used
> > naming convention is to name artifacts produced by the nested modules
> > as -.
> >
> > E.g., a discussion:
> > https://stackoverflow.com/questions/9435460/maven-naming-conventions-for-hierarchical-multiple-module-projects
> >
> > I mean that the current artifact names of "tomcat-i18n-" can
> > be interpreted as module "" in a parent project "tomcat-i18n".
> > It means that those artifacts are part of internationalization effort
> > in Tomcat.
>
> I don't see how this is related?! Nor did I bring up to do any migration
> to Maven or its naming scheme.

I mean that "tomcat-i18n" is the base name.

It is not "tomcat" + "-i18n-de",  but "tomcat-i18n" + "-de", as an example.

The current names are not wrong.


> > 3. Overall, my vote for this proposal is -0.5.
> >
> > It is not a veto, but I do not like it.
>
> So you generally do not object, but don't see a need for?

I really object.
I just do not veto, I do not end the discussion here at once.


If there were other reasons to justify the change (e.g. some
reorganization of packaging), ...

(E.g. all translation files could be packaged into a single jar.)

> I see no downsides ...

To make it clear, the following are externally visible consequences of
such a change:

1. Renaming of artifacts in Maven
2. Renaming of libraries in ${catalina.base}/lib
3. Change of configuration in conf/catalina.properties file (the
libraries are mentioned in a jarsToSkip pattern).

The following are internal changes:
4. Changes in build procedure (in build.xml, res/maven/mvn-pub.xml).
5. Changes in documentation (class-loader-howto.xml mentions the files).

##1-3 are the downsides that downstream consumers of Tomcat would have
to adapt to.

I certainly would have to change some of my scripts that I use with
Tomcat and some configuration settings.

##4-5 are our internal matter.

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: rename language bundles

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 2/1/20 8:31 AM, Michael Osipov wrote:
> Am 2020-01-30 um 18:41 schrieb Konstantin Kolinko:
>> ср, 29 янв. 2020 г. в 00:08, Michael Osipov
>> :
>>> 
>>> Folks,
>>> 
>>> I recently worked on some localization issues and noticed that,
>>> in my opinion, these JARs are incorrectly named:
>>> 
 tomcat-i18n-cs.jar tomcat-i18n-de.jar tomcat-i18n-es.jar 
 tomcat-i18n-fr.jar tomcat-i18n-ja.jar tomcat-i18n-ko.jar 
 tomcat-i18n-pt-BR.jar tomcat-i18n-ru.jar 
 tomcat-i18n-zh-CN.jar
>>> 
>>> Most people confuse I18N with L10N -- but they are distinct.
>>> According to Mozilla [1] Tomcat is internationalized and
>>> provides localization with those bundles. As far as I
>>> understand that, they should be
>>> 
>>> either tomcat-l10n-.jar or tomcat-nls-.jar
>>> 
>>> [...]
>>> 
>>> Comments?
>> 
>> 1. Overall, I am not convinced.
>> 
>> I think that for an average foreigner a discussion about what
>> term is better makes little sense. I know people for whom those
>> words are hard to pronounce and are a little obscure.
>> 
>> Does changing one "obscure" word with another makes life easier?
>> How? Does it help to reach some wider audience?
>> 
>> I think that it would be better to keep it simple (KISS) and
>> continue using the existing historic naming pattern.
>> 
>> I am really proud of 20+ years of history of our project. If
>> there are some things there that are not proper [American]
>> English, it just means that there are different people involved
>> with the project, and it is a good sign.
>> 
>> (Being too strict about language is a barrier that may reject
>> people.)
> 
> For those who don't know both, they don't care. For those who know
> care to make it right/consistent. I see no downsides to make it
> right.
> 
> This has nothing to do with American, British, You Name It English.
> It is simply about consistent naming.
> 
>> 2. In multi-module projects built with Apache Maven, one widely
>> used naming convention is to name artifacts produced by the
>> nested modules as -.
>> 
>> E.g., a discussion: 
>> https://stackoverflow.com/questions/9435460/maven-naming-conventions-
for-hierarchical-multiple-module-projects
>>
>>
>>
>> 
I mean that the current artifact names of "tomcat-i18n-" can
>> be interpreted as module "" in a parent project
>> "tomcat-i18n". It means that those artifacts are part of
>> internationalization effort in Tomcat.
> 
> I don't see how this is related?! Nor did I bring up to do any
> migration to Maven or its naming scheme.

Tomcat produces Maven artifacts, even if we don't use a Maven-based
build. I think Konstantin is talking about the artifact names. Mark
also brought this up previously. If we change them, we need to offer
an obvious "upgrade" path. AIUI, these days, Maven doesn't do
latest-dependency resolution but instead requires specific versions to
be referenced. I think that frees us from introducing an incompatible
name-change because every version itself is practically-incompatible
with all previous versions from a dependency-resolution standpoint.
I'd appreciate some clarity from those who understand Maven better than
I.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl41uzIACgkQHPApP6U8
pFiJWw//YmQwkUTfT6ucVVATHBw44ZgDPE1Bo6uC4QlACEA8IVI1F1D91epBbknR
xdK5sXy4zdFe0bmuaD7rf+VA1MsIx6NdNFBgGl/vNnDXVm7SpG3dRfThPDD2+HHa
MZTIB1OfNSuIdh6LZJmg+0cxf2UjtHqCwDeGkPEhVds0pVpkXwtVAVsZtGjyUuCb
F+C8Vd/cW84Ji0CcUErMYgW1+BPC1OB3yd6yvpwJJ5aukQCZ3hZxpahyJRszYHV6
GaN5vfmQAualHHGCULVVcLkY2tS4FTyfRc3p33qQiRbZTA+vebCSfLIUJNhGeHl0
mGkRRykgL+lrnlXow6XlRaHJHl2y4gDKHlI9wq+rCAi9OYWF/IpPWlo4iZZj2k+h
o7c2+7XIs9VdouVbr4rOhGXfXOEsoAflUl5l3XhxO7/T4FBYjy8Ci4PYge5n22vY
u+PytCvVPh4Rs42m3no8aJPu0P8mUmRwdXsG2FyPIjJktvaiQGnIyMaFxqrvNiq6
4MyxGFoPE+xaFHWvo8cjsoWcduMTcuuuo8dxBTeL57c7i+T0TFWUWWDlMarnWWyh
zx5NlczsAObXf+uo0rQ7pJQP3/6NaLdLs+A8mcnOO+L3pF6MNLeQCS2vIgYj2t4p
5VD7gjJ9/E8kmdslXeaQUVP1cp4IcLpiMBkRAzV7WD4XeUmxxuk=
=NQzC
-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: rename language bundles

[Michael Osipov]

Am 2020-01-30 um 18:41 schrieb Konstantin Kolinko:

ср, 29 янв. 2020 г. в 00:08, Michael Osipov :


Folks,

I recently worked on some localization issues and noticed that, in my
opinion, these JARs are incorrectly named:


tomcat-i18n-cs.jar
tomcat-i18n-de.jar
tomcat-i18n-es.jar
tomcat-i18n-fr.jar
tomcat-i18n-ja.jar
tomcat-i18n-ko.jar
tomcat-i18n-pt-BR.jar
tomcat-i18n-ru.jar
tomcat-i18n-zh-CN.jar


Most people confuse I18N with L10N -- but they are distinct. According
to Mozilla [1] Tomcat is internationalized and provides localization
with those bundles. As far as I understand that, they should be

either tomcat-l10n-.jar or tomcat-nls-.jar

[...]

Comments?


1. Overall, I am not convinced.

I think that for an average foreigner a discussion about what term is
better makes little sense. I know people for whom those words are hard
to pronounce and are a little obscure.

Does changing one "obscure" word with another makes life easier? How?
Does it help to reach some wider audience?

I think that it would be better to keep it simple (KISS) and continue
using the existing historic naming pattern.

I am really proud of 20+ years of history of our project. If there are
some things there that are not proper [American] English, it just
means that there are different people involved with the project, and
it is a good sign.

(Being too strict about language is a barrier that may reject people.)


For those who don't know both, they don't care. For those who know care 
to make it right/consistent. I see no downsides to make it right.


This has nothing to do with American, British, You Name It English. It 
is simply about consistent naming.



2. In multi-module projects built with Apache Maven, one widely used
naming convention is to name artifacts produced by the nested modules
as -.

E.g., a discussion:
https://stackoverflow.com/questions/9435460/maven-naming-conventions-for-hierarchical-multiple-module-projects

I mean that the current artifact names of "tomcat-i18n-" can
be interpreted as module "" in a parent project "tomcat-i18n".
It means that those artifacts are part of internationalization effort
in Tomcat.


I don't see how this is related?! Nor did I bring up to do any migration 
to Maven or its naming scheme.



3. Overall, my vote for this proposal is -0.5.

It is not a veto, but I do not like it.


So you generally do not object, but don't see a need for?

M


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

Re: [PROPOSAL] Tomcat 10: rename language bundles

[Konstantin Kolinko]

ср, 29 янв. 2020 г. в 00:08, Michael Osipov :
>
> Folks,
>
> I recently worked on some localization issues and noticed that, in my
> opinion, these JARs are incorrectly named:
>
> > tomcat-i18n-cs.jar
> > tomcat-i18n-de.jar
> > tomcat-i18n-es.jar
> > tomcat-i18n-fr.jar
> > tomcat-i18n-ja.jar
> > tomcat-i18n-ko.jar
> > tomcat-i18n-pt-BR.jar
> > tomcat-i18n-ru.jar
> > tomcat-i18n-zh-CN.jar
>
> Most people confuse I18N with L10N -- but they are distinct. According
> to Mozilla [1] Tomcat is internationalized and provides localization
> with those bundles. As far as I understand that, they should be
>
> either tomcat-l10n-.jar or tomcat-nls-.jar
>
> [...]
>
> Comments?

1. Overall, I am not convinced.

I think that for an average foreigner a discussion about what term is
better makes little sense. I know people for whom those words are hard
to pronounce and are a little obscure.

Does changing one "obscure" word with another makes life easier? How?
Does it help to reach some wider audience?

I think that it would be better to keep it simple (KISS) and continue
using the existing historic naming pattern.

I am really proud of 20+ years of history of our project. If there are
some things there that are not proper [American] English, it just
means that there are different people involved with the project, and
it is a good sign.

(Being too strict about language is a barrier that may reject people.)


2. In multi-module projects built with Apache Maven, one widely used
naming convention is to name artifacts produced by the nested modules
as -.

E.g., a discussion:
https://stackoverflow.com/questions/9435460/maven-naming-conventions-for-hierarchical-multiple-module-projects

I mean that the current artifact names of "tomcat-i18n-" can
be interpreted as module "" in a parent project "tomcat-i18n".
It means that those artifacts are part of internationalization effort
in Tomcat.

3. Overall, my vote for this proposal is -0.5.

It is not a veto, but I do not like it.

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: rename language bundles

[Michael Osipov]

Am 2020-01-28 um 22:53 schrieb Mark Thomas:

On 28/01/2020 21:52, Christopher Schultz wrote:

Michael,

On 1/28/20 4:08 PM, Michael Osipov wrote:

Folks,



I recently worked on some localization issues and noticed that, in
my opinion, these JARs are incorrectly named:



tomcat-i18n-cs.jar tomcat-i18n-de.jar tomcat-i18n-es.jar
tomcat-i18n-fr.jar tomcat-i18n-ja.jar tomcat-i18n-ko.jar
tomcat-i18n-pt-BR.jar tomcat-i18n-ru.jar tomcat-i18n-zh-CN.jar



Most people confuse I18N with L10N -- but they are distinct.
According to Mozilla [1] Tomcat is internationalized and provides
localization with those bundles. As far as I understand that, they
should be



either tomcat-l10n-.jar or tomcat-nls-.jar



NLS (native language support), for those who are familiar with
LC_MESSAGES and gettext/libintl or similar.



I don't know wether this can be backported to 8.5 or 9.0 due to
file renames, but should be an issue with 10.



[1]
https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/



  Comments?


+0

This is mostly a matter of style, but you are correct, i18n is inaccurat
e.


It does mean changing the Maven co-ordinates. While I agree the current
naming is wrong, is it wrong enough to break things for upgrading users?


Yes, it does mean to change the artifact id, but consider that people 
will receive them at most as transitive dependency, and the change is 
proposed for 10 where everthing is still in flux. It is an acceptable 
change for that version. For 8.5+ it is for the community to decide.


I will provide a PR for 10+ only.

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

Re: [PROPOSAL] Tomcat 10: change default certificateKeystoreType and truststoreType from JKS to PKCS12

[Coty Sutherland]

On Tue, Jan 28, 2020 at 12:07 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> The subject says it all.
>
> Java 9 is changing the default keystore type from JKS to PKCS12 and
> deprecating the use of JKS.
>
> Do we know what version of Java Tomcat 10 will require? I suspect it
> will be Java 9, so it will match.
>
> In any case, PKCS12 is a better format overall and it's very early in
> the Tomcat 10 lifecycle, so I think it's the right time to make this mov
> e.
>
> It looks like there is no default type for the trust store type
> (unless javax.net.ssl.trustStoreType has a default value), so I would
> propose that we also set that default type to PKCS12.
>

+1 :D


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wakwACgkQHPApP6U8
> pFg54hAAvtOwO8sGYHfllwEcQakaacJ6DvTG9YMb+mX3WvZVLPfQAv/Zn5ReV8fu
> 1tOd3Hux1W/CoYKiO4cMKjxn4mwO3/5lukYzNg1KtmsBpnqA15rUsci5VsivXMvR
> ylZkWLxt9TprcVc79cvlUrtj+xYTdiYv7p/YXGSh7JDSeSrqipGItW+QDKIH8kmg
> jNlgj67Gy2gCqGPIu/CZQgDQBn7nSWcaeB1U2WITFAKQhgCv+mCzEm6+oLrHhN9q
> IDBFqD7QlRSDRRAQTBgpnpaj2m/B5dBkXGMGMtRwkzx0IU6jO2nlWUkTmSFYn+js
> CneqphJ7szLj9JdbNUHrtBMxojDeJTejtigCTsnd+1DJEIoYJCOuy1D4e0V9eEiA
> kpaP5gsG6tN7fyk3E1w7xtmEq6dTPcNYv731RDMOC3WIQcBXxOQ5cFKhfxeWZBrZ
> mkdjksDoCizWLcmKA3p4xwNBsvi7qnOReq7TZfL1U/Lp39d/ncSxpTPxucOi5k5T
> PlJncwNsZA1tThfFjMlANXeYAeh74ajdMWAcRoIIzP09wyIQP2/pI6msBsQ6mr1j
> MOOt6b25XO9RgJBn/EYBlVKYjULdDSBd/ojcc92wZONhw8uqt6Ly7Xrj4t3eFQ4e
> EdjKPawmDhyZZ/B9IYC9p7doRuni26eBWx7wGkqQM3TqIn0Rc9k=
> =zoYm
> -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: rename language bundles

[Mark Thomas]

On 28/01/2020 21:52, Christopher Schultz wrote:
> Michael,
> 
> On 1/28/20 4:08 PM, Michael Osipov wrote:
>> Folks,
> 
>> I recently worked on some localization issues and noticed that, in
>> my opinion, these JARs are incorrectly named:
> 
>>> tomcat-i18n-cs.jar tomcat-i18n-de.jar tomcat-i18n-es.jar 
>>> tomcat-i18n-fr.jar tomcat-i18n-ja.jar tomcat-i18n-ko.jar 
>>> tomcat-i18n-pt-BR.jar tomcat-i18n-ru.jar tomcat-i18n-zh-CN.jar
> 
>> Most people confuse I18N with L10N -- but they are distinct.
>> According to Mozilla [1] Tomcat is internationalized and provides
>> localization with those bundles. As far as I understand that, they
>> should be
> 
>> either tomcat-l10n-.jar or tomcat-nls-.jar
> 
>> NLS (native language support), for those who are familiar with 
>> LC_MESSAGES and gettext/libintl or similar.
> 
>> I don't know wether this can be backported to 8.5 or 9.0 due to
>> file renames, but should be an issue with 10.
> 
>> [1]
>> https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/
> 
>>  Comments?
> 
> +0
> 
> This is mostly a matter of style, but you are correct, i18n is inaccurat
> e.

It does mean changing the Maven co-ordinates. While I agree the current
naming is wrong, is it wrong enough to break things for upgrading users?

Mark

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

Re: [PROPOSAL] Tomcat 10: rename language bundles

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 1/28/20 4:08 PM, Michael Osipov wrote:
> Folks,
> 
> I recently worked on some localization issues and noticed that, in
> my opinion, these JARs are incorrectly named:
> 
>> tomcat-i18n-cs.jar tomcat-i18n-de.jar tomcat-i18n-es.jar 
>> tomcat-i18n-fr.jar tomcat-i18n-ja.jar tomcat-i18n-ko.jar 
>> tomcat-i18n-pt-BR.jar tomcat-i18n-ru.jar tomcat-i18n-zh-CN.jar
> 
> Most people confuse I18N with L10N -- but they are distinct.
> According to Mozilla [1] Tomcat is internationalized and provides
> localization with those bundles. As far as I understand that, they
> should be
> 
> either tomcat-l10n-.jar or tomcat-nls-.jar
> 
> NLS (native language support), for those who are familiar with 
> LC_MESSAGES and gettext/libintl or similar.
> 
> I don't know wether this can be backported to 8.5 or 9.0 due to
> file renames, but should be an issue with 10.
> 
> [1]
> https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/
>
>  Comments?

+0

This is mostly a matter of style, but you are correct, i18n is inaccurat
e.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wrRcACgkQHPApP6U8
pFj7kw//TJVjXb2fdCDF8M51vHqGkw4HG8nq6rZPWXFS1+G01htVreAWBoXBpedb
ck0XA5hj2kV31iO+DN8cHxpcCP1xQGs39u8Xq3Dx03MhW3Tr+cE9ST0rjT2Qc5Ok
q/Z/KBUBKVp5/Vy4fI1e7mdbCfNeCyP99upRTg+xzEwV00B48P2k6VPm5VbvO4Ys
z+TDf9QwybbWYaAa9ySR743rCNhcT6U83PrjfrC7V5HSVhNGkLhIE+rfEeZcbUv6
PIk+kL1DtPITnNzzV5apkvGFStHK/5xOw5de0Zw7qXsKfL7+v6pnhB5Vsylg3qUr
S3cDHfMGS7omwDmvgSovMQm8OsP3/gzQqaS3EujDBpLmJNcYoFjnquq5bBV5YOc+
K+7p/TsI1/IZnCyHjvmfrOYGP7SwgKp76xVt+GxscAteM8DMq79gWIzK9bYyGPfd
lXzk7tEH8WWLdPeFK93CukJ9jPfxcu3YFwdQDxLCWUJBzlfSLUXaqdzeWtFA3VUM
15lNYZz04gWaLvchcWKoD9l+AaO6sXkYa60F26012Ug7SAxX6U/Pp2yNoQQsaQK5
CEbWTfjMBSh2XkXnlR+ITqmsuxbIPGCtHGS5MdnEHk5xBawMQ6uAq98qNM+VbdJG
pRVGpF7ej6TUMeX/jvHuDJ5bwJ3qs3ruOfI8vDZ2GMk0Q8WQKdg=
=2p4q
-END PGP SIGNATURE-

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

[PROPOSAL] Tomcat 10: rename language bundles

[Michael Osipov]

Folks,

I recently worked on some localization issues and noticed that, in my 
opinion, these JARs are incorrectly named:



tomcat-i18n-cs.jar
tomcat-i18n-de.jar
tomcat-i18n-es.jar
tomcat-i18n-fr.jar
tomcat-i18n-ja.jar
tomcat-i18n-ko.jar
tomcat-i18n-pt-BR.jar
tomcat-i18n-ru.jar
tomcat-i18n-zh-CN.jar


Most people confuse I18N with L10N -- but they are distinct. According 
to Mozilla [1] Tomcat is internationalized and provides localization 
with those bundles. As far as I understand that, they should be


either tomcat-l10n-.jar or tomcat-nls-.jar

NLS (native language support), for those who are familiar with 
LC_MESSAGES and gettext/libintl or similar.


I don't know wether this can be backported to 8.5 or 9.0 due to file 
renames, but should be an issue with 10.


[1] https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/

Comments?

Michael

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

Re: [PROPOSAL] Tomcat 10: change default certificateKeystoreType and truststoreType from JKS to PKCS12

[Martin Grigorov]

On Tue, Jan 28, 2020 at 7:07 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> The subject says it all.
>
> Java 9 is changing the default keystore type from JKS to PKCS12 and
> deprecating the use of JKS.
>
> Do we know what version of Java Tomcat 10 will require? I suspect it
> will be Java 9, so it will match.
>
> In any case, PKCS12 is a better format overall and it's very early in
> the Tomcat 10 lifecycle, so I think it's the right time to make this mov
> e.
>
> It looks like there is no default type for the trust store type
> (unless javax.net.ssl.trustStoreType has a default value), so I would
> propose that we also set that default type to PKCS12.
>

+1


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wakwACgkQHPApP6U8
> pFg54hAAvtOwO8sGYHfllwEcQakaacJ6DvTG9YMb+mX3WvZVLPfQAv/Zn5ReV8fu
> 1tOd3Hux1W/CoYKiO4cMKjxn4mwO3/5lukYzNg1KtmsBpnqA15rUsci5VsivXMvR
> ylZkWLxt9TprcVc79cvlUrtj+xYTdiYv7p/YXGSh7JDSeSrqipGItW+QDKIH8kmg
> jNlgj67Gy2gCqGPIu/CZQgDQBn7nSWcaeB1U2WITFAKQhgCv+mCzEm6+oLrHhN9q
> IDBFqD7QlRSDRRAQTBgpnpaj2m/B5dBkXGMGMtRwkzx0IU6jO2nlWUkTmSFYn+js
> CneqphJ7szLj9JdbNUHrtBMxojDeJTejtigCTsnd+1DJEIoYJCOuy1D4e0V9eEiA
> kpaP5gsG6tN7fyk3E1w7xtmEq6dTPcNYv731RDMOC3WIQcBXxOQ5cFKhfxeWZBrZ
> mkdjksDoCizWLcmKA3p4xwNBsvi7qnOReq7TZfL1U/Lp39d/ncSxpTPxucOi5k5T
> PlJncwNsZA1tThfFjMlANXeYAeh74ajdMWAcRoIIzP09wyIQP2/pI6msBsQ6mr1j
> MOOt6b25XO9RgJBn/EYBlVKYjULdDSBd/ojcc92wZONhw8uqt6Ly7Xrj4t3eFQ4e
> EdjKPawmDhyZZ/B9IYC9p7doRuni26eBWx7wGkqQM3TqIn0Rc9k=
> =zoYm
> -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: change default certificateKeystoreType and truststoreType from JKS to PKCS12

[Michael Osipov]

Am 2020-01-28 um 18:07 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

The subject says it all.

Java 9 is changing the default keystore type from JKS to PKCS12 and
deprecating the use of JKS.

Do we know what version of Java Tomcat 10 will require? I suspect it
will be Java 9, so it will match.

In any case, PKCS12 is a better format overall and it's very early in
the Tomcat 10 lifecycle, so I think it's the right time to make this mov
e.

It looks like there is no default type for the trust store type
(unless javax.net.ssl.trustStoreType has a default value), so I would
propose that we also set that default type to PKCS12.


Brilliant proposal.

+1

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

Re: [PROPOSAL] Tomcat 10: change default certificateKeystoreType and truststoreType from JKS to PKCS12

[Rémy Maucherat]

On Tue, Jan 28, 2020 at 6:07 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> The subject says it all.
>
> Java 9 is changing the default keystore type from JKS to PKCS12 and
> deprecating the use of JKS.
>
> Do we know what version of Java Tomcat 10 will require? I suspect it
> will be Java 9, so it will match.
>

No, it's Java 8. Later on the Tomcat 10 branch will move to Jakarta EE 10,
which may up the requirement to Java 9. When that's done, your change would
be fully aligned.


>
> In any case, PKCS12 is a better format overall and it's very early in
> the Tomcat 10 lifecycle, so I think it's the right time to make this mov
> e.
>
> It looks like there is no default type for the trust store type
> (unless javax.net.ssl.trustStoreType has a default value), so I would
> propose that we also set that default type to PKCS12.
>

Tomcat 10.0 is not a really useful release, it's only a preparation for
Tomcat 10.x so I think you can have fun ;)

Rémy


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wakwACgkQHPApP6U8
> pFg54hAAvtOwO8sGYHfllwEcQakaacJ6DvTG9YMb+mX3WvZVLPfQAv/Zn5ReV8fu
> 1tOd3Hux1W/CoYKiO4cMKjxn4mwO3/5lukYzNg1KtmsBpnqA15rUsci5VsivXMvR
> ylZkWLxt9TprcVc79cvlUrtj+xYTdiYv7p/YXGSh7JDSeSrqipGItW+QDKIH8kmg
> jNlgj67Gy2gCqGPIu/CZQgDQBn7nSWcaeB1U2WITFAKQhgCv+mCzEm6+oLrHhN9q
> IDBFqD7QlRSDRRAQTBgpnpaj2m/B5dBkXGMGMtRwkzx0IU6jO2nlWUkTmSFYn+js
> CneqphJ7szLj9JdbNUHrtBMxojDeJTejtigCTsnd+1DJEIoYJCOuy1D4e0V9eEiA
> kpaP5gsG6tN7fyk3E1w7xtmEq6dTPcNYv731RDMOC3WIQcBXxOQ5cFKhfxeWZBrZ
> mkdjksDoCizWLcmKA3p4xwNBsvi7qnOReq7TZfL1U/Lp39d/ncSxpTPxucOi5k5T
> PlJncwNsZA1tThfFjMlANXeYAeh74ajdMWAcRoIIzP09wyIQP2/pI6msBsQ6mr1j
> MOOt6b25XO9RgJBn/EYBlVKYjULdDSBd/ojcc92wZONhw8uqt6Ly7Xrj4t3eFQ4e
> EdjKPawmDhyZZ/B9IYC9p7doRuni26eBWx7wGkqQM3TqIn0Rc9k=
> =zoYm
> -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: change default certificateKeystoreType and truststoreType from JKS to PKCS12

[Mark Thomas]

On 28/01/2020 17:07, Christopher Schultz wrote:
> All,
> 
> The subject says it all.
> 
> Java 9 is changing the default keystore type from JKS to PKCS12 and
> deprecating the use of JKS.
> 
> Do we know what version of Java Tomcat 10 will require?

Java 8.

> I suspect it
> will be Java 9, so it will match.

Oh well...

> In any case, PKCS12 is a better format overall and it's very early in
> the Tomcat 10 lifecycle, so I think it's the right time to make this mov
> e.

My primary concern is backwards compatibility but users using JKS are
going to have to make the change at some point so it is really a
question of when. And Tomcat 10 does seem like as good a time as any.

> It looks like there is no default type for the trust store type
> (unless javax.net.ssl.trustStoreType has a default value), so I would
> propose that we also set that default type to PKCS12.

No objections here.

Mark

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

[PROPOSAL] Tomcat 10: change default certificateKeystoreType and truststoreType from JKS to PKCS12

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

The subject says it all.

Java 9 is changing the default keystore type from JKS to PKCS12 and
deprecating the use of JKS.

Do we know what version of Java Tomcat 10 will require? I suspect it
will be Java 9, so it will match.

In any case, PKCS12 is a better format overall and it's very early in
the Tomcat 10 lifecycle, so I think it's the right time to make this mov
e.

It looks like there is no default type for the trust store type
(unless javax.net.ssl.trustStoreType has a default value), so I would
propose that we also set that default type to PKCS12.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wakwACgkQHPApP6U8
pFg54hAAvtOwO8sGYHfllwEcQakaacJ6DvTG9YMb+mX3WvZVLPfQAv/Zn5ReV8fu
1tOd3Hux1W/CoYKiO4cMKjxn4mwO3/5lukYzNg1KtmsBpnqA15rUsci5VsivXMvR
ylZkWLxt9TprcVc79cvlUrtj+xYTdiYv7p/YXGSh7JDSeSrqipGItW+QDKIH8kmg
jNlgj67Gy2gCqGPIu/CZQgDQBn7nSWcaeB1U2WITFAKQhgCv+mCzEm6+oLrHhN9q
IDBFqD7QlRSDRRAQTBgpnpaj2m/B5dBkXGMGMtRwkzx0IU6jO2nlWUkTmSFYn+js
CneqphJ7szLj9JdbNUHrtBMxojDeJTejtigCTsnd+1DJEIoYJCOuy1D4e0V9eEiA
kpaP5gsG6tN7fyk3E1w7xtmEq6dTPcNYv731RDMOC3WIQcBXxOQ5cFKhfxeWZBrZ
mkdjksDoCizWLcmKA3p4xwNBsvi7qnOReq7TZfL1U/Lp39d/ncSxpTPxucOi5k5T
PlJncwNsZA1tThfFjMlANXeYAeh74ajdMWAcRoIIzP09wyIQP2/pI6msBsQ6mr1j
MOOt6b25XO9RgJBn/EYBlVKYjULdDSBd/ojcc92wZONhw8uqt6Ly7Xrj4t3eFQ4e
EdjKPawmDhyZZ/B9IYC9p7doRuni26eBWx7wGkqQM3TqIn0Rc9k=
=zoYm
-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: Drop APR Connector

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 11/11/19 14:20, Rémy Maucherat wrote:
> On Mon, Nov 11, 2019 at 7:47 PM Michael Osipov
> mailto:micha...@apache.org>> wrote:
> 
> To revive this, why APR is stil important:
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63916
> 
> There is some severe bug making NIO performing very bad.
> 
> 
> We're making long term plans here, a bug report filed yesterday is 
> rather irrelevant.

I tend to agree, especially due to the subsequent resolution of this
problem.

The BIO connector had better performance than NIO, too, with less CPU
usage and yet we still removed it.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3MNsIACgkQHPApP6U8
pFiagA/+MV29Y6W2GTfvAVDrfsv87jlB63BOqPbw7cNtUCA7XEH/iiK9kVSiOuqJ
0s9rBHMo0QtMAHEUixfgHRQFMeoAsEwSyJK4vAF3nN7kBBSq8fL7DGIczNEDmKf1
0p20DFTRGHJBxPptNCJJvSSgYn9MiUAXhiDaPomJ4daL/5dlLincWS7fo+kiP36L
cTglITbILknMyrGsYS9AvYQYEpA2epfJFiWHxDYO3ZgB4MCSazr9nmUky/Pscrir
ew8aBcCm0ArTB65v6729zB3f7UJxNo74FtkbSUtdR28WTvpVAcSVC9eiEFnivXR9
gyO9w9sZYAt0X5jZbV4SA23wnBLx63tWwNm3GNKBV+v2hOZYd5H8cF6iMJ20I/x4
MhqaLnUSQZyu2YvMXtwVAYkGGEnEmUagBU5quII2lSdyH6idsI70I01cxCMd8bEc
/64a81zriaQK20IlAEm6zAClC9dS3s8Qugx0hW+l+Gs73BTLOSzXK6Qm7XGH+uUV
hYMoK31i4lZKsctWKtuV1r9sOSNOSfDc91FjBnkasuXD/YO3K4ZoilYQwWvKpsoH
biLOMeA5PFGSi1ptaaIF/ij6BmHRwYaU75CXd2BCb9lDgGHbYge+8fhgU9Usip1b
8m8WGWtn6W6Cgs4ix4BdYSrvxqJaj37L5F8aZTQZlBoe/boXYzg=
=DCXE
-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: Drop APR Connector

[Rémy Maucherat]

On Mon, Nov 11, 2019 at 7:47 PM Michael Osipov  wrote:

> To revive this, why APR is stil important:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63916
>
> There is some severe bug making NIO performing very bad.
>

We're making long term plans here, a bug report filed yesterday is rather
irrelevant.

Rémy

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

[Michael Osipov]

Am 2019-10-09 um 21:40 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael

On 10/9/19 11:40, Michael Osipov wrote:

Am 2019-10-07 um 16:39 schrieb Christopher Schultz:

-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 APR connector

Justification:

The APR connector was once used to provide superior I/O when
compared to the only other available I/O mechanism available in
Java: blocking I/O. Specifically, the APR connector allowed
Tomcat to wait for keepalive requests on a connection to in a
non-blocking fashion which was not possible with Java BIO-based
connectors.

The introduction of NIO into Java back in Java 1.4 (!!) changed
things, and NIO support was added to Tomcat in 6.0. Now that it
has had time to mature, the NIO connector is superior to the APR
connector in several ways:

1. NIO connector allows non-blocking TLS handshakes 2. NIO
connector uses less (Tomcat-owned) native code

The first item improves performance and availability and the
second item improves stability (and thus availability).

The last advantage which (until recently) made the APR connector
still very useful was the ability to use the OpenSSL
cryptographic library for all cryptographic operations which is
measurably higher-performance than those typically provided by
the JVM.

This last advantage no longer exists since we have a JSSE
provider available for OpenSSL using libtcnative.

Notes:

This proposal does not recommend the removal of libtcnative. Only
the removal of the APR connector, the APR lifecycle listener, and
the associated native code required to support those components.


Though, I have no opion for or against. It has worked very well for
me for the last 10+ years on HP-UX for our software.


I'd love to get your feedback on NIO+OpenSSL, then.


To revive this, why APR is stil important:

https://bz.apache.org/bugzilla/show_bug.cgi?id=63916

There is some severe bug making NIO performing very bad.

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 WebDAV

[Konstantin Kolinko]

пн, 7 окт. 2019 г. в 17:54, Christopher Schultz :
>
> -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 WebDAV
>
> Justification:
>
> WebDAV is a protocol that never really took off[2]. Read-only WebDAV
> can practically be replaced by standard HTTP GET and read-write WebDAV
> has a host of security problems.

My preference is to keep the WebDAV Servlet:

1) It is a good example of HTTP protocol beyond standard HTTP.
2) There exist 3-rd party test suites for this protocol.
3) It is tightly coupled with DefaultServlet and Tomcat internals
(resources management layer)

4) There are no security issues with read-write WebDAV as far as I know.
Enabling write (HTTP PUT) on the DefaultServlet will have the same
consequences. You have to authenticate your clients.

I am using WebDAV on some Apache HTTPD server with mod_dav.
I planned to use WebDAV on some Tomcat servers but I ended with a
configuration where DefaultServlet displays the files and upload and
management of the files is performed via SSH/SCP.

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)

[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)

[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)

[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)

[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)

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

Re: [PROPOSAL] Tomcat 10: Remove CGI Servlet

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Note: this was not a vote.

There was very little feedback, and responses were mixed. We got
exactly one response on the users@ list about real-world usage of CGI,
so we cannot draw any conclusions about real-world uses.

Otherwise, the consensus seems to be that CGIs should stay a part of
the main Tomcat distribution, but that perhaps separating it out into
a distinct JAR file and/or separate distribution might be advantageous.

It appears that the CGIServlet is completely self-contained. It makes
use of the following internal(ish) Tomcat APIs:

org.apache.catalina.util.IOTools
org.apache.juli.logging.Log
org.apache.juli.logging.LogFactory
org.apache.tomcat.util.compat.JrePlatform
org.apache.tomcat.util.res.StringManager

All of these could be replaced if necessary to make a standalone,
container-agnostic package.

It looks like it would be fairly easy to separate-out the CGIServlet
into a separate JAR file packaging if there's utility in that. For
example, security-conscious environments may want to remove that JAR
file entirely from the Tomcat deployment to be absolutely sure that
Runtime.exec() isn't available in the deployed Java code (from the
container; yet I realize that SSIServlet/SSIFilter has this, too).

I'd like to go ahead and move the CGIServlet from the general
catalina.jar file into catalina-cgi.jar. That should only require a
small change to the build.xml script.

Any objections?

- -chris

On 10/7/19 10:59, 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 CGI Servlet
> 
> Justification:
> 
> The CGIServlet is another component, like server-side-includes,
> which is a remote-code execution (RCE) vulnerability as a feature.
> It is very easy to misconfigure. It is arguably not possible to
> secure it on Windows[2]. There are better solutions if you want to
> run Perl, Python, PHP, or whatever on your server in the form of
> the many fine web-server products out there.
> 
> -chris
> 
> 
> [1]
> http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
>
> 
at
> [2] 
> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/
23
>
> 
/everyone-quotes-command-line-arguments-the-wrong-way/
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2281sACgkQHPApP6U8
pFjMLw//cR2e2f32IUVK7kbbK2isBhmqd+GB/MhC9/Dt6d7iBPElr1gOid2zegpg
BLVzAdzCjUxR1TlzTfOqq7riZwYPui6+URGePsVyNms3c4tM9hWMArqtYRJFnQXt
bQCRS7dsS7dyonJTdJzAQFwN+zqjP1We4AORSO1uOjPA8wF7NK4d4mQ1yMaF7Bsj
CzGIzvo31iRCix2TUJiok0SrRU9qRQn8IzTU2tUswTEGDR0lTjnSc6XUzvBgYbmx
WF8AVLsjYIJKt1zDDAmAckhnio1Vq9jIwp/fHYd16NPy8n5Mfn1IkWmuZ8RGMDXM
o0W4/HYRYV+9WWiGF3aUrSbmu2hOwXdbPcYm+hzntWzyHoY5JGVSCXS1HrFIGr4S
TZTLzj7sCV+Yl5Na8spie3S5rZ0EsI2BzP7fwmvmBEHAzetFr/tQFYv9t6ibZHUF
e06ef39ws7sO8GlII3TEKfMaByY1BMX/jv8RD6qSCrdLPQgwAzInfL3wJLdqykNC
8SkS1h0Oo4Dm4lrBuAnrwo6cCZOVzI5SJz1q3hJja5BnAg1+7920ts4LGS1EbJVu
2mnlgWJg7veMkjGEyZs3W0WKkOZHnuQjY1gZRBDBnBqqRy7OUmWIftVixUK2m6sP
IKVnaT0f5bS47gqt4wahhuwLo5+JCEiSTpEVlhNV2ZK5ZwAvSWU=
=dNvr
-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)

[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 

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

[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/y9R0qYJdVuNqMn

Re: [PROPOSAL] Tomcat 10: Remove WebDAV

[Mark Thomas]

On 09/10/2019 21:42, Michael Osipov wrote:
> Am 2019-10-09 um 21:35 schrieb Christopher Schultz:



>>> The only drawback I see with the current servlet is that I cannot
>>> have arbitrary paths of my context served by this servlet. It
>>> serves either the entire app or nothing. That's why I have resorted
>>> to mod_dav.
>>
>> Okay, so someone who really wants to make DAV work has decided that
>> Tomcat's implementation won't cut it. I fee that as further evidence
>> that Tomcat's implementation can just die.
> 
> As you might know, people will only complain when something is
> gone/broken and not when it is working well.

If arbitrary path mapping would be useful then please add that as an
enhancement to Bugzilla. From memory, the path handling for WebDav is
"interesting" so I'm not sure how easy this would be to implement.

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 WebDAV

[Michael Osipov]

Am 2019-10-09 um 21:35 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 10/9/19 11:36, Michael Osipov wrote:

Am 2019-10-07 um 16:54 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Or, since svn is HTTP, you can just use plain-old HTTP. Besides,
mod_dav_svn doesn't work with Tomcat.


Again, plain HTTP != WebDAV.


Read-only WebDAV can practically be replaced by standard HTTP GET



No, it can't. you can't list collections with multistatus w/o
WebDAV.


Meh.


and read-write WebDAV has a host of security problems. There are
better solutions to supporting WebDAV than using the Tomcat
module.


Which are? Milton.io?


How about mod_dav and friends?


I was thinking about Java-based solution in Tomcat, at best with Spring 
to fully reuse my authnz code. I don't run HTTPd if it is not strictly 
necessary. Tomcat just performs perfectly well for dynamic, static and 
transport-encrypted content.



The only drawback I see with the current servlet is that I cannot
have arbitrary paths of my context served by this servlet. It
serves either the entire app or nothing. That's why I have resorted
to mod_dav.


Okay, so someone who really wants to make DAV work has decided that
Tomcat's implementation won't cut it. I fee that as further evidence
that Tomcat's implementation can just die.


As you might know, people will only complain when something is 
gone/broken and not when it is working well.



A recent search of the users mailing list shows only 10 threads
regarding WebDAV in the past 6 years.


Maybe people are just happy with the servlet?


People are super happy with the TLS implementation and ask about it
all the time.


Because encryption is complex...

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

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael

On 10/9/19 11:40, Michael Osipov wrote:
> Am 2019-10-07 um 16:39 schrieb Christopher Schultz:
>> -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 APR connector
>>
>> Justification:
>>
>> The APR connector was once used to provide superior I/O when
>> compared to the only other available I/O mechanism available in
>> Java: blocking I/O. Specifically, the APR connector allowed
>> Tomcat to wait for keepalive requests on a connection to in a
>> non-blocking fashion which was not possible with Java BIO-based
>> connectors.
>>
>> The introduction of NIO into Java back in Java 1.4 (!!) changed
>> things, and NIO support was added to Tomcat in 6.0. Now that it
>> has had time to mature, the NIO connector is superior to the APR
>> connector in several ways:
>>
>> 1. NIO connector allows non-blocking TLS handshakes 2. NIO
>> connector uses less (Tomcat-owned) native code
>>
>> The first item improves performance and availability and the
>> second item improves stability (and thus availability).
>>
>> The last advantage which (until recently) made the APR connector
>> still very useful was the ability to use the OpenSSL
>> cryptographic library for all cryptographic operations which is
>> measurably higher-performance than those typically provided by
>> the JVM.
>>
>> This last advantage no longer exists since we have a JSSE
>> provider available for OpenSSL using libtcnative.
>>
>> Notes:
>>
>> This proposal does not recommend the removal of libtcnative. Only
>> the removal of the APR connector, the APR lifecycle listener, and
>> the associated native code required to support those components.
>
> Though, I have no opion for or against. It has worked very well for
> me for the last 10+ years on HP-UX for our software.

I'd love to get your feedback on NIO+OpenSSL, then.

> Do we have any numbers comparing performance of both for different
> loads?

Yes. All of Jean-Frederic's presentations[1] for the last few years at
ApacheCon conferences all have slides showing the performance comparison
.

> Are there any drawbacks not using the APR connector?

The only drawback I see from using NIO+OpenSSL is that CPU usage goes
up a bit. The APR connector is apparently (slightly) more efficient in
terms of CPU, but everything else seems to be just about the same --
such as throughput.

> OpenSSL must stay, it always works very well.

Whether or works or not isn't the issue. It's how well is performs.
(Well... once it's working.) OpenSSL is a requirement because most
Java cryptographic providers perform terribly.

- -chris

[1] http://tomcat.apache.org/presentations.html
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2eN5YACgkQHPApP6U8
pFjeSw//fTDGf9WnsSHHlyM4hZTmJaeg2PodguITTSytOopcPGBDjqm9lL0U2c+C
YtmMZfSQ659IQrSfKajJqAGINTRvSe/PViAKKFMW38v7tObkGZrQG6bfEj8zcnXS
jH5P2IoijTCS7nC7bJmrYoWIMN50BElynMzQ9BMQEIk39sqtOuJ270bJNI9fqtw9
zeB4lnMUv9BXliLtWdKFBH1dUOHbBJLFg3oSri5EI6CVZvbgkBlVZwAsfifQKrQF
B5NwEgJEamXZX+g7opwbx/+ePrZ9Jm3d94I2C5RoAtooVhkdVz/EpfcqX+EoYhbd
Ku8O/UbIZTqZgYj6qPB9Ow06M23VRbRWI6YC2FtSIoumjjt9OJBRgJhL/1E4etjQ
Hl/Nl+mS2kG5EOIvIDWyvubdunhOXmtdJEaVqtMBNzaqKYNfSUlJVcx/AUs8asP4
O6ajSfOWDJW3DLkin+CDARKgFpQ0B773MyVJ2DjfU0/9eMwO85r2UuWUinabImJm
l4gF70DPymXz4mrA0eRyRjNFSHPA7lj+a1X/vyIyn1nNztCfpbpwZwQYY9u+lJaP
TdtHBxbKqyl6wxvQYHGPCwvbjEPlECHviUvz1RJq7Ynf9GjI8TYLVaWBMSaE4mck
pXuB4KTznLW34XJ+ov3Mmyq2WeWWp+A4vnYNPL82oHPyfbU6vYE=
=sE0J
-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 WebDAV

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 10/9/19 11:36, Michael Osipov wrote:
> Am 2019-10-07 um 16:54 schrieb Christopher Schultz:
>> -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 WebDAV
>>
>> Justification:
>>
>> WebDAV is a protocol that never really took off[2].
>
> From where do you take this? We, at work, use it all the time.
> Either from Sharepoint, or a new project with mod_dav.

Just because you use it doesn't mean it's widely-used. We use it at
$work as well, and it's a giant pain in the neck for anyone using a
Windows operating system. Linux and MacOS are totally fine, but we
have to buy a separate product to get Windows clients working
properly, and it's not super reliable.

> Another great example is mod_dav_svn. You can access you repo with
> any DAV client (except crappy Windows Explorer).

Or, since svn is HTTP, you can just use plain-old HTTP. Besides,
mod_dav_svn doesn't work with Tomcat.

>> Read-only WebDAV can practically be replaced by standard HTTP GET
>>
>
> No, it can't. you can't list collections with multistatus w/o
> WebDAV.

Meh.

>> and read-write WebDAV has a host of security problems. There are
>> better solutions to supporting WebDAV than using the Tomcat
>> module.
>
> Which are? Milton.io?

How about mod_dav and friends?

> The only drawback I see with the current servlet is that I cannot
> have arbitrary paths of my context served by this servlet. It
> serves either the entire app or nothing. That's why I have resorted
> to mod_dav.

Okay, so someone who really wants to make DAV work has decided that
Tomcat's implementation won't cut it. I fee that as further evidence
that Tomcat's implementation can just die.

>> A recent search of the users mailing list shows only 10 threads
>> regarding WebDAV in the past 6 years.
>
> Maybe people are just happy with the servlet?

People are super happy with the TLS implementation and ask about it
all the time.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2eNo4ACgkQHPApP6U8
pFgeow/+LzA+bwZtlK4r3cNZ5NQIlhfErzp5/EF+IcvfuRgrZKC0seLc9I0B9/GD
U9FkzcyCebTaEjK4zUQKpzI8pgJUgkGj8v+EbStZSSNASrL9rZra0Lkzbqm6nXgQ
33tHE0+pqRnny9j4Ysye1L+q2m1qyTg+cVoz5h7vN2ybXsJXeT7aQklOSj5b7yJx
464s2/wF8dfhY0U6uDIHg3ixK0378kptixfbQMuB/fHMoHkQRNznfayvjAoRiTGn
EfeD+w4HsS9r46JdmnB5OMIPjPcbSuCI4OuSLzkEaiYvdcgN5F4CZMQdua3MJWaB
P8g0dkhC3FzLf/LoXfOa9GmjUuer+TuaFKPLjTKCHF1SBhQx4ZXcMjsVX4zQkvS3
JDXemUUF6eOo/doj360AQeV8B/FBzePd33R2rhSB12FG19vrSgIjlALdTg1E0H4S
JeMuq7PBY44uWWJaEAMAg/LghWCyc3RICZi58htydUO/fnF4LA90kNz8RlSQ18Wg
iozFCeCQCQdbd6MuOqe+irU1+kAPvyezEd2YIU/S5TjD17PqE/6cZgEPzZRUrFc7
Z+JB6kBsGNJ9fVXMYqx4VBLx5lcaIy942fft5UiNqMsPaUT686R68Oj1WKJGbMgF
d0h93S14V8d02H+H9SFkV1oP2KOvILRhs3fJTFZLXZ/kU2CBBYU=
=f/+q
-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: Drop APR Connector

[Michael Osipov]

Am 2019-10-07 um 16:39 schrieb Christopher Schultz:

-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 APR connector

Justification:

The APR connector was once used to provide superior I/O when compared
to the only other available I/O mechanism available in Java: blocking
I/O. Specifically, the APR connector allowed Tomcat to wait for
keepalive requests on a connection to in a non-blocking fashion which
was not possible with Java BIO-based connectors.

The introduction of NIO into Java back in Java 1.4 (!!) changed
things, and NIO support was added to Tomcat in 6.0. Now that it has
had time to mature, the NIO connector is superior to the APR connector
in several ways:

1. NIO connector allows non-blocking TLS handshakes
2. NIO connector uses less (Tomcat-owned) native code

The first item improves performance and availability and the second
item improves stability (and thus availability).

The last advantage which (until recently) made the APR connector still
very useful was the ability to use the OpenSSL cryptographic library
for all cryptographic operations which is measurably
higher-performance than those typically provided by the JVM.

This last advantage no longer exists since we have a JSSE provider
available for OpenSSL using libtcnative.

Notes:

This proposal does not recommend the removal of libtcnative. Only the
removal of the APR connector, the APR lifecycle listener, and the
associated native code required to support those components.


Though, I have no opion for or against. It has worked very well for me 
for the last 10+ years on HP-UX for our software.


Do we have any numbers comparing performance of both for different 
loads? Are there any drawbacks not using the APR connector?


OpenSSL must stay, it always works very well.

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 WebDAV

[Michael Osipov]

Am 2019-10-07 um 16:54 schrieb Christopher Schultz:

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

Justification:

WebDAV is a protocol that never really took off[2].


From where do you take this? We, at work, use it all the time. Either 
from Sharepoint, or a new project with mod_dav.


Another great example is mod_dav_svn. You can access you repo with any 
DAV client (except crappy Windows Explorer).



Read-only WebDAV
can practically be replaced by standard HTTP GET 


No, it can't. you can't list collections with multistatus w/o WebDAV.


and read-write WebDAV
has a host of security problems. There are better solutions to
supporting WebDAV than using the Tomcat module.


Which are? Milton.io?

The only drawback I see with the current servlet is that I cannot have 
arbitrary paths of my context served by this servlet. It serves either 
the entire app or nothing. That's why I have resorted to mod_dav.



A recent search of the users mailing list shows only 10 threads
regarding WebDAV in the past 6 years.


Maybe people are just happy with the servlet?

Michael

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

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

[Rainer Jung]

Am 07.10.2019 um 16:39 schrieb Christopher Schultz:

-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 APR connector


+1 and +1 to the additional comments by Mark and Remy


Justification:

The APR connector was once used to provide superior I/O when compared
to the only other available I/O mechanism available in Java: blocking
I/O. Specifically, the APR connector allowed Tomcat to wait for
keepalive requests on a connection to in a non-blocking fashion which
was not possible with Java BIO-based connectors.

The introduction of NIO into Java back in Java 1.4 (!!) changed
things, and NIO support was added to Tomcat in 6.0. Now that it has
had time to mature, the NIO connector is superior to the APR connector
in several ways:

1. NIO connector allows non-blocking TLS handshakes
2. NIO connector uses less (Tomcat-owned) native code

The first item improves performance and availability and the second
item improves stability (and thus availability).

The last advantage which (until recently) made the APR connector still
very useful was the ability to use the OpenSSL cryptographic library
for all cryptographic operations which is measurably
higher-performance than those typically provided by the JVM.

This last advantage no longer exists since we have a JSSE provider
available for OpenSSL using libtcnative.

Notes:

This proposal does not recommend the removal of libtcnative. Only the
removal of the APR connector, the APR lifecycle listener, and the
associated native code required to support those components.

- -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 CGI Servlet

[Rainer Jung]

Am 07.10.2019 um 18:37 schrieb Igal Sapir:

On 10/7/2019 8:14 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/7/19 11:10, Mark Thomas 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 CGI Servlet

-1. Not a veto, just a -1.

Fair enough. I didn't think I'd get 100% agreement. If anyone feels
like this is is something worth keeping around, I'm happy to let the
proposal drop.


Is it possible to extract these removals (including the other proposals 
in this question) to an external repo in case someone wants to add them 
manually to his/her own deployment?


That way if anyone depends on any of the removed items they can still 
add them.


+1 it would be great if that would be feasible.

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)

[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: Drop APR Connector

[Rémy Maucherat]

On Mon, Oct 7, 2019 at 4:59 PM Mark Thomas  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 APR connector
>
> +1
>
> > This proposal does not recommend the removal of libtcnative. Only the
> > removal of the APR connector, the APR lifecycle listener, and the
> > associated native code required to support those components.
>
> Yes, we'd need to keep that library going until at least 9.0.x is EOL.
>
> There is then an argument for a new native library that simply wraps
> OpenSSL (or ideally any OpenSSL clone). Project Panama may prove useful:
> https://openjdk.java.net/projects/panama/


Fun fact: Graal has a more radical way to replace JNI for accesses to
native libraries.
It looks like this:
https://cornerwings.github.io/2018/07/graal-native-methods/
So let's forget it, but still fun though.

Rémy

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

[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)

[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 CGI Servlet

[Igal Sapir]

On 10/7/2019 8:14 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/7/19 11:10, Mark Thomas 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 CGI Servlet

-1. Not a veto, just a -1.

Fair enough. I didn't think I'd get 100% agreement. If anyone feels
like this is is something worth keeping around, I'm happy to let the
proposal drop.


Is it possible to extract these removals (including the other proposals 
in this question) to an external repo in case someone wants to add them 
manually to his/her own deployment?


That way if anyone depends on any of the removed items they can still 
add them.


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)

[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: Drop APR Connector

[Rémy Maucherat]

On Mon, Oct 7, 2019 at 4:39 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 APR connector
>
> Justification:
>
> The APR connector was once used to provide superior I/O when compared
> to the only other available I/O mechanism available in Java: blocking
> I/O. Specifically, the APR connector allowed Tomcat to wait for
> keepalive requests on a connection to in a non-blocking fashion which
> was not possible with Java BIO-based connectors.
>
> The introduction of NIO into Java back in Java 1.4 (!!) changed
> things, and NIO support was added to Tomcat in 6.0. Now that it has
>

But it really didn't work then.


> had time to mature, the NIO connector is superior to the APR connector
> in several ways:
>
> 1. NIO connector allows non-blocking TLS handshakes
> 2. NIO connector uses less (Tomcat-owned) native code
>
> The first item improves performance and availability and the second
> item improves stability (and thus availability).
>

I agree the OpenSSL native code used alone inside an OpenSSLContext is much
easier to make crash proof than the network code as a whole in the APR
connector.


>
> The last advantage which (until recently) made the APR connector still
> very useful was the ability to use the OpenSSL cryptographic library
> for all cryptographic operations which is measurably
> higher-performance than those typically provided by the JVM.
>
> This last advantage no longer exists since we have a JSSE provider
> available for OpenSSL using libtcnative.
>
> Notes:
>
> This proposal does not recommend the removal of libtcnative. Only the
> removal of the APR connector, the APR lifecycle listener, and the
> associated native code required to support those components.
>

The APR lifecycle listener is not part of the APR connector, it initializes
the libraries and sets config defaults based on that.

Anyway, +1 to attempt the APR connector removal.

Rémy


>
> - -chris
>
>
> [1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
> at
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bTg8ACgkQHPApP6U8
> pFghUhAAwXEdrarxE5sgqMbZxswlOrRTQSIGZuh2t9KV8pJG+M8NrRbPMZxL3IX/
> UkJA9JGxFGA20D9kn0Xx2eX276tKtW/ZyVhg9vvlKqm8+n+vXLuN/sj15sPw1f64
> rCqj/GA+iMPP1AtBwc3E2bxBUI7WYGjgMutobwWOfHrlrw6/D4aNyO/t8XXlh9UT
> ZcP9Nq0ed4G4I+zx+R//FmEa0Ky2ARUtiyuBhnA+yEFm0XT/iMpgGnl5DHpJ5nOv
> U9YiTOU/bMXP1ABgCYoPgHPnYADKoEepdhD8x7CZTyUpR4vTr7DXxAABvapwynBo
> sPb+CFjlQilS8zxNYbGZbCu/mpux88jKYvOrrf5Jjb8YzxAGmmy00VyzuyzApdLs
> T9eYJazcej8u0he26U+QJi+HCQ+KpdSeMP/kQuw2BorvdD5BkPA22MvqoeIdU1Xs
> IzS6+69/MwjkTSL3YOlxp/E7HuG/gegGYBgVphVVJVAYh5lyBcY9o5diTIwdbejU
> yK+3WBbkK9dp8nM0GmKoaUqhLP/XvACG5FohW6P+EHLTjlCy7dPbr7s409coQb/1
> JQqur4GABbM47MXSDaXHisXLSLY3RpF6Uo0Fb2AC2AuuAihjNpQ0GmeuLHhoPI7W
> CycCLjMqLystoj8pNR1pil1FOgI1zOPilylpMX0mV5VuDhPxuFw=
> =MZ7V
> -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)

[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 WebDAV

[Rémy Maucherat]

On Mon, Oct 7, 2019 at 5:05 PM Mark Thomas  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 WebDAV
> >
> > Justification:
> >
> > WebDAV is a protocol that never really took off[2]. Read-only WebDAV
> > can practically be replaced by standard HTTP GET and read-write WebDAV
> > has a host of security problems. There are better solutions to
> > supporting WebDAV than using the Tomcat module.
> >
> > A recent search of the users mailing list shows only 10 threads
> > regarding WebDAV in the past 6 years.
>
> I'm not so sure on this one. There are times when being able to set up a
> platform independent read/write file share can be useful. Generally,
> inside trusted environments.
>

I'd also think WebDAV support can stay.
If the protocol wasn't a bigger success it's IMO all Microsoft's fault,
since they insist(ed) on having non compliant impls. So using it in
practice has always been harder for users. It should have been better
overall since WebDAV (and extensions) are HTTP and benefit from all the
security layers and ease of use there.

Rémy


>
> 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 CGI Servlet

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/7/19 11:10, Mark Thomas 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 CGI Servlet
>
> -1. Not a veto, just a -1.

Fair enough. I didn't think I'd get 100% agreement. If anyone feels
like this is is something worth keeping around, I'm happy to let the
proposal drop.

>> Justification:
>>
>> The CGIServlet is another component, like server-side-includes,
>> which is a remote-code execution (RCE) vulnerability as a
>> feature. It is very easy to misconfigure. It is arguably not
>> possible to secure it on Windows[2].
>
> I disagree. That is an edge case.
>
>> There are better solutions if you want to run Perl, Python, PHP,
>> or whatever on your server in the form of the many fine
>> web-server products out there.
>
> Yes, but that isn't the only use of CGI. It is essentially, a
> fairly easy way to integrate any executable into a web application.
> My sense that this use remains sufficiently widespread that we
> should not discontinue it.
>
> Maybe a topic for discussion on users@ ?

Sure.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bVmsACgkQHPApP6U8
pFhpGQ/+PWCpG7pJGeVHULrwDHMy3VkOc4OIcnt17gfcm5IXL9ZVDquaWc8dsCBb
iB5XNZ458RYwi7ewwQ3xI7il+Utnij8zFCHWaOSlPqbfb2VYrkSUD7/esJTqufhO
B3Sonkw6hTSov4+/GgdQTee0hN6rmuu2MrLpL0lU0xcz9wITDGbb16S4weBpDynW
cXCcQHYgT4nGvzayevhHqyiiMom0aC/O/ZwwkWgZf/JWb9SSw0P1b2dTulBbranL
DkGdYt+m5WaawZ40GVwh6sYT3dVlGkTebKEG5PFSJY36NbDJ1tIUKxCGeUOXyyCg
Qqrk42VdxjvXWZ+GmuFJegACExIlxiH8miM1RG2qaN75Irt+mEygvsX3GcG2uIwQ
HXcQpbf4uPJEBZ/Q954b2yXkvrn/0QHXhVsFVq+aTc6C6wmFRk53djgblHduOnBw
QPD3/Q5Eeh2btu67sSnAoFkAhr0/y11Kfc5iSdRqcLa4qdcG+U8TEshpoavX10az
9BOsELcutJ/EPWiXttd0IFn5Bt+zKIlIURRuXQGbxTYm6v69XvUz95Leb+qg/2+f
50kXRyqHmIU9/6Kxzv2FZZEIEnVnEg6pSYkTRXyG7y2Z4GNHvp7vnkXuwPDbdZK9
dw3rW223KpuxvXuoCHc+zzelcKm3ejiOCBBXBxhchswNwUxvzjo=
=qU2J
-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 CGI Servlet

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Coty,

On 10/7/19 11:02, Coty Sutherland wrote:
> On Mon, Oct 7, 2019 at 11:00 AM Christopher Schultz
>  <mailto:ch...@christopherschultz.net>>
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 CGI Servlet
>
>
>> +1
>
>
>
> Justification:
>
> The CGIServlet is another component, like server-side-includes,
> which is a remote-code execution (RCE) vulnerability as a feature.
> It is very easy to misconfigure. It is arguably not possible to
> secure it on Windows[2]. There are better solutions if you want to
> run Perl, Python, PHP, or whatever on your server in the form of
> the many fine web-server products out there.
>
>
>> I thought this was a really weird feature for Tomcat to provide
>> anyway :)

I think there was a lot of "me-too-ism" happening back in the day. I
get it: why use two separate servers when one will do the trick?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bVfwACgkQHPApP6U8
pFjA/RAAyW7nluFxfWFmQAKazbpGwjgBIM8LCxrVtWfVDzaXpEWdkP259P9HdO+m
TmFAOFYzlw4pstR73AhcQk/pLxF8mWYzU0Fi+uaPCDEDJ3OsJjKuGNRu3o51OMjF
j7+666hxS3VmfkiFqejhPClaFB3QPHzA0YopMdjPGyAJJ7eQExXZXdUVbSQeh+v3
1Ka/57Sm0wdRRHpdd2N22jh3NDKR/laC8gnqzbnr5WealN+Yeb9ECIg6c6ooD2cy
fo5SGAsllzMWdNWtckAPZ+Op7S96mdro6Komyp5VNgOLGd4kILA4e3KfbVyYBBAj
HEyY5st6BHIhqtbjRou+/9e0Z94sZU7Wa7JSDo/tdc9bWeoBYSfewTRDBKp7yREV
tHsHOMDAW88MveP6Eu/daxV+ZUhY/s6u/UHnfHsgYcdvnDHj7IFki80qRZpH7h19
LjHX6h1EnS79p8+lszY7bA/XFfOw+f4T5VjnvyAr/ospU9GVdE7SnUEI2lzejn1/
PUoTlWEhTH4BJ5+l5BtKxXriuyckfULSDLKckIoMyGe6+JrXHEbfc40aO6hsnZVq
2jYvTydaHPGOaINZahrs1m9eGa6upduHVo0rtwN1eBLDa339o072jKG1yP81xYUN
xql1LOjEqhcsUtxUfvZr/uDYOxivuqGJwfsHzNv+1XUGeY334to=
=2JSs
-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 CGI Servlet

[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 CGI Servlet

-1. Not a veto, just a -1.

> Justification:
> 
> The CGIServlet is another component, like server-side-includes, which
> is a remote-code execution (RCE) vulnerability as a feature. It is
> very easy to misconfigure. It is arguably not possible to secure it on
> Windows[2].

I disagree. That is an edge case.

> There are better solutions if you want to run Perl,
> Python, PHP, or whatever on your server in the form of the many fine
> web-server products out there.

Yes, but that isn't the only use of CGI. It is essentially, a fairly
easy way to integrate any executable into a web application. My sense
that this use remains sufficiently widespread that we should not
discontinue it.

Maybe a topic for discussion on users@ ?

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 WebDAV

[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 WebDAV
> 
> Justification:
> 
> WebDAV is a protocol that never really took off[2]. Read-only WebDAV
> can practically be replaced by standard HTTP GET and read-write WebDAV
> has a host of security problems. There are better solutions to
> supporting WebDAV than using the Tomcat module.
> 
> A recent search of the users mailing list shows only 10 threads
> regarding WebDAV in the past 6 years.

I'm not so sure on this one. There are times when being able to set up a
platform independent read/write file share can be useful. Generally,
inside trusted environments.

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 CGI Servlet

[Coty Sutherland]

On Mon, Oct 7, 2019 at 11:00 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 CGI Servlet
>

+1


>
> Justification:
>
> The CGIServlet is another component, like server-side-includes, which
> is a remote-code execution (RCE) vulnerability as a feature. It is
> very easy to misconfigure. It is arguably not possible to secure it on
> Windows[2]. There are better solutions if you want to run Perl,
> Python, PHP, or whatever on your server in the form of the many fine
> web-server products out there.
>

I thought this was a really weird feature for Tomcat to provide anyway :)


>
> - -chris
>
>
> [1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
> at
> [2]
> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23
> /everyone-quotes-command-line-arguments-the-wrong-way/
> <https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/>
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bUusACgkQHPApP6U8
> pFhGxw//V8a5sALHVJAGDuhYf3HJs+MyDkHI848BOW8U5JjSOC9erQg84xxOm11q
> ywHqmdJ1HkVCTlN6n+OMne4/DVtAywqetF6hVf3TdGvA/Xp2HGiz4H9FeBgD5oVS
> WgZqrShBk5xneElWkBH69yG7qC2XKhCZNtA8bNqMdUQ+zOW2Gwhk8k35r//jWivX
> ZkXloVRs2aQaArtqwIi0kWWMMbIEL6JJJigAfjfpap8HvTrLL/W5/dTpYUp1Y1Ms
> qGhv0CcbDSFmQqPEnZO0keaUJRi5QXsW7ByMnXjterr1ExEW8ZfHM7ZOAap/7VWz
> O2TFeq59YSG2KOrueDpzZk1u1l0G5vT9ttyoGtGJQlFt6TnxA0+4EouciFoVtPM8
> mrAEHkp9MSHIVGjTj6qanNnEkue3Bnyv5TQq2m5MX6mYCkyGUhZpdaIfK2aw6M2Y
> uJ4h8Qf1hX0s3/nfyF3ERTKnsB2aYcVORjcfLaEajJwbUAXRG4kLKqOszMsLKV3S
> FC/rzp1f7MSKf4nN9WVIQvxUZhxP70SjBSTtRN3UXZvrZvCiq/BaK0/inyYTKOIc
> 1QOjbfoZnI3Kcm8zKKODJRebpsrsF+f7EWwuEg07lAmgAxQGsdciss23rt6OALf0
> Dhr5Lb6mcMktmy4JLIKwbM9Hbk3IslbQlEWQEOSiagzph/ZMVP8=
> =28Zt
> -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)

[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

[PROPOSAL] Tomcat 10: Remove CGI Servlet

[Christopher Schultz]

-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 CGI Servlet

Justification:

The CGIServlet is another component, like server-side-includes, which
is a remote-code execution (RCE) vulnerability as a feature. It is
very easy to misconfigure. It is arguably not possible to secure it on
Windows[2]. There are better solutions if you want to run Perl,
Python, PHP, or whatever on your server in the form of the many fine
web-server products out there.

- -chris


[1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
at
[2]
https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23
/everyone-quotes-command-line-arguments-the-wrong-way/
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bUusACgkQHPApP6U8
pFhGxw//V8a5sALHVJAGDuhYf3HJs+MyDkHI848BOW8U5JjSOC9erQg84xxOm11q
ywHqmdJ1HkVCTlN6n+OMne4/DVtAywqetF6hVf3TdGvA/Xp2HGiz4H9FeBgD5oVS
WgZqrShBk5xneElWkBH69yG7qC2XKhCZNtA8bNqMdUQ+zOW2Gwhk8k35r//jWivX
ZkXloVRs2aQaArtqwIi0kWWMMbIEL6JJJigAfjfpap8HvTrLL/W5/dTpYUp1Y1Ms
qGhv0CcbDSFmQqPEnZO0keaUJRi5QXsW7ByMnXjterr1ExEW8ZfHM7ZOAap/7VWz
O2TFeq59YSG2KOrueDpzZk1u1l0G5vT9ttyoGtGJQlFt6TnxA0+4EouciFoVtPM8
mrAEHkp9MSHIVGjTj6qanNnEkue3Bnyv5TQq2m5MX6mYCkyGUhZpdaIfK2aw6M2Y
uJ4h8Qf1hX0s3/nfyF3ERTKnsB2aYcVORjcfLaEajJwbUAXRG4kLKqOszMsLKV3S
FC/rzp1f7MSKf4nN9WVIQvxUZhxP70SjBSTtRN3UXZvrZvCiq/BaK0/inyYTKOIc
1QOjbfoZnI3Kcm8zKKODJRebpsrsF+f7EWwuEg07lAmgAxQGsdciss23rt6OALf0
Dhr5Lb6mcMktmy4JLIKwbM9Hbk3IslbQlEWQEOSiagzph/ZMVP8=
=28Zt
-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: Drop APR Connector

[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 APR connector

+1

> This proposal does not recommend the removal of libtcnative. Only the
> removal of the APR connector, the APR lifecycle listener, and the
> associated native code required to support those components.

Yes, we'd need to keep that library going until at least 9.0.x is EOL.

There is then an argument for a new native library that simply wraps
OpenSSL (or ideally any OpenSSL clone). Project Panama may prove useful:
https://openjdk.java.net/projects/panama/

Mark

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

Re: [PROPOSAL] Tomcat 10: Drop APR Connector

[Coty Sutherland]

On Mon, Oct 7, 2019 at 10:39 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 APR connector
>

I'm +1 for this


>
> Justification:
>
> The APR connector was once used to provide superior I/O when compared
> to the only other available I/O mechanism available in Java: blocking
> I/O. Specifically, the APR connector allowed Tomcat to wait for
> keepalive requests on a connection to in a non-blocking fashion which
> was not possible with Java BIO-based connectors.
>
> The introduction of NIO into Java back in Java 1.4 (!!) changed
> things, and NIO support was added to Tomcat in 6.0. Now that it has
> had time to mature, the NIO connector is superior to the APR connector
> in several ways:
>
> 1. NIO connector allows non-blocking TLS handshakes
> 2. NIO connector uses less (Tomcat-owned) native code
>
> The first item improves performance and availability and the second
> item improves stability (and thus availability).
>
> The last advantage which (until recently) made the APR connector still
> very useful was the ability to use the OpenSSL cryptographic library
> for all cryptographic operations which is measurably
> higher-performance than those typically provided by the JVM.
>
> This last advantage no longer exists since we have a JSSE provider
> available for OpenSSL using libtcnative.
>
> Notes:
>
> This proposal does not recommend the removal of libtcnative. Only the
> removal of the APR connector, the APR lifecycle listener, and the
> associated native code required to support those components.
>
> - -chris
>
>
> [1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
> at
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bTg8ACgkQHPApP6U8
> pFghUhAAwXEdrarxE5sgqMbZxswlOrRTQSIGZuh2t9KV8pJG+M8NrRbPMZxL3IX/
> UkJA9JGxFGA20D9kn0Xx2eX276tKtW/ZyVhg9vvlKqm8+n+vXLuN/sj15sPw1f64
> rCqj/GA+iMPP1AtBwc3E2bxBUI7WYGjgMutobwWOfHrlrw6/D4aNyO/t8XXlh9UT
> ZcP9Nq0ed4G4I+zx+R//FmEa0Ky2ARUtiyuBhnA+yEFm0XT/iMpgGnl5DHpJ5nOv
> U9YiTOU/bMXP1ABgCYoPgHPnYADKoEepdhD8x7CZTyUpR4vTr7DXxAABvapwynBo
> sPb+CFjlQilS8zxNYbGZbCu/mpux88jKYvOrrf5Jjb8YzxAGmmy00VyzuyzApdLs
> T9eYJazcej8u0he26U+QJi+HCQ+KpdSeMP/kQuw2BorvdD5BkPA22MvqoeIdU1Xs
> IzS6+69/MwjkTSL3YOlxp/E7HuG/gegGYBgVphVVJVAYh5lyBcY9o5diTIwdbejU
> yK+3WBbkK9dp8nM0GmKoaUqhLP/XvACG5FohW6P+EHLTjlCy7dPbr7s409coQb/1
> JQqur4GABbM47MXSDaXHisXLSLY3RpF6Uo0Fb2AC2AuuAihjNpQ0GmeuLHhoPI7W
> CycCLjMqLystoj8pNR1pil1FOgI1zOPilylpMX0mV5VuDhPxuFw=
> =MZ7V
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[PROPOSAL] Tomcat 10: Remove WebDAV

[Christopher Schultz]

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

Justification:

WebDAV is a protocol that never really took off[2]. Read-only WebDAV
can practically be replaced by standard HTTP GET and read-write WebDAV
has a host of security problems. There are better solutions to
supporting WebDAV than using the Tomcat module.

A recent search of the users mailing list shows only 10 threads
regarding WebDAV in the past 6 years.

- -chris


[1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
at
[2] And yet I love WebDAV very much and wish it has better support on
Windows

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bUaYACgkQHPApP6U8
pFgpvw//fpgWZWxg+c0PsXqQK/Vyw5EBDxjq4ulXVxpO2MMI7On2iP7DaUUfCIPR
bd1ijbOEjydIHeD2Gu4hj+I9as2/avTjkVlzi3fhWsLypHWJ9x0vw+M9elJBapTY
+FtMj1e4U2QPvf98lDyaBMoSHCDIBZbGq0E5AlDVwjgCgJmxzT1FNQJI90gGwtiw
PYsLaNuMZc2gwzgyQ3978kL4zwFG3gWVSexNfiI2g3GEvpUhfh7fitskxwN8rILU
l/HJCJ6HiCRoISWwIPE/m+yAFzaYcWtcBaQzx5IiiJTG1LLSiLO79M6Sj6bnYDSG
UxEfjmbgbklV0HAlnHfjA85sfLw/mPayumcaTwxMdB5VAMe45UaAF16G4vtReuaA
zlU6TVQ/5L0W4+eB30jfKNOVMnUde2iHNRIqOXDsvUV5f7Hp553ehxT+584RPVKP
Kk9CW+wwPCgJkB/gVsopM9SElhzoYcmeNB1h5zKBsBcafQzmkzGAonS3qdYdMo2u
FjVjrUVWocntuqUc5e37mm0KbzrWQstQBjmISOzAJc8ikYOghPZSgskuKEzMp3Sz
KLkyEaLluR5Jd9N89M8Ivp0xJixLYyQJ5LlmWGnTTiH8i36LilhL9FXlQZKPdV7r
irl/hJDrHu7VzQQtAet+AZAUBhdnE/zqtyoDV1pKXQjYHrFIF40=
=pQ5N
-END PGP SIGNATURE-

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

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

[Christopher Schultz]

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

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

[PROPOSAL] Tomcat 10: Drop APR Connector

[Christopher Schultz]

-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 APR connector

Justification:

The APR connector was once used to provide superior I/O when compared
to the only other available I/O mechanism available in Java: blocking
I/O. Specifically, the APR connector allowed Tomcat to wait for
keepalive requests on a connection to in a non-blocking fashion which
was not possible with Java BIO-based connectors.

The introduction of NIO into Java back in Java 1.4 (!!) changed
things, and NIO support was added to Tomcat in 6.0. Now that it has
had time to mature, the NIO connector is superior to the APR connector
in several ways:

1. NIO connector allows non-blocking TLS handshakes
2. NIO connector uses less (Tomcat-owned) native code

The first item improves performance and availability and the second
item improves stability (and thus availability).

The last advantage which (until recently) made the APR connector still
very useful was the ability to use the OpenSSL cryptographic library
for all cryptographic operations which is measurably
higher-performance than those typically provided by the JVM.

This last advantage no longer exists since we have a JSSE provider
available for OpenSSL using libtcnative.

Notes:

This proposal does not recommend the removal of libtcnative. Only the
removal of the APR connector, the APR lifecycle listener, and the
associated native code required to support those components.

- -chris


[1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
at
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bTg8ACgkQHPApP6U8
pFghUhAAwXEdrarxE5sgqMbZxswlOrRTQSIGZuh2t9KV8pJG+M8NrRbPMZxL3IX/
UkJA9JGxFGA20D9kn0Xx2eX276tKtW/ZyVhg9vvlKqm8+n+vXLuN/sj15sPw1f64
rCqj/GA+iMPP1AtBwc3E2bxBUI7WYGjgMutobwWOfHrlrw6/D4aNyO/t8XXlh9UT
ZcP9Nq0ed4G4I+zx+R//FmEa0Ky2ARUtiyuBhnA+yEFm0XT/iMpgGnl5DHpJ5nOv
U9YiTOU/bMXP1ABgCYoPgHPnYADKoEepdhD8x7CZTyUpR4vTr7DXxAABvapwynBo
sPb+CFjlQilS8zxNYbGZbCu/mpux88jKYvOrrf5Jjb8YzxAGmmy00VyzuyzApdLs
T9eYJazcej8u0he26U+QJi+HCQ+KpdSeMP/kQuw2BorvdD5BkPA22MvqoeIdU1Xs
IzS6+69/MwjkTSL3YOlxp/E7HuG/gegGYBgVphVVJVAYh5lyBcY9o5diTIwdbejU
yK+3WBbkK9dp8nM0GmKoaUqhLP/XvACG5FohW6P+EHLTjlCy7dPbr7s409coQb/1
JQqur4GABbM47MXSDaXHisXLSLY3RpF6Uo0Fb2AC2AuuAihjNpQ0GmeuLHhoPI7W
CycCLjMqLystoj8pNR1pil1FOgI1zOPilylpMX0mV5VuDhPxuFw=
=MZ7V
-END PGP SIGNATURE-

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

Re: Proposal: use Files.move instead of File.renameTo in FarmWarDeployer

[Mark Thomas]

On 06/08/2019 21:05, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> All,
> 
> Someone recently had a problem where the FarmWarDeployer wouldn't work
> on a secondary node because File.renameTo was failing -- likely due to
> the underlying Java/OS refusing to re-name a file across filesystems.
> 
> I propose that we switch to using Files.move which will either re-name
> or move depending upon what is necessary. It also throws an exception
> if it can't do its work, rather than failing and returning false.
> 
> Code patch below. I would also remove all of the
> "farmWarDeployer.renameFail" error message keys from the resource bundle
> s.

+1. Might be worth a wider review of where else File.renameTo() is used.

This is Java 7 so it can also be back-ported to 8.5.x.

Mark


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