Michael,
On 6/7/24 10:18, Michael Osipov wrote:
On 2024/06/07 12:54:44 Christopher Schultz wrote:
Michael,
On 6/7/24 08:01, Michael Osipov wrote:
On 2024/06/07 08:05:34 Mark Thomas wrote:
On 06/06/2024 16:30, Christopher Schultz wrote:
All,
Resurrecting this thread from 2019.
I'd like to
On Thu, Jun 6, 2024 at 4:46 PM Christopher Schultz
wrote:
>
> All,
>
> I'd like to remove the around the SecureLifecycleListener
> in conf/server.xml that we bundle with Tomcat distributions.
>
> Before I do so, are there any objections to making this change?
+1
Having something commented out in
On Thu, Jun 6, 2024 at 4:44 PM Christopher Schultz
wrote:
>
> All,
>
> I'd like to change the existing webapps/ROOT/index.jsp to index.html and
> remove the dynamic elements. Currently, the only truly dynamic element
> in the whole file is this:
>
> "
> Copyright ©1999-${year} Apache Software
> Fo
t; 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 recent
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
> f
On Fri, Jun 7, 2024 at 10:33 AM Tim Funk wrote:
> Somewhat related and tangential to the other conversations
>
> Is it worth introducing a system property like
> "-Dtomcat.security.harden=true". (Personally not sold yet on the idea)
>
I think I'm +0 on this. Implementing something like this
Somewhat related and tangential to the other conversations
Is it worth introducing a system property like
"-Dtomcat.security.harden=true". (Personally not sold yet on the idea)
Then when set to true ...
- It can go nuts with additional SecureLifecycleListener checks
- It can disable all OOTB
On 2024/06/07 12:54:44 Christopher Schultz wrote:
> Michael,
>
> On 6/7/24 08:01, Michael Osipov wrote:
> > On 2024/06/07 08:05:34 Mark Thomas wrote:
> >> On 06/06/2024 16:30, Christopher Schultz wrote:
> >>> All,
> >>>
> >>> Resurrecting this thread from 2019.
> >>>
> >>> I'd like to remove the
My 2c.
I think a new static page could easily make it clear what happened without
too much discomfort.
"Welcome to the NEW Apache Tomcat static landing page (replace this webapp
with your own... the old one, if deployed, is probably [here](/quickstart))"
etc. etc.
I would think that in a large
Am 6. Juni 2024 17:26:27 MESZ schrieb Konstantin Kolinko
:
>чт, 6 июн. 2024 г. в 17:44, Christopher Schultz :
>>
>> All,
>>
>> I'd like to change the existing webapps/ROOT/index.jsp to index.html and
>> remove the dynamic elements. Currently, the only truly dynamic element
>> in the whole file
On Fri, Jun 7, 2024 at 8:52 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Konstantin,
>
> On 6/6/24 11:26, Konstantin Kolinko wrote:
> > чт, 6 июн. 2024 г. в 17:44, Christopher Schultz <
> ch...@christopherschultz.net>:
> >>
> >> All,
> >>
> >> I'd like to change the existing web
Michael,
On 6/7/24 08:01, Michael Osipov wrote:
On 2024/06/07 08:05:34 Mark Thomas wrote:
On 06/06/2024 16:30, Christopher Schultz wrote:
All,
Resurrecting this thread from 2019.
I'd like to remove the SSI configuration from conf/web.xml and put it
into webapps/docs/ssi-howto.html.
Are ther
Konstantin,
On 6/6/24 11:26, Konstantin Kolinko wrote:
чт, 6 июн. 2024 г. в 17:44, Christopher Schultz :
All,
I'd like to change the existing webapps/ROOT/index.jsp to index.html and
remove the dynamic elements. Currently, the only truly dynamic element
in the whole file is this:
"
Copyright
Coty,
On 6/6/24 11:34, Coty Sutherland wrote:
On Thu, Jun 6, 2024 at 10:46 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:
All,
I'd like to remove the around the SecureLifecycleListener
in conf/server.xml that we bundle with Tomcat distributions.
Before I do so, are there any
Konstantin,
On 6/6/24 12:01, Konstantin Kolinko wrote:
чт, 6 июн. 2024 г. в 17:46, Christopher Schultz :
All,
I'd like to remove the around the SecureLifecycleListener
in conf/server.xml that we bundle with Tomcat distributions.
Before I do so, are there any objections to making this change
On 2024/06/07 08:05:34 Mark Thomas wrote:
> On 06/06/2024 16:30, Christopher Schultz wrote:
> > All,
> >
> > Resurrecting this thread from 2019.
> >
> > I'd like to remove the SSI configuration from conf/web.xml and put it
> > into webapps/docs/ssi-howto.html.
> >
> > Are there any objections?
On 06/06/2024 18:13, Konstantin Kolinko wrote:
чт, 6 июн. 2024 г. в 17:49, Christopher Schultz :
All,
Tomcat's SecurityLifecycleListener currently checks the current working
user's name, the umask and not much else at the moment.
I'd like to add "administrator" as another username to look for
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 serv
On 06/06/2024 16:30, Christopher Schultz wrote:
All,
Resurrecting this thread from 2019.
I'd like to remove the SSI configuration from conf/web.xml and put it
into webapps/docs/ssi-howto.html.
Are there any objections?
None here.
Do we want to go further and consider removing it entirely
чт, 6 июн. 2024 г. в 17:49, Christopher Schultz :
>
> All,
>
> Tomcat's SecurityLifecycleListener currently checks the current working
> user's name, the umask and not much else at the moment.
>
> I'd like to add "administrator" as another username to look for. (The
> documentation says that "root"
чт, 6 июн. 2024 г. в 17:46, Christopher Schultz :
>
> All,
>
> I'd like to remove the around the SecureLifecycleListener
> in conf/server.xml that we bundle with Tomcat distributions.
>
> Before I do so, are there any objections to making this change?
Its name is "SecurityListener",
org.apache.ca
On Thu, Jun 6, 2024 at 10:46 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> All,
>
> I'd like to remove the around the SecureLifecycleListener
> in conf/server.xml that we bundle with Tomcat distributions.
>
> Before I do so, are there any objections to making this change?
>
No
чт, 6 июн. 2024 г. в 17:44, Christopher Schultz :
>
> All,
>
> I'd like to change the existing webapps/ROOT/index.jsp to index.html and
> remove the dynamic elements. Currently, the only truly dynamic element
> in the whole file is this:
>
> "
> Copyright ©1999-${year} Apache Software
> Foundation.
All,
Tomcat's SecurityLifecycleListener currently checks the current working
user's name, the umask and not much else at the moment.
I'd like to add "administrator" as another username to look for. (The
documentation says that "root" is the only current username checked.)
I would also like
All,
I'd like to remove the around the SecureLifecycleListener
in conf/server.xml that we bundle with Tomcat distributions.
Before I do so, are there any objections to making this change?
Thanks,
-chris
-
To unsubscribe, e-
All,
I'd like to change the existing webapps/ROOT/index.jsp to index.html and
remove the dynamic elements. Currently, the only truly dynamic element
in the whole file is this:
"
Copyright ©1999-${year} Apache Software
Foundation. All Rights Reserved
"
I don't see any particular reason tha
me 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 (R
All,
Resurrecting this thread from 2019.
I'd like to remove the SSI configuration from conf/web.xml and put it
into webapps/docs/ssi-howto.html.
Are there any objections?
Thanks,
-chris
On 10/29/19 05:05, Konstantin Kolinko wrote:
пн, 28 окт. 2019 г. в 16:34, Christopher Schultz :
[...]
tions 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
e 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
let spec for
> removal in a future version.
>
> Any objections to this proposal?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@to
rrent 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?
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 don
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 di
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. Thi
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. Ea
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 w
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 s
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
>
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.
T
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
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 "glu
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 actual
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 fr
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
1
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
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" r
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 no
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.o
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 e
EnabledProtocols 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 sslEnabledProtocol
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 nu
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 (using
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) {
re
ontinuing 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
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
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
-
e:
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 d
>> 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
end 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 "sa
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
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
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 thes
+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
-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 appl
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
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.
Every
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 o
+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 thes
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 thes
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
t; > 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
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 "
-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,
>>> i
t;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 lik
e-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
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
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
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.j
-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
>> to
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.
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
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
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
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 w
-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, PKCS
-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
>
> Ther
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
irr
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 con
t; 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 r
пн, 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 comme
-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
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
-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 "packag
ver 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" p
oing 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
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
arp 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 S
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
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 pla
1 - 100 of 762 matches
Mail list logo
