Re: [VOTE][RESULT?] Release Apache Tomcat 8.5.60

2020-11-18 Thread Christopher Schultz

Mark,

If it's important, you didn't:

1. Start a new thread
2. Change the subject to [VOTE][RESULT]

-chris

On 11/17/20 15:30, Mark Thomas wrote:

The following votes were cast:

Binding:
+1: markt, mgrigorov, remm, isapir

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

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: Removing JDBC mode from JDBCStore

2020-11-09 Thread Christopher Schultz

Rémy,

On 11/9/20 08:45, Rémy Maucherat wrote:

Hi,

As part of https://github.com/apache/tomcat/pull/376 and along with
the similar removal of JDBCRealm, I would like to propose: - Remove
JDBC code from JDBCStore in Tomcat 10, in favor of DataSource code;
this allows simplifying and removing global sync which obviously 
kills scalability - Rename JDBCStore to DataSourceStore in Tomcat 10 
- Introduce a new empty DataSourceStore store extending JDBCStore in

Tomcat 7.0.x, 8.5.x and 9.0.x to help migration, and adjust
documentation to refer to it

Comments ?


+1 to all that

-chris

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



Re: Working around a JRE bug

2020-11-06 Thread Christopher Schultz

Mark,

On 11/5/20 14:59, Mark Thomas wrote:

Woot!

The great folks at bnd have fixed this. It means depending on a snapshot
but compared to the disruption of the alternatives I think that is
acceptable for the short term.

The issue with depending on a snapshot is reproducibility of builds. The
simplest option (and infra seem OK with it) is to put a copy in my home
dir on home.a.o.


Sounds good to me.

Oh, and ship a beer or two to the kind folks at bnd who jumped to fix 
this within ... 4 hours?


How does this affect Maven builds?

-chris


On 05/11/2020 12:57, Mark Thomas wrote:

All,

The summary:

- The JVM spec states that the ModulePackages attribute in
   module-info.class DOES NOT have to list ALL packages in the module
- bnd is consistent with the JVM spec and only lists the packages that
   are required to be listed
- the JRE uses a broken class loader optimisation that assumes that
   ModulePackages DOES list ALL packages present in the module

When applications try and use our JARs with bnd provided module-info
CNFE occur because the JRE can't find the module for some classes.

For a fuller description of the issue see:
https://bugs.openjdk.java.net/browse/JDK-8255854

This is likely the cause of several currently open bugs reports of CNFE
when using modules.


Possible solutions:

1. OpenJDK accepts the class loader optimisation is flawed and reverts
it.
Given the reaction so far to the reported bug this looks unlikely.
Even if this were to happen, class loading performance would be
impacted and it is going to take a long time before all the broken
JREs have been updated.

2. The bnd project updates bnd to implement what amounts to an
undocumented requirement that the ModulePackages attribute lists all
packages in the module.
This is probably the cleanest solution but depends on the goodwill of
the bnd project who would be well within their rights to reject it as
invalid based on the JVM spec. I haven't yet approached the bnd
project. A fix along these lines might be ready for the next release
round but is unlikely to be ready for this one.

3. We drop all the JPMS meta-data until we have a solution.
I'm not sure of the consequences for users wanting to use Tomcat JARs
in a JPMS environment.

4. We "patch" module-info after bnd has generated it via:
- custom code (BCEL probably helps)
- jar (if using Java 9+ jar rebuilds the module-info.class file)

5. We add "unnecessary" @aQute.bnd.annotation.jpms.Open annotations to
packages so bnd includes them in module-info.
It might be hard to remove these at a later date if folks start to
depend on them.


I am currently thinking along these lines:

- Add @aQute.bnd.annotation.jpms.Open where necessary to fix this.
- Document clearly in the Javadoc, change log, the release announcement
   and the RELEASE NOTES that this is a temporary workaround that will be
   removed as soon as a better fix is available.
- Ask the bnd project to make a change to list all packages in a module
   in the ModulePackages attribute.

Thoughts?

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



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



Re: [PROPOSAL]

2020-10-30 Thread 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]

2020-10-30 Thread 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



[PROPOSAL]

2020-10-30 Thread 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: Some test observations for TC 7

2020-10-28 Thread Christopher Schultz

Rainer,

I recently had some weirdness with TLS connections as well. Please see 
my post titled "SSLException after Java upgrade".


"Recently", Java moved certain EC curves to the attic and won't 
handshake properly anymore.


Another investigation of my own product running into a network exception 
that hadn't been generated before. It looks like a change to the JRE.


https://bugs.openjdk.java.net/browse/JDK-8215102

This was initially reported as an error with MySQL connections but it 
appears that the driver's involvement was unnecessary. Please see 
Severin Gehwolf's comments from 2019-01-25.


I'm not sure if either of these issues are related to yours, but I 
wanted to make suer you were aware of them.


Hope that helps,
-chris

On 10/28/20 08:09, Rainer Jung wrote:

Hi all,

I tested TC 7.0.106 plus a few patches from git with a variety of JVMs 
on a few Linux distributions. I observed:


- org.apache.tomcat.util.net.TestClientCertTls13 now fails for Java 
1.8.0_272 be it OpenJDK, Adopt or Zulu on all Linux distros I tested. 
TLSv1.3 was backported to Java 8 in the recently released Patchlevel 272 
and is enabled on the server side by default, but not on the client 
side. The test succeeds as soon as I add 
"-Djdk.tls.client.protocols=TLSv1.3". I guess correct TLS1.3 detection 
during test gets moire and more complicated ...


- Only on RHEL 8 (e.g. not RHEL 6 or 7) and only with Red Hat provided 
Java 1.8.0 and 11 (but not for other distributions of Java 1.8.0 or 11), 
lots of TLS tests fail. For example TestSsl test testSimpleSsl show the 
following when started with -Djavax.net.debug=all und Red Hat Java 11:


     [junit] Oct 28, 2020 12:55:26 PM org.apache.coyote.AbstractProtocol 
start
     [junit] INFO: Starting ProtocolHandler 
["http-bio-127.0.0.1-auto-1-43799"]
     [junit] javax.net.ssl|DEBUG|03|Finalizer|2020-10-28 12:55:26.265 
CET|SSLSocketImpl.java:473|duplex close of SSLSocket
     [junit] javax.net.ssl|WARNING|03|Finalizer|2020-10-28 12:55:26.273 
CET|SSLSocketImpl.java:494|SSLSocket duplex close failed (

     [junit] "throwable" : {
     [junit]   java.net.SocketException: Socket is not connected
     [junit] at 
java.base/java.net.Socket.shutdownOutput(Socket.java:1553)
     [junit] at 
java.base/sun.security.ssl.BaseSSLSocketImpl.shutdownOutput(BaseSSLSocketImpl.java:232) 

     [junit] at 
java.base/sun.security.ssl.SSLSocketImpl.duplexCloseOutput(SSLSocketImpl.java:561) 

     [junit] at 
java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:479)
     [junit] at 
java.base/sun.security.ssl.BaseSSLSocketImpl.finalize(BaseSSLSocketImpl.java:275) 

     [junit] at 
java.base/java.lang.System$2.invokeFinalize(System.java:2117)
     [junit] at 
java.base/java.lang.ref.Finalizer.runFinalizer(Finalizer.java:87)
     [junit] at 
java.base/java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:171)}

     [junit]
     [junit] )
     [junit] javax.net.ssl|ERROR|01|main|2020-10-28 12:55:26.304 
CET|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Couldn't 
kickstart handshaking (

     [junit] "throwable" : {
     [junit]   javax.net.ssl.SSLHandshakeException: No appropriate 
protocol (protocol is disabled or cipher suites are inappropriate)
     [junit] at 
java.base/sun.security.ssl.HandshakeContext.(HandshakeContext.java:163) 

     [junit] at 
java.base/sun.security.ssl.ClientHandshakeContext.(ClientHandshakeContext.java:95) 

     [junit] at 
java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:217) 

     [junit] at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:395) 

     [junit] at 
java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) 

     [junit] at 
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) 

     [junit] at 
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:163) 

     [junit] at 
org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:665) 

     [junit] at 
org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:639) 

     [junit] at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:633)
     [junit] at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:627)
     [junit] at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:612)
     [junit] at 
org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:606)
     [junit] at 
org.apache.tomcat.util.net.TestSsl.testSimpleSsl(TestSsl.java:60)


Dont know whether the error in the finalizer really is the root cause 
and it might well be a JDK error, but I at least wanted to provide the 
info here.


Best regards,

Rainer

-
To 

Re: svn/git for website

2020-10-27 Thread Christopher Schultz

Konstantin,

On 10/26/20 20:47, Konstantin Kolinko wrote:

пт, 2 окт. 2020 г. в 00:09, Mark Thomas :


Hi all,

The topic came up at the BoF session at the end of the Tomcat track of
migrating the website from svn to git. There were strong opinions both
for migrating and for sticking with svn.

As a middle ground I'd like to propose we ask Infra to create a git
mirror of the svn repo.

For those who favour git:
The git mirror would be read-only but it would be possible to:
- clone the git mirror
- make changes in git
- use git-svn to commit those changes back to svn
- then the mirror automatically replicates them back to git

For those who favour svn there would be no change.

If there is agreement on this approach, I volunteer to contact infra to
get it set up.


My proposal at BoF was for a partial mirror.

The issue is that

1. I think that this mirror is intended as a tool to collect feedback
/ patches from random people, and to lower barriers for contribution.

2. The full Tomcat site is large. It includes documentation for all
versions of Tomcat, including javadocs. Those pages are changed rarely
and are not needed for people who contribute small changes for the
site. The source code for those pages is elsewhere.


The question I have to ask, here is: why do we bother putting all those 
files in revision-control? The users guide for 4 different versions of 
Tomcat is not a problem, but the javadocs are just stupid to store.


Is there some policy we are following by having all those files in 
there? Or is it just to make sure that website "publication" is as 
simple as "svn checkout"?



3. Subversion has easy commands to cope with such large source trees.
This feature is called "sparse checkouts".

For our site the necessary commands are documented in README.txt.
Essentially, it is done with --depth and --set-depth arguments to "svn
checkout" and "svn update" commands

Speaking about Git, there are huge repositories [1] out there, but I
think that the majority of people are not accustomed to them.

[1] https://en.wikipedia.org/wiki/Monorepo

I see that Git developers recently did some work to make dealing with
such repositories simpler, with addition of "git sparse-checkout"
command in Git 2.25.0 [2], released in January 2020.

[2] https://github.com/git/git/blob/v2.25.0/Documentation/RelNotes/2.25.0.txt

Though I think that support in tools is still lacking. E.g. missing in
TortoiseGit. [3]

[3] https://gitlab.com/tortoisegit/tortoisegit/issues/1599


If we go with a full Git mirror or with migration to Git, then I think
that somebody has to prepare an update to README.txt.

If we go with a partial Git mirror, I think it could be named
"tomcat-site-dev", reserving the name "tomcat-site" for a full mirror
if we ever make one.


Ignored paths for git-svn are configured with "--ignore-paths"
argument or with "svn-remote..ignore-paths" configuration
option. [4]

[4] https://git-scm.com/docs/git-svn


Other notes:

4. Release managers use Subversion to publish the binaries.

Thus I expect that they are able to update the published documentation
with Subversion as well.

5. Publishing the javadocs generates small changes over a large number
of files. The script that generates the commit email notes that the
diff is huge and trims it all to a small summary.

If we ever migrate to Git, I wonder whether a similar script in Git is
able to cope with it.


We might also want to consider complicating the website-building process 
in order to simplify the repository. Yes, "disk space is cheap" but it's 
kind of ridiculous that we have all that derivative content in RCS, 
separate from its canonical source.


-chris

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



Re: [tomcat] branch master updated: Use SVG logo for a more modern and consistent look

2020-10-15 Thread Christopher Schultz
Igal,

On 10/10/20 16:08, isa...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> isapir pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 466d1a5  Use SVG logo for a more modern and consistent look
> 466d1a5 is described below
> 
> commit 466d1a5a281973e8a12721f0fe4b4c72cc4fa07d
> Author: Igal Sapir 
> AuthorDate: Sat Oct 10 13:07:56 2020 -0700
> 
> Use SVG logo for a more modern and consistent look
> 
> Also removed unused images and obsolete CSS styles
> ---
>  webapps/ROOT/index.jsp|   3 +--
>  webapps/ROOT/tomcat-power.gif | Bin 2376 -> 0 bytes
>  webapps/ROOT/tomcat.css   |   9 ++---
>  webapps/ROOT/tomcat.gif   | Bin 2066 -> 0 bytes
>  webapps/ROOT/tomcat.png   | Bin 5103 -> 0 bytes
>  5 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/webapps/ROOT/index.jsp b/webapps/ROOT/index.jsp
> index 1d3d46d..5149594 100644
> --- a/webapps/ROOT/index.jsp
> +++ b/webapps/ROOT/index.jsp
> @@ -28,7 +28,6 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
>  
>  <%=request.getServletContext().getServerInfo() %>
>  
> -
>  
>  
>  
> @@ -52,7 +51,7 @@ request.setAttribute("tomcatExamplesUrl", "/examples/");
>  If you're seeing this, you've successfully installed 
> Tomcat. Congratulations!
>  
>  
> -
> +

If you want a bealt, suspenders, and girdle apprroach to make sure this
works on NCSA Mosaic, you can do this:


  
  


I'm not sure of a spec-compliant way to specify the "alt text" for a
.

-chris

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



Re: TCK status

2020-10-08 Thread Christopher Schultz
Mark,

On 10/3/20 14:39, Mark Thomas wrote:
> Hi all,
> 
> I mentioned TCK status during a couple of ApacheCon presentations.
> Having checked the current status I thought it would be worth sending a
> brief note to the list. More detail is on the wiki:
> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
> 
> The short version is:
> 
> - EL: all tests pass
> - JSP: all tests pass (once the TCK regression is fixed)
> - WebSocket: all tests pass
> - Servlet: one failure (expected)
> 
> So, all good. No issues.
> 
> Mark
> 
> P.S. If you are wondering the servlet failure is because Tomcat ignores
> any suggested context path in web.xml and will ALWAYS derive the context
> path from the file name to avoid ambiguities and conflicts.

I can't for the life of me find a reference to how you "suggest" the
context path in web.xml. Is this using the appCxtRoot env-entry? I
thought that was vendor-specific...

-chris

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



Re: Removing the APR connector

2020-09-29 Thread Christopher Schultz
Rémy,

On 9/29/20 07:57, Rémy Maucherat wrote:
> On Tue, Sep 29, 2020 at 1:32 PM Mark Thomas  wrote:
> 
>> All,
>>
>> Removing the APR connector (HTTP and AJP) is currently on the TODO list
>> for Tomcat 10.0.x (i.e. the current development branch).
>>
>> I am wondering whether we are still happy with this plan as we have had
>> a few 10.0.x milestone releases and we haven't made any efforts to
>> remove the APR connector.
>>
>> I'm happy to remove APR from 10.0.x but I am equally happy postponing
>> this to a later release if necessary.
>>
>> We'd still need Tomcat Native support to enable the use of OpenSSL with
>> NIO and NIO2. I am only thinking of removing the APR based HTTP and AJP
>> connectors (with associated plumbing) and possibly some of the
>> org.apache.tomcat.jni package.
>>
>> Thoughts?
> 
> I would rather postpone at this point, with the idea of really removing it
> in 10.1.

I don't know how popular the APR connector is. There are probably lots
of users who use it because "it's the fastest" and they haven't changed
since 2005.

I also don't know how many users are actually using NIO+OpenSSL. APR is
well-known to be reliable and has good performance. I think the
NIO+OpenSSL is less popularly deployed. Is it "too fast" to remove it in
10.0?

> Maybe we should remove it from the docs in 10.0 in preparation for the move
> ?

I wouldn't remove it from the docs, but maybe very clearly advertise
that it's being removed.

-chris

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



Re: CATALINA_BASE vs CATALINA_HOME: What must be where?

2020-09-28 Thread Christopher Schultz
Konstantin,

On 9/27/20 14:33, Konstantin Kolinko wrote:
> сб, 26 сент. 2020 г. в 18:12, Christopher Schultz
> :
>>
>> All,
>>
>> I'm writing about the above topic for ApacheCon @ Home and I wanted to
>> get some confirmation about a few statements. The code is ... large and
>> complex and it will be easier to just ask for help from those who Know.
>>
>> "
>> Many files in CATALINA_BASE are optional
>> * Override those in CATALINA_HOME
>>  - conf/context.xml
> 
> I think you are wrong with the above one. By design it has to be in
> CATALINA_BASE, it cannot be in CATALINA_HOME.
> E.g.
> - org.a.c.startup.HostConfig.addGlobalRedeployResources() assumes that
> the file is in CATALINA_BASE.
> - org.a.c.startup.CatalinaBaseConfigurationSource#getResources() loads
> a file from catalinaBase.

My CATALINA_BASE deployments never include a conf/context.xml file. So
either it's never required or it's only required if the application
doesn't supply one.

>> * Some files are required in CATALINA_BASE
>>  - conf/server.xml
>>  - conf/catalina.policy
>>  - conf/web.xml
> 
> catalina.policy is not needed if you are not running with a
> SecurotyManager enabled.

Ack.

>> Some Exceptions may be Surprising
>> * Only in CATALINA_HOME
>>  - bin/setclasspath.sh
> .
> That is some helper script that should not be customized.
> 
> When people modify that file it usually means that they have not read
> the documentation and do not know about setenv.sh.

I agree, but it's worth pointing out (a) it must be in HOME and (b) you
shouldn't be changing it.

>>  - endorsed/ (special Java libraries)
> 
> The path to endorsed directory is settable in setenv.sh. The directory
> can be anywhere. I have experience of running several Tomcat 7
> instances where only some of them had an endorsed directory. And I am
> sure that you know that it is a technology that does not work with
> modern versions of Java.

Agreed. I'm talking about a "stock" Tomcat: where will tomcat look for
things unless you override them. Assuming you already know how to
override them, then you don't need to know where their defaults are :)

>>  - bin/bootstrap.jar
>> "
>>
>> Is this all correct?
>>
>> Am I missing anything?
> 
> There may be some "last resort" defaults, e.g. I see that a copy of
> catalina.properties is present in catalina.jar. I also see that
> CatalinaBaseConfigurationSource#getResources() tries to load a
> resource from a ClassLoader, but it would be odd to put configuration
> there.
> 
> From the docs I know that a system property "catalina.config" may be
> used to override the path to the "catalina.properties" file, but I
> personally have not used that feature and do not know whether it is
> useful. As documentation for that property is improved in Tomcat 10 vs
> Tomcat 7, I think there was some discussion.
> 
> http://tomcat.apache.org/tomcat-10.0-doc/config/systemprops.html#Other
> http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Other
> 
> I know that path to server.xml may be specified at the command line.
> See o.a.startup.Catalina#arguments() for "-config".
> I have not tested whether it works, and I do not see "-config" being
> documented in RUNNING.txt or elsewhere in the docs.

Ack.

Thanks for the review.

-chris

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



CATALINA_BASE vs CATALINA_HOME: What must be where?

2020-09-26 Thread Christopher Schultz
All,

I'm writing about the above topic for ApacheCon @ Home and I wanted to
get some confirmation about a few statements. The code is ... large and
complex and it will be easier to just ask for help from those who Know.

"
Many files in CATALINA_BASE are optional
* Override those in CATALINA_HOME
 - conf/context.xml
* Some files are required in CATALINA_BASE
 - conf/server.xml
 - conf/catalina.policy
 - conf/web.xml

Some Exceptions may be Surprising
* Only in CATALINA_HOME
 - bin/setclasspath.sh
 - endorsed/ (special Java libraries)
 - bin/bootstrap.jar
"

Is this all correct?

Am I missing anything?

Thanks!
-chris

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



Application-accesible Executors

2020-09-18 Thread Christopher Schultz
All,

I've recently been thinking about application uses of servlet-async and
Websocket for long-running operations, or really for any interactions
where you want to allow the request-processing thread to go back into
the pool, but the application is still doing useful things and therefore
needs its own thread.

I'm thinking of something like SwingUtilities.invokeLater, though that
does something very specific that is AWT-related, of course.

I don't believe there is a (JavaEE/JakartaEE) standard for this, so I'm
interested in what others think might be a good idea from a Tomcat
standpoint.


It's fairly easy to do something like this in one's own web application,
maybe using a ServletContextListener:

public class ExecutorProvider
  implements ServletContextListener
{
  public static final EXECUTOR_SERVICE_KEY = "executor-service";

  private ExecutorService _svc;

  public void contextInitialized(ServletContext ctx) {
_svc = Executors.newFixedThreadPool(10); // ?

ctx.setAttribute(EXECUTOR_SERVICE_KEY, _svc);
  }

  public void contextDestroyed(ServletContext ctx) {
ctx.removeAttribute(EXECUTOR_SERVICE_KEY);
_svc.shutdown();
  }
}

Then in a servlet, etc. you could:

((ExecutorService)ctx.getAttribute(ExecutorProvider.EXECUTOR_SERVICE_KEY)).submit(new
Runnable() {
public void run() {
// your code goes here
}
});

I'm wondering if there is scope here for Tomcat to provide this kind of
service for applications that want to opt-into one. Maybe the above is
so trivial as to not be worth it at all. But maybe it would be a nice
service to provide to web applications, or maybe across multiple web
applications in some kind of group. Or it might survive context restarts
for some reason.

Having this provided by Tomcat would allow admins to maybe override the
sizes of the thread pools and other details that the application then
wouldn't need to worry about.

It might even tie-into Tomcat's utility-executor if that makes any sense
0-- though we'd have to make sure it executes in the right ClassLoader
and/or security context.

Any thoughts on this? Or is it really such a trivial thing as to not
really be useful to anyone. Maybe simply providing a
ServletContextListener class like the one above (with obvious robustness
improvements) that anyone could configure for their own application
would be sufficient/useful to users.

-chris

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



Request for documentation improvement: changelog UI

2020-09-09 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Could someone better at CSS look into this for me?

I sometimes find myself searching the changelog for some string e.g.
"keystore". I generally do that by loading-up the changelog in my
browser and using the browser's "Find" feature to search the text. (Duh)
.

The changelog for each version, however, usually stretches to a few
screen-heights and it's often not possible to see the version number
where a particular changelog item is included. I often have to find
something, then scroll "up" to see the version number.

This isn't a big deal when locating something specific: it generally
occurs once (like a bug id) and then you go look at the version number
and you are done.

But when trying to find something that happened between versions X and
Y, there is a great deal of scrolling, searching, re-scrolling,
re-searching, etc. which may be avoided if the following is possible.
(And I'm sure it is).

What I'd like is for the  headings on the changelog pages to
"stick" to the top of the screen as they are scrolled. So, for
example, if you load the changelog for Tomcat 9, you'll see at the
very top of the page there is the standard Tomcat documentation header
("Tomcat", current version number, latest release-date), then the
"Changelog" header, then the first  which is currently "Tomcat
9.0.37 (markt)".

As you scroll, the "Tomcat 9.0.37 (markt)" eventually scrolls up off
the top of the visible page (as web pages generally do). Instead, when
that heading gets to the top of the page, I'd like it to "stick" there
until scrolling replaces it with the next  in the order, which is
currently "Tomcat 9.0.36 (markt)".

This would keep the version number where fixes/improvements have been
made at the top of the screen during any searching activity and make
it much easier to hunt for certain kinds of fixes.

Is anyone willing to look into implementing the above?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9Y17oACgkQHPApP6U8
pFjN0xAAhfFd0Yl69XF38f5tSYtMQMQcDNIOywVDXCIBWnYaSIUPWvzFAPeq0uv/
t7Hvc2MlQ+QlKfu3aiq0PEOpCRy2QEQ9EDDGEonxRPvhQrkhUIDlkuGpTvYrS1XA
RF7XSUuV+g9eVyFeh1KQEQP1BCAKXjxXLNl51v6xHP+FMiySAtAgCF7U3DVbB/fw
rXILy6/wgSjdWyQkcC+yZ/5OHxp9R3s8E80MT0Kdwp7oTtdlCq0bFOdcmqQZqC92
9658bGQhllYfF7eqMeWRVO8TdlIyAI0RFJU8gVlt9IGWy5OHzc6QB853O4ejA8G0
xrjeKVwzWYBNUImkfxxqXoOSdK8/rKK/zEZtBi7GuHeYLiqn8JBvFS4NZGp0rMNY
xWYAf0Nhql+y+gDDbpk10CplptNePCUXjF6fSX7IPSsgpBwyjDbGl671s08DOM83
TJq5NwwjJS37kPmHY7g0DRdhtn0dKf45H97Kdpqm/BEp8Vua63eEtK8WFFXmOVBd
hhEADE8ccQg639U5jxshI9F3wxnChNcfOSKDcdxmCU0Rgfslq3ujgqzZ2sqCHNVP
9SwJiolW76PUFLG02LasM1FYzPSYv85a/0DH5lPGUMpB3EvczCnu5FWagsTS3fu5
8JCHz7Eyo1SrijeMtE/NgSV0LpKbuGjh8v+BUBODiW+jD8vfxxI=
=4+RB
-END PGP SIGNATURE-

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



Re: [VOTE][RESULT][OT] Release Apache Tomcat Native 1.2.25

2020-09-03 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/3/20 10:34, Mark Thomas wrote:
> The following votes were cast:
>
> Binding: +1: markt, mgrigorov, fschumacher
>
> +0: schultz
>
> The vote therefore passes.
>
> I think it is worth noting that there were crashes / unit test
> failures reported with LibreSSL. This isn't unexpected. There is
> more work to do for LibreSSL support.

In fact, if someone in the community is motivated to look into
improving LibreSSL support, I'm sure their contributions will be
accepted and likely result in an invitation to become a committer.

Most of us are Java devs who can also write C code, but nobody would
hire most of us to write C code.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9RO8gACgkQHPApP6U8
pFhXQRAAqaOWZZF75cFVxAzHYQ3O0cLJco68LCxi7M8eDZ8MERwP2MoVkRP8ZCbV
gryTOT9bqZfyal0K/AXdglNbuDGp/jWsP+0GveBQ5ILl4E0EuB8uxcLbfpOT+Fx9
9KXEy7Cx81amseA3pXm/kRgCc7TN621RRYMFjqJFAC6og+DtmPcRYfWcx7hvG1gC
BDjDawhmzWwL4NHiaASgI9aKjODdfhbQO3dR8cUWd+C+dZyWkNRBKL48RXFDJnIl
il2AhBbXLNHYjBQdosDg1Cqj5Rdoxen7YnYym0GNmcIfP4ddzw5YSiiVDwliOAl3
QTTNL/ul77O1XiWNFKWtpOdtbmpDt8jE2IDuxLQzfcksGkyba0c1iU6yJiMFBOPj
gM0L7z9oPHRwwnP+8gP+v52nN/duQ2vN3sPLtX6zKE3ilynqQDbMaCMFJBMA7L2z
vdDoSvyZ7uxaUmt0+eAhd2/g15ID3w92wehuE8JG6krU3uyFvpJhYm4rtpmFWdfn
UmO3W/1NuY9JcOK4x7tQumdpPz1hTxMq0k//rMArVCpKdqDqMkjH2lnWCjv4tv+L
R/hwqfUFyouhdsQiqIt0N1qygFMOZlnGoO20MtquQmsO61bNQbg97NHyq/hMCa7R
HMlkRmDnJSyZIGo08Lt5TxfmbZrxK6KKv9xyUDrn2kZ+suAQIj8=
=z0/h
-END PGP SIGNATURE-

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



Re: [VOTE] Release Apache Tomcat Native 1.2.25

2020-09-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/21/20 14:22, Mark Thomas wrote:
> Version 1.2.25 includes the following changes compared to 1.2.24
>
> - Improvements to LibreSSL support
>
> - Improvements to HP_UX support
>
> Various other fixes and improvements. See the changelog for
> details.
>
> The proposed release artefacts can be found at [1], and the build
> was done using tag [2].
>
> The Apache Tomcat Native 1.2.25 release is [ ] Stable, go ahead and
> release [ ] Broken because of ...

Thanks for rm'ing.

All signatures match.
Compiles without issue (gcc 6.3.0, OpenSSL 1.1.0l (+Debian), APR 1.5.2).

I wasn't able to perform any actual testing; this is a +0 vote for
compile-test success only.

Looks like no unit-tests. "make check" fails immediately; looks like
it wasn't really expected to work :shrug:

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9QSeoACgkQHPApP6U8
pFhenw//R3zSula9q4uPUw+AXm/untLbXme7nVkC0K9yrZVQusvRJaU2AafEhBC2
9RxgfsOnR71VbUWBCezYjfphDMIQBgtgccr2fRYX+GTEUN3vTsSxF1RASpiOuIIN
eZGtLUukpiP8UdOPrPHEPlfE1XI13YwJ7RhSuNvqgSAb2MAx+72ssBpigywTBs13
9Y1AZ7UjdvvfcN7TuE24fX4mh6ltfZc/gYL13X/UW5GijVilM5l4932eKAvOFBhn
mQuKx/nmdTuV6zNZ7RQcaV6Af2QL3eRn1uxjCQmPHzBl77TD5kSf/nXa7DTTJmrv
8+O50mT2uznF5Op1Eb3StHsW/dhMI2ZHDVk15xU6jcLmxEluBAFLMdAPhb6k9Hvz
Drt8C3SrpcQmdx3SFdtXxdznpaCOnyrUXv/YXhnoALOy6jmKz7ZnpFzOhc27DoIV
zLFoQ6SpDPy0R6emqkDsKgkF/gLbgnpDh6chyLoUU6L54BGX24cVoaTF52Ucwhfl
Nk4/KpiZopCiVKkIK4IJvJP92AIIRfRY1B8y8LEohZ6tm2VshHA9dT4mhnB1bsLc
N8ORq44eghgZz3TjgGT1UVXS+KP4W0hWeLw0rwBD1B+bBdN4A2Li392/yXcz3Ugb
8IiSWqHh0L3JuRdHSsxw1eY+LhAE6m23OxIMLJOu/eyS3I+I2Z8=
=AKkE
-END PGP SIGNATURE-

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



Re: security.txt

2020-09-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/1/20 14:38, Mark Thomas wrote:
> On 01/09/2020 18:01, Christopher Schultz wrote:
>> All,
>>
>> I'd like to propose that we publish a security.txt[1] file on our
>> web site under /.well-known/security.txt and /security.txt
>>
>> This file contains information we all already know, but it's in
>> obviously "proprietary" locations on our web site and might not
>> easily be found by someone who maybe doesn't speak English, etc.
>>
>> Here's my proposed content:
>>
>> Contact: secur...@tomcat.apache.org Contact:
>> https://tomcat.apache.org/security.html#Reporting_New_Security_Proble
ms_
>>
>>
with_Apache_Tomcat
>> Acknowledgments: https://tomcat.apache.org/security.html
>> Preferred-Languages: en Canonical:
>> https://tomcat.apache.org/.well-known/security.txt Hiring:
>> https://tomcat.apache.org/getinvolved.html
>>
>> If there are no objections, I'll add it to the site repo, soon.
>
> +1
>
>> What's the best way to make sure that the same file ends up in
>> /.well-known/security.txt and /security.txt? Can git link them
>> together or something like that?
>
> The site is in svn.

Oh, right. I modify the site so rarely I forget it hasn't migrated to Gi
t.

> A rewrite rule?

Sure. Shall I put an .htaccess file into the site's repo, then, at the
top-level?

  RedirectPermanent /security.txt /.well-known/security.txt

?

Aah, there's already a top-level .htaccess file. I'll just add to that
one.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9QSTsACgkQHPApP6U8
pFiAGxAAhw/9IDGM7BbNCMGzhPkQwFrB8z+2rm25rmpJBYwYU/ZcnnIbky5Olz1x
83oygeQKTofmllEvZoAqyQEr3woFH2MZWL7/qluvCKhHpnxDBsYb6wYNX3pX9L1H
SXHb237GiUEbKYLpwYtjjxOWQwbjTCGNm7fHtSW2X0luyvzjHDZd38WsIBI+JvRS
KtYUwPTvzpRYWxzdx8feojUp+IUGrU6OUs39rYnbtNcgpZ7bpfmwFhH40K6BXjcb
AzW1bIYWpyA2AeQw0jGoXPvReDwn3iOR4aO/IUSdTTWuVD8Tw+ChFDcWkcqcYXq/
lYkA+p/ceM+qBzCXxQK/rvjmN5DQZ1y7P3sHJBRvqCp/lcmK/JNFfzo0+e0sR3Yc
ltSLqRKgdnvcNO8BRE1PJiz+b7S6Du8/OB66/byQduwacUUbz7pPxlNu1CkwKxh8
a5DGwiYnG5tAthbf512ASgWkFtU97et9JOwv0TXiTfVF9DVxw3Fp+6a1Akkh1+hZ
Ebsliwp0FcAb8K6lhdNjG7LJik5vQrqCfJ6tJchwpmsCqfMCXb1+dApv6fFlTP0a
Uf30XwzJkNX/uPqP1AAPFetUVBJScHwwNf5WH+/FtK1M15Ykj7hjPPNMFY1ej3Hp
fdWaiP3LfZV8gR8HM4V5MM8OPkIKc0mUWxVs1WDSA46e4+Cf4kU=
=aN45
-END PGP SIGNATURE-

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



security.txt

2020-09-01 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'd like to propose that we publish a security.txt[1] file on our web
site under /.well-known/security.txt and /security.txt

This file contains information we all already know, but it's in
obviously "proprietary" locations on our web site and might not easily
be found by someone who maybe doesn't speak English, etc.

Here's my proposed content:

Contact: secur...@tomcat.apache.org
Contact:
https://tomcat.apache.org/security.html#Reporting_New_Security_Problems_
with_Apache_Tomcat
Acknowledgments: https://tomcat.apache.org/security.html
Preferred-Languages: en
Canonical: https://tomcat.apache.org/.well-known/security.txt
Hiring: https://tomcat.apache.org/getinvolved.html

If there are no objections, I'll add it to the site repo, soon.

What's the best way to make sure that the same file ends up in
/.well-known/security.txt and /security.txt? Can git link them
together or something like that?

- -chris

[1] https://securitytxt.org/
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9OflcACgkQHPApP6U8
pFhy7g//bvd5hO/QTg+HJyJ1pRY4DCZUtssratL9iwoXNWmRz5toO6XM+Hj3Bh0U
4VOV5pMl+dN6DhSvuUSDXumnkF6RFMPYFjs15TvC5BaMbt7jlwfNtez7ByrVimOm
BX9KLsXHgjE04Z4nnqp0S+bXdig5bBTtDLPH9woQOOJfx+4LFyPPUMBaKVzxIh2h
3VAv1vkUCmwfqzY5jJKxERQBzhYwBzuxOe1dL+qtXZGs6R8++OltX5GH1qYks8PR
28A8SDp+YWrMEEMkv0vUIle3lmEpzEa3+hujFHhMjxPM3q80d9r1XR7B+T3SodEo
1udOfBMRG6MGU9OiFD+s8vYgVt2BBBSCTzoeuNQkkf2kbzpeFYChjv7mM4ghBSyy
6y8Cz5O8HHQwroaxrkbhf1iIlNDdV0zQ+vd1C3EmhiZosD/bWhIL9q0RFzkY5QIY
d4U2AN2Q6r9Wd12jS7ELjKy2q/BshJktEjdHs0HQUvYP26zOK9AVtH/ojFLmfXf8
E+8TxLX2Wr3e6VyaGOJayeofSeeWEs0a4kxzfTB1ChQ/tG/SBJACCYS12cCq1XIn
nKzkNm1ftbNDgH2IxSfvAPl1m9SzoSO3RJwibrV1bwstahtbvgALHP5raGzZ8Mxo
+piQmPr1YKwxcvQWE3X/aZOv2YryjnbXKCdHixieZu+rU4f7j6M=
=qHDh
-END PGP SIGNATURE-

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



Re: [tomcat] branch master updated: Change forcedRemainingCapacity from Integer to int

2020-08-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 8/27/20 07:55, mgrigo...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git
> repository.
>
> mgrigorov pushed a commit to branch master in repository
> https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this
> push: new 2cef8f1  Change forcedRemainingCapacity from Integer to
> int 2cef8f1 is described below
>
> commit 2cef8f18dee7b7bca3d03b3301fbe8e733e728fa Author: Martin
> Tzvetanov Grigorov  AuthorDate: Tue Aug 25
> 14:36:23 2020 +0300
>
> Change forcedRemainingCapacity from Integer to int
>
> No need to create object (or use Integer cache) and cast it to
> primitive int. 'forcedRemainingCapacity' can do its job with a
> primitive int, since Queue's capacity cannot be negative value ---
> java/org/apache/tomcat/util/threads/TaskQueue.java| 15
> ++-
> .../apache/tomcat/util/threads/ThreadPoolExecutor.java|  4
> ++-- 2 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/java/org/apache/tomcat/util/threads/TaskQueue.java
> b/java/org/apache/tomcat/util/threads/TaskQueue.java index
> 87c93a9..35f1d89 100644 ---
> a/java/org/apache/tomcat/util/threads/TaskQueue.java +++
> b/java/org/apache/tomcat/util/threads/TaskQueue.java @@ -35,12
> +35,13 @@ public class TaskQueue extends
> LinkedBlockingQueue { private static final long
> serialVersionUID = 1L; protected static final StringManager sm =
> StringManager .getManager("org.apache.tomcat.util.threads.res"); +
> private static final int DEFAULT_FORCED_REMAINING_CAPACITY = -1;
>
> private transient volatile ThreadPoolExecutor parent = null;
>
> // No need to be volatile. This is written and read in a single
> thread -// (when stopping a context and firing the  listeners)
> -private Integer forcedRemainingCapacity = null; +// (when
> stopping a context and firing the listeners) +private int
> forcedRemainingCapacity = -1;
>
> public TaskQueue() { super(); @@ -109,18 +110,22 @@ public class
> TaskQueue extends LinkedBlockingQueue {
>
> @Override public int remainingCapacity() { -if
> (forcedRemainingCapacity != null) { +if
> (forcedRemainingCapacity > DEFAULT_FORCED_REMAINING_CAPACITY) { //
> ThreadPoolExecutor.setCorePoolSize checks that //
> remainingCapacity==0 to allow to interrupt idle threads // I don't
> see why, but this hack allows to conform to this // "requirement" -
> return forcedRemainingCapacity.intValue(); +return
> forcedRemainingCapacity; } return super.remainingCapacity(); }
>
> -public void setForcedRemainingCapacity(Integer
> forcedRemainingCapacity) { +public void
> setForcedRemainingCapacity(int forcedRemainingCapacity) {
> this.forcedRemainingCapacity = forcedRemainingCapacity; }

Technically, this could cause a problem for anyone who has binaries
built against the current code. My guess is that it's very unlikely
for anyone to be using this code directly so it's not really a big deal.

But in general, it would be better to add a new set(Integer) method
which calls the old one and deprecate the old one to be as consistent
as possible for a point-release.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9H8m4ACgkQHPApP6U8
pFhVwQ/+MyrOmzl8+ragnuyamOlDkGSzhULnJpAnF43OScVBkCfjIbfO3S6ZxZSA
N/uzXg4c2/zXO/qN1BMCRRHi8/bbb02y54h4jT8h/2OyIdbmlFJhOWAGPpkA7A8D
GwgSpG5YbEtnpEg0nodtrbWzF1VqKw1x1Wa65tx2wFeSJCVVTlECGlQc1w3sewuV
o3rpLuupamg/3gOzHlPHaBNYOFY8IEeXtTGmdpTeKmpsh2tbkNvsctcH5IiPvaox
8M1mz3IJpK0xb/epBADf7N+hNe+4dT7r+jsDcMyuvRD5CIsLvuKDa2Az8MgamNLQ
Jd4J1LpxY8PmWsF3EV51DIJmyijxeHEvPu9YXZQ+eR7k4vxFn7CLdfDe3p0SdhKO
z2m3Sr3BW23tKJBBRQmHLgT7N3ZlnVdoMmQ9jy+vzbb+QWYEQGO3Oc8P1tZbKEjK
CBKOYmfkBlfB6vcsX/n8pC4gFU6R/V2qKhYG6KiHGjviEoRy0gWLi+5OpD9y+dYS
u7FjQcB1NrT/kVghOSAkUcvKaIXtB/dM1Se2t/77DnVb7YrjDk97/1Jjbk7rrS6T
myaXIzsZMgI2d26wtBQSTr+AyyFvNw2h/LnooAc4bIlDJiFju6nSoVqcBPHHZ1mt
FaIwTzmRSGsSu2EX+S0HEOhHI/kHl5gCP4OVsvZDfBMZN3tKTog=
=GjCI
-END PGP SIGNATURE-

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



Re: [tomcat] 02/02: Update Commons DBCP to latest

2020-08-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/26/20 13:36, Mark Thomas wrote:
> On 26/08/2020 17:56, Christopher Schultz wrote:
>> Mark,
>>
>> On 8/26/20 11:19, ma...@apache.org wrote:
>>> This is an automated email from the ASF dual-hosted git
>>> repository.
>>
>>> markt pushed a commit to branch master in repository
>>> https://gitbox.apache.org/repos/asf/tomcat.git
>>
>>> commit f1c4210470a268ec6830a95ab219f418a7e775fb Author: Mark
>>> Thomas  AuthorDate: Wed Aug 26 16:15:50 2020
>>> +0100
>>
>>> Update Commons DBCP to latest
>>
>> It looks like, among other things, this includes the fix for
>> https://issues.apache.org/jira/browse/DBCP-559
>>
>> If so: hooray!
>>
>> Can you confirm?
>
> Confirmed. There were sufficient meaningful changes to DBCP since
> the last release so I took the latest code.

Sounds great.

Is there a particular reason we don't just shade the commons-dbcp and
commons-pool code at build-time rather than manually merging-in
patches to our private copy?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9Gny4ACgkQHPApP6U8
pFjWWRAAnOx86BJqnoHUt3abvXUMWz0d92kFRwG7gauMqMt6WZ/6zzyiXepRqmU9
oUvh0RH9hh5Ri0nDT+Hjl5PsRuhJ7zzrnA7QBtohFR1q+J7IWq3RpIIwuOmzLgMk
16Yc9m+T5JTH0c1bpZXgwvUyS9WrinIQfE7gBTtO/rDaSU9q7wC0K3S9/BTiED0b
j8y257CMKLPY8rcRoGaXPOwmFLKREli1m7havdatjPqHJF9HhiQiLyFXEN1NDXKb
tNJVxcAv1r9KJ6R1CRbb5/jmzLxncEBBX0IjtpX2YblGMfV5JxtAfJCO72UhTA3g
KGAQEKxRTonbKHkF8vTzAPHpz+r54tpxL5iYyk9M4a+K8Pxaw3wmwgmgbUpqyfJI
gWUgBKSgOP/aA6W2ccjP//D7xtHwcdABJn725zKHnmFb827BjUdFHZW9uxwGnKA3
XTRWeNgF0HNVzRKja3HXJK37vhd3LSUC9L5AG6jwQUqy/CdCUs4F0LbhrbYQcxg1
o3XjYoEp4KVQUtReMNKAiL4tzcneajdml6MFITAvg6wJ57XeSWrramKlkHtFz+bQ
WCl+zatzibH3SVOOsGWghZanzOZcPOxmSIS31hYMn1eAatOj9imCE9t9xA/bJ0FD
zzUqL0oaTe4tfsOecQDeu/HC5OkSjRbXsvHzkXWW7RoRA90RF6c=
=De8e
-END PGP SIGNATURE-

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



Re: Fwd: Security concern about Tomcat's default value for HSTS MaxAge

2020-08-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dave,

On 8/25/20 14:05, Dave Wichers wrote:
> Per:
> https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#HTTP_Heade
r_Security_Filter
>
>
and
https://tomcat.apache.org/tomcat-8.5-doc/config/filter.html#HTTP_Header_
Security_Filter
>
> they both say:
>
> hstsMaxAgeSeconds  - The max age value that should be used in the
> HSTS header. Negative values will be treated as zero. If not
> specified, the default value of 0 will be used.
>
> So, if a Tomcat user (like I did at first), configures
> hstsEnabled=true, the HSTS response header is set by Tomcat, but
> with a max age of zero (since that is the default).
>
> However, per the HSTS RFC:
> https://tools.ietf.org/html/rfc6797#section-6.1.1 it says:
>
> NOTE:  A max-age value of zero (i.e., "max-age=0") signals the UA
> to cease regarding the host as a Known HSTS Host, including the
> includeSubDomains directive (if asserted for that HSTS Host).
>
> I noticed this problem when I first enabled HSTS on my Tomcat dev
> instance, and then passively scanned my web app with OWASP ZAP
> (https://owasp.org/www-project-zap/). ZAP, correctly I believe,
> pointed out that enabling HSTS with a MaxAge of zero is effectively
> a no-op. (i.e., does nothing).

Correct.

> If I'm correct, then I think having a default of zero is dangerous
> and should instead default to something useful and effective.

I disagree.

> Such as one year (in seconds) which is what many developers
> set/configure this value.  Otherwise, I think turning HSTS ON in
> Tomcat might be giving people a false sense of security because it
> really doesn't doing anything unless you also set MaxAge (which to
> me isn't intuitive that you should have to do that).
>
> Do you agree with me that this is a problem that should be fixed?
Here's why I disagree: if you configure your server to reply with
HSTS=on with a meaningful expiration, then the browser is *going to
enforce it*. If you have not configured it correctly, or you are just
testing, you can basically lock your site out from all clients for
e.g. a year before they are willing to re-connect to you.

AFAIK, there is no recognized mitigation for "oops we enabled HSTS for
our site but actually we need parts of it to remain non-encrypted so
please please please forget we ever said anything about HSTS". If you
enable it and don't know what you are doing, you can SERIOUSLY fubar
your infrastructure.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9GlU0ACgkQHPApP6U8
pFgQfQ//XnGay5wOwEIixUb/8PoioJHNLZLgqwShePVRnAkgyzCxRl+yWDonC7pX
BcA4MwI5d/UcivGILor2VH5WXZYeI0e/zlneMT5P9hz9cBrUM4YTSx/wdUNA8a12
mznC7T9fRZiUrgCHhEcgJaAL+rrPXDSAMVq6vVZBhTQBPd0igLmqxf1I8vA2hc8p
Rk8oa6mb2YLSNvIjJAGqYaV1VIg4oMyNjowi5RmpFn/4h3Kk3rnPWY3kFlvi8t3W
JGM3l7tGU8aFxrdCEVO+ypsCCtNsRbGWFGCaETITAHwYVnXEwk9wZNnOA51sJeQE
aRyyo6KyJi7nqKEjlsXV2DBqCmjv8ToWv1INyZrGxJXNojThbeWhexKjrKu8FOXW
RZMnOc6BMfQPb8673lGjLoGzcyjlgLSRhUTNwHaIwTGV8a6nK5+E/GNPr+x00Wei
KumMnm/AB1haBLRPgX+A5elneOnedPweWE00KqH7uBOkUbHCquwOf/9YnmsJBji+
KGIXecNk5pC2bwZF17ULYoC25UEBePyDbJNV5wEOZGLL+ayUtNFhtCSYB30+AWJT
3CqbHb0oMsb9kGQkEqScklzOBRsmHxvDZ4JSswO3rmKEUY+yGWKUbpxdZu6s/HSj
DeaCEnqTByBocQDl8UWRruWwGXX7QC3Dk4z7CZdU1gLFAgMncm0=
=tfoo
-END PGP SIGNATURE-

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



Re: [tomcat] 02/02: Update Commons DBCP to latest

2020-08-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/26/20 11:19, ma...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git
> repository.
>
> markt pushed a commit to branch master in repository
> https://gitbox.apache.org/repos/asf/tomcat.git
>
> commit f1c4210470a268ec6830a95ab219f418a7e775fb Author: Mark Thomas
>  AuthorDate: Wed Aug 26 16:15:50 2020 +0100
>
> Update Commons DBCP to latest

It looks like, among other things, this includes the fix for
https://issues.apache.org/jira/browse/DBCP-559

If so: hooray!

Can you confirm?

Thanks,
- -chris

> --- MERGE.txt  |   2 +-
> .../apache/tomcat/dbcp/dbcp2/BasicDataSource.java  | 187
> +-
> .../tomcat/dbcp/dbcp2/BasicDataSourceFactory.java  |  11 +-
> .../tomcat/dbcp/dbcp2/BasicDataSourceMXBean.java   |  29 +++
> .../tomcat/dbcp/dbcp2/DelegatingConnection.java|   4 +-
> .../tomcat/dbcp/dbcp2/PoolableConnection.java  |   3 +
> .../dbcp/dbcp2/PoolableConnectionFactory.java  |  14 ++
> .../tomcat/dbcp/dbcp2/PoolingConnection.java   | 220
> +++--
> .../dbcp/dbcp2/cpdsadapter/DriverAdapterCPDS.java  |  28 +--
> .../dbcp2/datasources/CPDSConnectionFactory.java   |   3 +-
> .../dbcp2/datasources/InstanceKeyDataSource.java   |   8 +-
> .../dbcp/dbcp2/datasources/package-info.java   |   2 +-
> .../dbcp/dbcp2/managed/BasicManagedDataSource.java |   3 +-
> .../dbcp2/managed/LocalXAConnectionFactory.java|  21 +-
> webapps/docs/changelog.xml |   4 + 15 files
> changed, 323 insertions(+), 216 deletions(-)
>
> diff --git a/MERGE.txt b/MERGE.txt index 79fc82e..b8c152d 100644
> --- a/MERGE.txt +++ b/MERGE.txt @@ -69,4 +69,4 @@ Sub-tree
> src/main/java/org/apache/commons/dbcp2
> src/main/resources/org/apache/commons/dbcp2 The SHA1 ID / tag for
> the most recent commit to be merged to Tomcat is:
> -a363906bf7a039f79c07fa3c68b082a69ae035d7 (2019-12-06)
> +6d232e547d5725e419832fc514fc0348aa897e7c (2020-08-11) diff --git
> a/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSource.java
> b/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSource.java index
> 0293e9a..31faa61 100644 ---
> a/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSource.java +++
> b/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSource.java @@ -63,17
> +63,6 @@ import
> org.apache.tomcat.dbcp.pool2.impl.GenericObjectPoolConfig; */
> public class BasicDataSource implements DataSource,
> BasicDataSourceMXBean, MBeanRegistration, AutoCloseable {
>
> -/** - * @since 2.0 - */ -private class
> PaGetConnection implements PrivilegedExceptionAction {
> - -@Override -public Connection run() throws
> SQLException { -return
> createDataSource().getConnection(); -} -} - private
> static final Log log = LogFactory.getLog(BasicDataSource.class);
>
> static { @@ -220,6 +209,8 @@ public class BasicDataSource
> implements DataSource, BasicDataSourceMXBean, MBean */ private
> boolean poolPreparedStatements = false;
>
> +private boolean clearStatementPoolOnReturn = false; + /** *
>  * The maximum number of open statements that can be allocated
> from the statement pool at the same time, or negative @@ -402,7
> +393,7 @@ public class BasicDataSource implements DataSource,
> BasicDataSourceMXBean, MBean *  *  * Attempts to acquire
> connections using {@link #getConnection()} after this method has
> been invoked result in - * SQLExceptions. + *
> SQLExceptions.  To reopen a datasource that has been closed using
> this method, use {@link #start()}. *  *  * This method is
> idempotent - i.e., closing an already closed BasicDataSource has no
> effect and does not generate @@ -448,7 +439,7 @@ public class
> BasicDataSource implements DataSource, BasicDataSourceMXBean,
> MBean }
>
> /** - * Creates a JDBC connection factory for this datasource.
> The JDBC driver is loaded using the following algorithm: + *
> Creates a JDBC connection factory for this data source. The JDBC
> driver is loaded using the following algorithm: *  * If a
> Driver instance has been specified via {@link #setDriver(Driver)}
> use it * If no Driver instance was specified and {@link
> #driverClassName} is specified that class is loaded using the @@
> -471,6 +462,7 @@ public class BasicDataSource implements
> DataSource, BasicDataSourceMXBean, MBean return
> ConnectionFactoryFactory.createConnectionFactory(this,
> DriverFactory.createDriver(this)); }
>
> + /** * Creates a connection pool for this datasource. This method
> only exists so subclasses can replace the * implementation class.
> @@ -530,7 +522,6 @@ public class BasicDataSource implements
> DataSource, BasicDataSourceMXBean, MBean if (dataSource != null) {
> return dataSource; } - jmxRegister();
>
> // create factory which returns raw physical connections @@ -544,10
> +535,8 @@ public class BasicDataSource implements DataSource,
> BasicDataSourceMXBean, MBean
> 

Re: Use of "constants" in Manager to generate HTML/CSS content

2020-08-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 8/16/20 15:59, Konstantin Kolinko wrote:
> вс, 16 авг. 2020 г. в 21:32, Igal Sapir :
>>
>> I don't see any scripts either.  Why not add a CSP and set script
>> to 'none'?  I can add that if no one objects.
>>
>
> sessionsList.jsp has onclick attributes. Maybe it can be modified
> to work without them, I do not know.

SOP these days is to include a script that attaches itself to the
appropriate elements, instead of having "onclick" attributes directly
in the markup.

This can be solved either by modifying the CSP for that page
specifically, or by specifically allowing scripts based upon their
sha256 signatures.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9CpuUACgkQHPApP6U8
pFhMiw/+JJp90wQaCDo1y0IIzzXNaNuYDIxnSa3cmcTSQLYh78vbnOr2bGaSdiS8
9rQS69jbxfkFnDofQG3HwE4YZSeMjCKRjKzIMTpnUfusE842x91XGdNgtF33rtiW
gXFGJhpgCLchynYLIdl4LYfcGvsxrxuMR9gcaUP2I9/SpeYxTMzOGNuYiaV3mouv
EO5t3l5Wl0FN9hhrGIAhMLG/+wY05cevY16GGZy2xWcDeIHq44Pq2rh9spBFRo2c
9HhaNvNpXlZ30ELmD5YSnxLmpH8CPgsA+5Sdj0ppZ7jpXcx+M/Ihqj+E1za9P20N
WpagVdJaDtYJ0M9FZ5j+nwZoYyGh7ySobH0W3tYfygtfhRgi2l8rc0Zy9CeQPZmu
9WaP2RRz+dGXPMUUwWOKMjl7Fbux+ss66lKvHPrQe0jezVDNYcnSgd7RqlfBznEy
YfoPGxasbyhbrKg7y9encIWOR476LdWQN0g8ZMVxsS3XyStvY3CxiT8NjIrYu1fi
iz8Ni5zEWK1RUiRabv/JrNehrk6ivwARFtJeAwIf8sH2vVlmkQsk4ge8Xfk0BeRP
O49GbiljgqyTy+l5hg0bq9OBkLXTFxLA8D+E9k5dElGzOKQH7GI3+A0GpCm9wbOL
wQCQljWdRgVyLz57bonvTpxe59SNAgwva1AkF6xhM+ky0eiAlHU=
=iYAX
-END PGP SIGNATURE-

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



ApacheCon @ Home Tomcat Track Schedule

2020-08-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm happy to announce that the Apache Tomcat track schedule has been
posted for ApacheCon @ Home, our virtual conference to replace
"ApacheCon North America 2020". If you use social media to discuss
this event, please use #ACAH2020 and tag @apachecon.

You can find the schedule here, as well as links to the other 27 (!)
tracks that will be held at the conference:
https://www.apachecon.com/acah2020/tracks/tomcat.html

If you'd like to register (zero cost!), you can do that here:
https://hopin.to/events/apachecon-home

Note that some tracks are happening at different times; please check
the times for each presentation in each track for your timezone.

I hope to "see" many of you at the conference this year.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl82sk4ACgkQHPApP6U8
pFiypw/+M6Sz1wUtXk6A1CO5Lbz0jMU6/Ky53+zCb3skp4wNSVXaUuJ4xCb2hWg/
cl8KkgP6N0e4stwB9M/XbL403Ic6NGYBvS2ZcMmm2rJqO99t5UvTpUY/DzzNwaXf
d5z2h8p+aSU4ph6UZavi/Tydxa83WxQSRDuRww61xs6yHv7myELicv+fATJGY4fb
slMLJt2Hzmh9C7t7+xkQDTpEUNz+oIV2yyQwuvkAS6WMHJbrqAkuqgQq6eAYm5Qc
79pb4e/G+E71Sr2AzeuFSpLQCUzYIyOkXFoLfr9L6Wb7iwwiu5bFP7+WAbJvI200
tYjokn9NdZOwf4P3uY0xfCk3aq2jI9DZAcYjh7n0nhHCN+8vrqodQ/CZtoBYNQR5
/HwMgszCyimfkegwb3CcuayFUko/Oa+klSOuh9XqFM8jb9XobyXx7dprZk3Ly0Kq
oL/7h3+uBvz4rzR6FVdcuJ7stY4JpBhG+ZsjkiMktYcZovD9IP20RIE+omvqc0/S
L1d/3XyRk3fM6JuQq2Y9yqTcgsbBrzEtcwIAOv2r9TQaRrwSbO2nTUiPVx8RTwQ4
dtE60qVUvZ933I8aV4akqGkeUSBbxiv0WSfpV3T2F1latoqfEmlzueJNWrdgwXFC
8hSVyx29AsTiDGAXAswzxQDyNFlaY9zZZKi467doMvhJBGzTYfk=
=pleB
-END PGP SIGNATURE-

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



Re: Use of "constants" in Manager to generate HTML/CSS content

2020-08-12 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 8/12/20 10:02, Konstantin Kolinko wrote:
> вт, 28 июл. 2020 г. в 16:55, Christopher Schultz
> :
>>
>> All,
>>
>> I was looking at this PR[1] and wondering why we have huge swaths
>> of CSS and HTML in a Java source file, instead of using e.g. JSP
>> or some other content-generation framework.
>
> I remember that I once read some praise for being able to use the
> Manager web application when there is no Jasper and no JSP
> compiler available. It was more than 5 years ago and I do not
> remember the details - maybe it was some small system with limited
> hardware.

Agreed.

> The Manager app does use JSPs nowadays, not for some unimportant
> pages: listing of sessions and listing attributes of a session.

Okay. Are you suggesting then that JSP can/should be required for
Manager usage? Or maybe just for certain functions?

>> I know, I hate JSP, too, but having large blocks of HTML and CSS
>> in Java strings is just ... awful.
>>
>> Also, is there a particular reason we are using embedded CSS in
>> the pages instead of an external CSS file?
>
> Originally it was rather small. It grows with time.

Okay. I think it's time to separate.

> A separate file needs a license header, so the size will grow.

I'm okay with that.

>> Ultimately, it would be a good idea to move all CSS and even
>> styles into a separate CSS file so we can tighten-up the Content
>> Security Policy on the manager app. This can help prevent attacks
>> if there happens to be some kind of XSS vulnerability hiding in
>> there somewhere.
>
> I do not get how having a separate file [matters] with Content
> Security Policy.

Having separate CSS allows a site to allow external styles but
prohibit in-page styles. The allow-token for CSP for inline styles is
"unsafe-inline".

The reason this is a security issue is for XSS attacks. If an XSS
attack is in progress, the script may attempt to modify the page's
styles to manipulate the user. For example, hiding some important data
or warning message. XSS would have more difficulty spoofing an
externally-loaded CSS file.

I don't think we have any js in the Manager, but external js is better
as well, as the page is therefore prohibited from running any js code
appearing in the page: all scripts must be external.

Speaking of which, we should look at defining a CSP for the Manager
application.

>> Any objections to evicting the CSS to begin with?
>
> No objection, if you want it.
>
> We already have image files. Thus, why not?

Sine you mentioned it, how to we "license" image files?

>> [1] https://github.com/apache/tomcat/pull/327
>
> An odd PR. I see that it makes some visual changes, but there is
> no description nor discussion what the actual changes are.

I care less about this specific PR and more about cleaning everything up
.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl80Dx8ACgkQHPApP6U8
pFhSSg/9EQQpZ6WLOeMA7o41UJ3o/X49Xu5h7mliFhIQ6xNkoqW6sWkOHy0LURqU
4S+WaPQzNsXqU8gREcKcU1OPNFnh2i3hGaD6mc/Tr5PMg82qBDwozxM9L6pcKo/N
d30RiJ5MeenrLZ/chbC8Kq4pqBbNtChQWmVH4Dp469DIAwhE3A6T7pwiB1bB72Tz
DxW/1PTAZENvkchkhll/UyEd+pJV9rq1CrrR8LRpqkEkZqu50vKFhE7XWIn4AkZf
OXhtI+SLh/1cxeVMfVjq7JyoslMHiZ7d+55wybvdRWZLns+OMeOTjxW6nzAaB8nN
SYEs/x/+HOV2x91btCpurttGFNzjdU3VqnM/Xk0mThVoxP0CktOSePGlUKd8gqi1
Jed/RxeaKSUSjrghhCJLnvsNhqUfXMy35eATWdJ+YPhIyxM1aotBPZN9zZRKh2zp
IPM/VvpFWJsIiIzbzhLfQfRNK9UpLaTL96s+V/5opoIHpPVpW+T8uSVrFpysfErE
fZVC027SgEDzDjtBvPhRN4E8kK4rUKiAOyJJX/M3q7iJKZj1zy5NOo3RQZ7WAqIv
Qx8mAwIi+/cNaQotbCuTkTpObzSHetR6OF9RQDZG/zAMI+W5/9eVTrZucto4yCB8
9fMGf2YTrqnF4qF5JMAKzRH+kucGyZx4q8aX9SY+RTl5GuGcGKI=
=xI8S
-END PGP SIGNATURE-

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



Re: Use of "constants" in Manager to generate HTML/CSS content

2020-08-12 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Igal,

On 8/11/20 23:23, Igal Sapir wrote:
> Chris,
>
> On Mon, Aug 10, 2020 at 12:20 PM Martin Grigorov
> mailto:mgrigo...@apache.org>> wrote:
>
>
> On Tue, Jul 28, 2020, 16:48 Christopher Schultz
>  <mailto:ch...@christopherschultz.net>> wrote:
>
> All,
>
> I was looking at this PR[1] and wondering why we have huge swaths
> of CSS and HTML in a Java source file, instead of using e.g. JSP
> or some other content-generation framework.
>
> I know, I hate JSP, too, but having large blocks of HTML and CSS
> in Java strings is just ... awful.
>
> Also, is there a particular reason we are using embedded CSS in
> the pages instead of an external CSS file?
>
> Ultimately, it would be a good idea to move all CSS and even
> styles into a separate CSS file so we can tighten-up the Content
> Security Policy on the manager app. This can help prevent attacks
> if there happens to be some kind of XSS vulnerability hiding in
> there somewhere.
>
> Any objections to evicting the CSS to begin with?
>
>
>> It's funny, I was thinking the same thing a couple of weeks ago
>> but didn't want to cause a merge conflict for the PR so waited to
>> see what's going on with that, though as I commented on it I
>> don't like that it changes the theme colors, etc.
>
>> If you are already working on that then great.  If you haven't
>> started, and you have better things to do, I'd be happy to clean
>> that up so please LMK.

I've got a bunch of ACAH presentations to get done, so I'd be
perfectly happy to have you do this work :)

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8z7ogACgkQHPApP6U8
pFjMeBAAh3teSq45voa1dMj2BGTPmhTLq2Eu6y4L5KqjABZergqapfNZsKRUuiTZ
ze1Jpmjb+YfRkspi0nHZMN8K8LBibSh5cr+6SRydZSqada2vNdM1j4y2bCGwrJuY
fykU8adsIzbkQreN+70mzyObJFruUz4o/+PE7c5dc6xQXnZQ7TmxZxfHmAeVegNz
DS0itJXdc8Spnl9HFG+bZwQcKAMflakCxyb/aCjfkhZ4yxUwmX8ReL7ihQWoVH7b
IO85ipw8mJ6h89IfQMN89ZKzs2KRFTbVk7jepxOi4YRoG8P1a2lNcigKBQ6qi0DF
aGaiiTck58+q5uvWQDE7kWSm1MGmLz6bec5zknQ7Smgw2sQqykFLRDDia/v/gKRn
B1nmGp0aB8P5sReP3F/ipOFTXXOVT4N/8MHNv3EK2M+b5isYDzyCF96f7Q8ha+mA
NPh+CJlCWTpEvRjSuwd12DVL/12WyDtCI8fOHlrCCI2ks5L45JWFtQX26WvYZl6n
Z2WO4yg58CjTTxr66VAnuriZra6gSRfZyJCTUp2wImcrAR9pBiM7uB6D1e03hgP3
qiMSY/jSLRvv+aaXQTpc+ePFInKWE+iEgNh7s2njgYrS0dcn5ahhFgeioXtDV8ex
nTbucrv9ArTZ+XywnQSI8UHDA3bb2gAM+xnb31d8p83TEDv5how=
=jGCx
-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

2020-08-12 Thread 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



Publishing EOL dates on whichversion?

2020-08-06 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm wondering if we shouldn't add EOL dates to the "which version" page.

The table on that page is very busy, but I think it would help to know:

1. When a currently-supported version will be EOL'd (e.g. 7.0.x)
2. When a superseded version has been EOL'd (e.g. 6.0.x)

We might be able to shrink the table horizontally a little by
shrinkking / abbreviating some of the column headers. For example
replace "Authentication (JASPIC) Spec" with "JASPIC". Maybe drop
"Spec" from all headers. Maybe shorten "Latest Released Version" to
"Latest" and "Supported Java Versions" to "Java". We could use a
stylesheet to add those longer headers for printing, and we could use
"title"s to expand the headers if you float a mouse/tap a finger on
the headings to get more information. We could also put a key below
the table.

WDYT?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sIa8ACgkQHPApP6U8
pFhjkA/8DLMqIHgF130aGL2YXWuG5OKl/WHh1NFUHhcWHg1zu4zosaMeqExcxFdM
20kE44WjbcD0kvAEeAvR6ejOLm1S7lfXzCs41ZnJI6v4wyhEfp+n9gfYESF3kZqU
5v4IhD0XBspp60iom2BVggF61qu2ZIE9BCD+zv5ikELni4+psg1T7WkTomtIj8Id
W0A+QGMnsYyAGZpqxPRM3agn/T2A+pbsQKFTfqX8KEot+m00PrEy5HRjeYCRpm4Y
OtlHrPLhrOutS7M3K8b191BPf7I55pGEfsq7rSHnpD0H+KM4ur9v6tHtWNutwVTY
3Y2Fs357Cckr+jU0YpBEDn/2jmHioiShMYNmchalkvbXCiCESzgzhr5oazU7tp9j
et7zFy3XlJ1e0fJ3vq/LQnu6HqCwPRPaF27h8hyVrLSzatrPb9Cb2/AGr3SaHonK
9YmpziI1MR4i358y3cxeVIaTMal6MDAjRn8fIfQxxm3k5PZiHb+aMNd4Mion11xH
SqVAep9FyV9V0AbikoazTzUApPBosiD0onioq3o6ApSVfdaa+shh2jmI2JFzRGkf
Unpb3xGRye3EZZVjwXCDw0QJ2UVx65gM7k5W0xvUr0IOmSjJVLBpi1Z1Zv7ijNN0
nj8x3UUTNrABK8PniUIZ+xafoRFlPv4RDGcf6laCdks5R5y31+8=
=8Ax9
-END PGP SIGNATURE-

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



[tomcat] branch 8.5.x updated: Update changelog.xml

2020-08-04 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 3f81598  Update changelog.xml
3f81598 is described below

commit 3f81598de055d935daf17f6fe49cf37ba429f16f
Author: Christopher Schultz 
AuthorDate: Tue Aug 4 17:43:03 2020 -0400

Update changelog.xml

Fix XML.
---
 webapps/docs/changelog.xml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index ac90ee8..47413b6 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -103,6 +103,7 @@
 62723: Clarify the effects of some options for cluster
 channelSendOptions. Patch provided by Mitch Claborn.
 (schultz)
+  
 
   
 


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



[tomcat] branch 9.0.x updated: Fix XML

2020-08-04 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 4b3580a  Fix XML
4b3580a is described below

commit 4b3580af10e7d12201cb40cd68581b2dd1f5bfa2
Author: Christopher Schultz 
AuthorDate: Tue Aug 4 17:38:38 2020 -0400

Fix XML
---
 webapps/docs/changelog.xml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 1806b15..dbcb5a6 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -109,6 +109,7 @@
 62723: Clarify the effects of some options for cluster
 channelSendOptions. Patch provided by Mitch Claborn.
 (schultz)
+  
 
   
   


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



[tomcat] branch master updated: Fix XML

2020-08-04 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 446b7d3  Fix XML
446b7d3 is described below

commit 446b7d378be45904eb41cf50fea7b1efc077665a
Author: Christopher Schultz 
AuthorDate: Tue Aug 4 17:38:38 2020 -0400

Fix XML
---
 webapps/docs/changelog.xml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 17ec66b..e1c8e04 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -113,6 +113,7 @@
 62723: Clarify the effects of some options for cluster
 channelSendOptions. Patch provided by Mitch Claborn.
 (schultz)
+  
 
   
   


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



[tomcat] branch 8.5.x updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723

2020-08-04 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new df39f20  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723
df39f20 is described below

commit df39f2024023fcc07cfbc69cc6b0999cb5560a68
Author: Christopher Schultz 
AuthorDate: Tue Aug 4 17:10:01 2020 -0400

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

Clarify the effects of some cluster channelSendOptions.

Patch provided by Mitch Claborn.
---
 webapps/docs/changelog.xml  |  4 
 webapps/docs/cluster-howto.xml  | 22 +
 webapps/docs/config/cluster.xml | 44 -
 3 files changed, 65 insertions(+), 5 deletions(-)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index dff49fb..ac90ee8 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -99,6 +99,10 @@
 Clean-up / standardize the XSL files used to generate the 
documentation.
 PR provided by John Bampton. (markt)
   
+  
+62723: Clarify the effects of some options for cluster
+channelSendOptions. Patch provided by Mitch Claborn.
+(schultz)
 
   
 
diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml
index cce6726..09cdb2c 100644
--- a/webapps/docs/cluster-howto.xml
+++ b/webapps/docs/cluster-howto.xml
@@ -217,10 +217,24 @@ should be completed:
 sent over the wire and reinstantiated on all the other cluster nodes.
 Synchronous vs. asynchronous is configured using the 
channelSendOptions
 flag and is an integer value. The default value for the 
SimpleTcpCluster/DeltaManager combo is
-8, which is asynchronous. You can read more on the send flag(overview) or the
-send 
flag(javadoc).
-During async replication, the request is returned before the data has been 
replicated. async replication yields shorter
-request times, and synchronous replication guarantees the session to be 
replicated before the request returns.
+8, which is asynchronous.
+See the configuration 
reference
+for more discussion on the various channelSendOptions values.
+
+
+For convenience, channelSendOptions can be set by name(s) 
rather than integer,
+which are then translated to their integer value upon startup.  The valid 
option names are:
+"asynchronous" (alias "async"), "byte_message" (alias "byte"), 
"multicast", "secure",
+"synchronized_ack" (alias "sync"), "udp", "use_ack".  Use comma to 
separate multiple names,
+e.g. pass "async, multicast" for the options
+SEND_OPTIONS_ASYNCHRONOUS | SEND_OPTIONS_MULTICAST.
+
+
+  You can read more on the send 
flag(overview) or the
+  send 
flag(javadoc).
+  During async replication, the request is returned before the data has been 
replicated. async
+  replication yields shorter request times, and synchronous replication 
guarantees the session
+  to be replicated before the request returns.
 
 
 
diff --git a/webapps/docs/config/cluster.xml b/webapps/docs/config/cluster.xml
index f6cd407..9211edd 100644
--- a/webapps/docs/config/cluster.xml
+++ b/webapps/docs/config/cluster.xml
@@ -143,7 +143,49 @@ Tomcat cluster. These include:
   
   Note that if you use ASYNC messaging it is possible for update messages
   for a session to be processed by the receiving nodes in a different order
-  to the order in which they were sent.
+  to the order in which they were sent.
+  
+  
+The various channelSendOptions values offer a tradeoff
+between throughput on the sending node and the reliability of
+replication should the sending or receiving node(s) fail. Here are
+some common options. "Message" could be any message sent between nodes,
+but only session-change messages are considered, here.
+  
+  
+channelSendOptions="8" / 
channelSendOptions="async"
+As far as the sender is concerned, the message is "sent"
+as soon as it has been placed in the queue on the sender for
+transmission to the other nodes. The message may not reach any or all
+of the recipient nodes and may not be successfully processed on any
+nodes that it does reach. This option offers the highest throughput on
+the sender but the least reliability, as the triggering request will
+complete without any knowledge of the success/failure of the session
+replication.
+  
+  
+channelSendOptions="2" / 
channelSendOptions="use_ack"
+The sender will block the completion of the current request until all
+of the receiving n

[tomcat] branch 9.0.x updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723

2020-08-04 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new b75ee12  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723
b75ee12 is described below

commit b75ee12a4ed6724c21f1a670b5a569ff5e043e52
Author: Christopher Schultz 
AuthorDate: Tue Aug 4 16:59:34 2020 -0400

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

Clarify the effects of some cluster channelSendOptions.

Patch provided by Mitch Claborn.
---
 webapps/docs/changelog.xml  |  4 
 webapps/docs/cluster-howto.xml  |  2 ++
 webapps/docs/config/cluster.xml | 34 ++
 3 files changed, 40 insertions(+)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 95ddadf..1806b15 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,10 @@
 Clean-up / standardize the XSL files used to generate the 
documentation.
 PR provided by John Bampton. (markt)
   
+  
+62723: Clarify the effects of some options for cluster
+channelSendOptions. Patch provided by Mitch Claborn.
+(schultz)
 
   
   
diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml
index cfbfc2f..09cdb2c 100644
--- a/webapps/docs/cluster-howto.xml
+++ b/webapps/docs/cluster-howto.xml
@@ -218,6 +218,8 @@ should be completed:
 Synchronous vs. asynchronous is configured using the 
channelSendOptions
 flag and is an integer value. The default value for the 
SimpleTcpCluster/DeltaManager combo is
 8, which is asynchronous.
+See the configuration 
reference
+for more discussion on the various channelSendOptions values.
 
 
 For convenience, channelSendOptions can be set by name(s) 
rather than integer,
diff --git a/webapps/docs/config/cluster.xml b/webapps/docs/config/cluster.xml
index 91e8328..12434a8 100644
--- a/webapps/docs/config/cluster.xml
+++ b/webapps/docs/config/cluster.xml
@@ -146,6 +146,40 @@ Tomcat cluster. These include:
   to the order in which they were sent.
   
   
+The various channelSendOptions values offer a tradeoff
+between throughput on the sending node and the reliability of
+replication should the sending or receiving node(s) fail. Here are
+some common options. "Message" could be any message sent between nodes,
+but only session-change messages are considered, here.
+  
+  
+channelSendOptions="8" / 
channelSendOptions="async"
+As far as the sender is concerned, the message is "sent"
+as soon as it has been placed in the queue on the sender for
+transmission to the other nodes. The message may not reach any or all
+of the recipient nodes and may not be successfully processed on any
+nodes that it does reach. This option offers the highest throughput on
+the sender but the least reliability, as the triggering request will
+complete without any knowledge of the success/failure of the session
+replication.
+  
+  
+channelSendOptions="2" / 
channelSendOptions="use_ack"
+The sender will block the completion of the current request until all
+of the receiving nodes have acknowledged that they have received the
+message, but have not necessarily processed that message. This option
+will result in lower throughput on the sending node, because the 
message
+must be transmitted and the acknowledgement received, but the
+reliability is greater than the asynchronous model.
+  
+  
+channelSendOptions="6" / 
channelSendOptions="sync,use_ack"
+The sender will block the completion of the current request until
+all of the receiving nodes have acknowledged that they have received
+and processed the message. This option will have the lowest
+throughput (of these three) but the greatest reliability.
+  
+  
   You may also set these options as a comma separated string, e.g. "async, 
multicast", which
   will be translated into Channel.SEND_OPTIONS_ASYNCHRONOUS | 
Channel.SEND_OPTIONS_MULTICAST
   


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



[tomcat] branch master updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723

2020-08-04 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new d3c8a10  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723
d3c8a10 is described below

commit d3c8a10babacae2fb857c0591960d96397305353
Author: Christopher Schultz 
AuthorDate: Tue Aug 4 16:56:39 2020 -0400

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

Clarify the effects of some cluster channelSendOptions.

Patch provided by Mitch Claborn.
---
 webapps/docs/changelog.xml  |  4 
 webapps/docs/cluster-howto.xml  |  2 ++
 webapps/docs/config/cluster.xml | 34 ++
 3 files changed, 40 insertions(+)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 246c2c4..17ec66b 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -109,6 +109,10 @@
 Clean-up / standardize the XSL files used to generate the 
documentation.
 PR provided by John Bampton. (markt)
   
+  
+62723: Clarify the effects of some options for cluster
+channelSendOptions. Patch provided by Mitch Claborn.
+(schultz)
 
   
   
diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml
index cfbfc2f..09cdb2c 100644
--- a/webapps/docs/cluster-howto.xml
+++ b/webapps/docs/cluster-howto.xml
@@ -218,6 +218,8 @@ should be completed:
 Synchronous vs. asynchronous is configured using the 
channelSendOptions
 flag and is an integer value. The default value for the 
SimpleTcpCluster/DeltaManager combo is
 8, which is asynchronous.
+See the configuration 
reference
+for more discussion on the various channelSendOptions values.
 
 
 For convenience, channelSendOptions can be set by name(s) 
rather than integer,
diff --git a/webapps/docs/config/cluster.xml b/webapps/docs/config/cluster.xml
index 91e8328..12434a8 100644
--- a/webapps/docs/config/cluster.xml
+++ b/webapps/docs/config/cluster.xml
@@ -146,6 +146,40 @@ Tomcat cluster. These include:
   to the order in which they were sent.
   
   
+The various channelSendOptions values offer a tradeoff
+between throughput on the sending node and the reliability of
+replication should the sending or receiving node(s) fail. Here are
+some common options. "Message" could be any message sent between nodes,
+but only session-change messages are considered, here.
+  
+  
+channelSendOptions="8" / 
channelSendOptions="async"
+As far as the sender is concerned, the message is "sent"
+as soon as it has been placed in the queue on the sender for
+transmission to the other nodes. The message may not reach any or all
+of the recipient nodes and may not be successfully processed on any
+nodes that it does reach. This option offers the highest throughput on
+the sender but the least reliability, as the triggering request will
+complete without any knowledge of the success/failure of the session
+replication.
+  
+  
+channelSendOptions="2" / 
channelSendOptions="use_ack"
+The sender will block the completion of the current request until all
+of the receiving nodes have acknowledged that they have received the
+message, but have not necessarily processed that message. This option
+will result in lower throughput on the sending node, because the 
message
+must be transmitted and the acknowledgement received, but the
+reliability is greater than the asynchronous model.
+  
+  
+channelSendOptions="6" / 
channelSendOptions="sync,use_ack"
+The sender will block the completion of the current request until
+all of the receiving nodes have acknowledged that they have received
+and processed the message. This option will have the lowest
+throughput (of these three) but the greatest reliability.
+  
+  
   You may also set these options as a comma separated string, e.g. "async, 
multicast", which
   will be translated into Channel.SEND_OPTIONS_ASYNCHRONOUS | 
Channel.SEND_OPTIONS_MULTICAST
   


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



Re: Discouraging Rogue Users In Tomcat

2020-08-04 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alan,

On 8/3/20 21:25, Alan Basche wrote:
> I have recently developed code for Tomcat 8.5 that defends against
> black-hats probing Tomcat and the website apps for
> vulnerabilities. This coding effort started a year ago, and the
> latest code has been running successfully on Tomcat 8.5.49 (Linux
> server) for about 3 months.  I feel that Tomcat is less vulnerable
> now and I would be rather uncomfortable running a production system
> without this new feature.
>
> I am happy to provide design details and donate this code to
> Apache, but I am unsure of your process to introduce new Tomcat
> features for review by your dev team, and to submit code.
>
> Let me know if you have questions.

What kind of protections does this module provide? How does it
integrate into Tomcat (e.g. custom
Filter/Valve/ServletContextListener, patches to arbitrary places in
Tomcat internals, etc.)?

Are you willing to post your code somewhere like GitHub where everyone
can see it?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8paG4ACgkQHPApP6U8
pFjbHg/8CJU3YQqQhu9TdPkSyS1CtRy6dgN0wf24NbU0mB39732lSk63Nssvm76e
TWSzZ3cArjNseMrv8pxPsj44q5LCKZC065PpJnz5FEG0wJo7jVH+oQ4UcfBTqyuF
woTjbMmX7b8IQIY/z5vgHXlgXlbVx8gZzNyRh0SgUZPNrZyViGgTKLMz4Wo+1PO+
xhBIEsAMyF55mei8qXYTatoW6vZ8oXofzh54Z41sAiA1zhziPBgim6E8UUaH8F8p
kL9fcI3n421tsaE9ALLMrWQLAxUgwdbcLrL23JWRXOMT9pk7htkdEpQ+NF7UByr+
yL6omz3+LfUngFpAAIYX1A2DRQ9vtlFkM3VklGahemAM3BXzsiAEwbMYCycAhJEt
iuoBu93F1q00iStYE6OcesRLIcmVplQMEGfgF8ibg9NGJQZLeTGXKfN2ksGAkr9x
uk4uco9+NDKq19eQGitFnzx+l1Dvh9NlSDcoJsbw8mDKhPM1S+u3vQ5jVIgTw9s0
W5U8qWxFFcH3yWa805f3Skptps7mQg12YpDBsTEErwip+cIGhwG4Yna1AFtXhVU3
QHdz9hEsu1efNVWmjKvTsjAXnPNfn5F3rXjiyEbEzws1k0Z4D8MlrFWyk4ykfJWj
e4/oPtQE/QD2jgq488WDRhMRimV2iB4u26SdfW7dyQvXVHNQI8I=
=AiQz
-END PGP SIGNATURE-

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



Re: First impressions from OpenSSL 3.0.0 and TC 10.0.0-M7 plus tcnative 1.2.24

2020-08-03 Thread Christopher Schultz
IO-JSSE-PEM]
> took 0.185 sec Testcase:
> testHostRSAwithRSAandECClient[NIO-JSSE-PEM] took 0.255 sec
> Testcase: testHostRSAwithRSAClient[NIO-JSSE-PEM] took 0.199 sec

I'm assuming that this is a spec-upgrade and we are just using smelly
certs in our tests. Does that sound about right?


> Furthermore the test with OpenSSL 1.1.1g plus patches showed one
> isolated JVM crash under Zulu with JDK 11 in
> org.apache.tomcat.util.net.TestSsl for NIO2:
>
> Executable: /usr/local/zulu_jdk11/bin/java Control Group: / Slice:
> -.slice Boot ID: 5b69924960db44f297aac21f912de346 Machine ID:
> 11e20c69b48145c494c0005eb2e92d17 Hostname: esb-rhel8-64 Storage:
> /var/lib/systemd/coredump/core.java.1200.5b69924960db44f297aac21f912de
346.8157.159642343300.lz4
>
>  Message: Process 8157 (java) of user 1200 dumped core.
>
> Stack trace of thread 8162: #0  0x7f2a39bfe93f raise
> (libc.so.6) #1  0x7f2a39be8c95 abort (libc.so.6) #2
> 0x7f2a39c41d57 __libc_message (libc.so.6) #3
> 0x7f2a39c4868c malloc_printerr (libc.so.6) #4
> 0x7f2a39c4a188 _int_free (libc.so.6) #5  0x7f2a08b0d4f3
> apr_allocator_destroy (libapr-1.so.0) #6  0x7f2a08b0df60
> apr_pool_terminate (libapr-1.so.0) #7  0x7f2a1be0f1f0 n/a
> (n/a) #8  0x7f2a1be00849 n/a (n/a) #9  0x7f2a38faab42
> _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgum
entsP6Thread
>
>
(libjvm.so)
> #10 0x7f2a393b8de0
> _ZL6invokeP13InstanceKlassRK12methodHandle6Handleb14objArrayHandle9Bas
icTypeS5_bP6Thread
>
>
(libjvm.so)
> #11 0x7f2a393b9bc3
> _ZN10Reflection13invoke_methodEP7oopDesc6Handle14objArrayHandleP6Threa
d
>
>
(libjvm.so)
> #12 0x7f2a39058542 JVM_InvokeMethod (libjvm.so) #13
> 0x7f2a239792b0 n/a (n/a) #14 0x7f2a1c779a8c n/a (n/a)
>
> I ran the test with 2 threads in parallel. It looks like a
> possible thread safety issue (race condition) during shutdown.
> Seems not to be strictly reproducible.

Does higher concurrency improve the reliability of this failure?

> So far this means OpenSSL 3.0.0 looks good :)

That IS good news.

Thanks,
- -chris


> Am 01.08.2020 um 19:12 schrieb Christopher Schultz:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> Rainer,
>>
>> On 8/1/20 11:44, Rainer Jung wrote:
>>> Sorry, wrong dev list.
>>
>> I thought it was interesting anyway :)
>>
>> How about libtcnative built against OpenSSL 3.0.0?
>
> -
>
>
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8oOrAACgkQHPApP6U8
pFh/og/+LLhkI0r3u726xKCIM7Oviy2wiz8UsPmHy0G/0tv8nZKCLJ4rDR27cG70
NCFD5kc7wcSlB2CsEqONpD2h37vWMJo5oIrguDdKyjn1p2fD2+8QWv5nFrfsd2d6
4UXgLvlJm4O95MpkEF1O5gfR24bDhHwg1EYogcUhtpll9oS4XWXpEpvQSOq9hBFz
DXuoqriU2F/tK+2JLsGavnTf0EKwBwg7Afd2QhEw0GPbhgkV4xylR7sWptS25bEU
9QkFhF+1Ba4UKex3WnfP+uLwY12fkFWFhMKiUVDAjsUDq7EGF0WAUQYjCC/VBd89
Vane1qeIzdU9LypMol9NuMAS5S0Mn5k0f/BP3QrfN2Bc+3tA9lBML9qsS84nrc9l
IP2PILGXD7jr4bK7l6VLV7booLpDUK2+nEegtQTCadEr89U3xX1fnGJfyOb5rxXx
nqV9HES5h7wRzl9xtd3u4KtRC3tNhbVnFaJdsG1igmxr6AF7O0zMUjQyu2RTNx/G
813RmcWe8jorEq67tAGOl/imn764fxerWhqUOMxN/TVOcSj1YwkymkDWRs+UOzQR
ooyx/bUVMsW98cPKUBB00VN881axXgorP98rCsm4HkzJxD3NvXRLUvOuk2p9RoQU
ai/VhMGxtlR95V8qK4zdbp+zvvew7ZkQTJJw9bb2br62qMvqBIc=
=JcGj
-END PGP SIGNATURE-

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



Re: First impressions from OpenSSL 3.0.0 and httpd 2.4.45

2020-08-01 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rainer,

On 8/1/20 11:44, Rainer Jung wrote:
> Sorry, wrong dev list.

I thought it was interesting anyway :)

How about libtcnative built against OpenSSL 3.0.0?

- -chris

> Am 01.08.2020 um 12:07 schrieb Rainer Jung:
>> Hi there,
>>
>> during release testing for 2.4.45 I also built and tested using
>> OpenSSL 3.0.0alpha5 on the server. Overall first results are
>> pretty good:
>>
>> - a few deprecation warnings during compilation:
>>
>> modules/ssl/ssl_engine_config.c:610:5: warning: 'ENGINE_by_id'
>> is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_config.c:612:9: warning: 'ENGINE_free' is
>> deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_config.c:617:9: warning:
>> 'ENGINE_get_first' is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_config.c:619:13: warning: 'ENGINE_get_id'
>> is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_config.c:620:42: warning:
>> 'ENGINE_get_name' is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_config.c:623:13: warning:
>> 'ENGINE_get_next' is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_init.c:457:9: warning: 'ENGINE_by_id' is
>> deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_init.c:467:13: warning: 'ENGINE_ctrl' is
>> deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_init.c:471:9: warning:
>> 'ENGINE_set_default' is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_init.c:482:9: warning: 'ENGINE_free' is
>> deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_kernel.c:2611:9: warning: 'HMAC_Init_ex'
>> is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_kernel.c:2632:9: warning: 'HMAC_Init_ex'
>> is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_log.c:90:5: warning:
>> 'ERR_peek_error_line_data' is deprecated
>> [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_pphrase.c:856:5: warning: 'ENGINE_by_id'
>> is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_pphrase.c:864:5: warning: 'ENGINE_init'
>> is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_pphrase.c:877:9: warning:
>> 'ENGINE_ctrl_cmd_string' is deprecated
>> [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_pphrase.c:886:9: warning:
>> 'ENGINE_ctrl_cmd' is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_pphrase.c:896:5: warning:
>> 'ENGINE_load_private_key' is deprecated
>> [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_pphrase.c:904:5: warning: 'ENGINE_finish'
>> is deprecated [-Wdeprecated-declarations]
>> modules/ssl/ssl_engine_pphrase.c:905:5: warning: 'ENGINE_free'
>> is deprecated [-Wdeprecated-declarations]
>>
>> - a few const warnings
>>
>> modules/ssl/ssl_engine_kernel.c:608:55: warning: passing argument
>> 2 of 'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer
>> target type [-Wdiscarded-qualifiers]
>> modules/ssl/ssl_engine_kernel.c:627:61: warning: passing argument
>> 2 of 'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer
>> target type [-Wdiscarded-qualifiers]
>> modules/ssl/ssl_engine_kernel.c:638:57: warning: passing argument
>> 2 of 'sk_SSL_CIPHER_find' discards 'const' qualifier from pointer
>> target type [-Wdiscarded-qualifiers]
>> modules/ssl/ssl_engine_kernel.c:1039:49: warning: passing
>> argument 2 of 'sk_SSL_CIPHER_find' discards 'const' qualifier
>> from pointer target type [-Wdiscarded-qualifiers]
>>
>> and unit tests show two problems, one will be fixed in OpenSSL
>> itself:
>>
>> - during unit test preparation, our test script create a PKCS12
>> store with default encoding params. That's known to be broken in
>> alpha5. So the "-configure" step of "t/TEST" should be run before
>> the actual testing with a stable version of OpenSSL.
>> https://github.com/openssl/openssl/pull/12540
>> https://github.com/openssl/openssl/issues/11672
>>
>> - independent of OpenSSL 3.0.0: to work around the previous
>> observation I tried using the env var "APACHE_TEST_OPENSSL_CMD".
>> Unfortunately this is slightly broken, because it tests for the
>> existence using the "which" function in TestConfig.pm and that
>> function is broken when used for a command containing a path
>> component. I temporarily fixed it using:
>>
>> @@ -1782,6 +1782,11 @@
>>
>> return undef unless $program;
>>
>> +# No need to search PATH components +# if $program
>> already contains a path +return $program if !OSX and !WINFU
>> and +$program =~ /\// and -f $program and -x $program; +
>> my @dirs = File::Spec->path();
>>
>> require Config;
>>
>>
>> - when testing with client >= OpenSSL 1.1.0 against 3.0.0alpha5,
>> only t/ssl/proxy.t shows failures, especially in eat_post but
>> already during TLS handshake:
>>
>> [ssl:info] [pid 9162:tid 140326149928720] [client
>> 127.0.0.1:56312] AH01964: Connection to child 82 established
>> (server localhost:8532)
>>
>> [ssl:info] [pid 

[tomcat] branch 8.5.x updated: Add test including port numbers in various places.

2020-07-30 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 74298d4  Add test including port numbers in various places.
74298d4 is described below

commit 74298d4e7dce1723fd7e9b57af6b4bd7a097b212
Author: Christopher Schultz 
AuthorDate: Thu Jul 30 17:25:05 2020 -0400

Add test including port numbers in various places.
---
 .../apache/catalina/valves/TestRemoteIpValve.java  | 56 ++
 1 file changed, 56 insertions(+)

diff --git a/test/org/apache/catalina/valves/TestRemoteIpValve.java 
b/test/org/apache/catalina/valves/TestRemoteIpValve.java
index d2f7040..a428ba7 100644
--- a/test/org/apache/catalina/valves/TestRemoteIpValve.java
+++ b/test/org/apache/catalina/valves/TestRemoteIpValve.java
@@ -1128,6 +1128,62 @@ public class TestRemoteIpValve {
 request.getAttribute(Globals.REQUEST_FORWARDED_ATTRIBUTE));
 }
 
+@Test
+public void testRequestForwardedForWithPortNumber() throws Exception {
+
+// PREPARE
+RemoteIpValve remoteIpValve = new RemoteIpValve();
+RemoteAddrAndHostTrackerValve remoteAddrAndHostTrackerValve = new 
RemoteAddrAndHostTrackerValve();
+remoteIpValve.setNext(remoteAddrAndHostTrackerValve);
+
+Request request = new MockRequest();
+request.setCoyoteRequest(new org.apache.coyote.Request());
+// client ip
+request.setRemoteAddr("192.168.0.10");
+request.setRemoteHost("192.168.0.10");
+
request.getCoyoteRequest().getMimeHeaders().addValue("x-forwarded-for").setString("140.211.11.130:1234");
+// protocol
+request.setServerPort(8080);
+request.getCoyoteRequest().scheme().setString("http");
+
+// TEST
+remoteIpValve.invoke(request, null);
+
+// VERIFY
+
+Assert.assertEquals("140.211.11.130:1234", 
remoteAddrAndHostTrackerValve.getRemoteAddr());
+   }
+
+@Test
+public void testRequestForwardedForWithProxyPortNumber() throws Exception {
+
+// PREPARE
+RemoteIpValve remoteIpValve = new RemoteIpValve();
+//remoteIpValve.setRemoteIpHeader("x-forwarded-for");
+//remoteIpValve.setProtocolHeader("x-forwarded-proto");
+RemoteAddrAndHostTrackerValve remoteAddrAndHostTrackerValve = new 
RemoteAddrAndHostTrackerValve();
+remoteIpValve.setNext(remoteAddrAndHostTrackerValve);
+
+Request request = new MockRequest();
+request.setCoyoteRequest(new org.apache.coyote.Request());
+// client ip
+request.setRemoteAddr("192.168.0.10");
+request.setRemoteHost("192.168.0.10");
+// Trust c.d
+remoteIpValve.setTrustedProxies("foo\\.bar:123");
+
request.getCoyoteRequest().getMimeHeaders().addValue("x-forwarded-for").setString("140.211.11.130:1234,
 foo.bar:123");
+// protocol
+request.setServerPort(8080);
+request.getCoyoteRequest().scheme().setString("http");
+
+// TEST
+remoteIpValve.invoke(request, null);
+
+// VERIFY
+
+Assert.assertEquals("140.211.11.130:1234", 
remoteAddrAndHostTrackerValve.getRemoteAddr());
+   }
+
 private void assertArrayEquals(String[] expected, String[] actual) {
 if (expected == null) {
 Assert.assertNull(actual);


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



[tomcat] branch 9.0.x updated: Add test including port numbers in various places.

2020-07-30 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 6632954  Add test including port numbers in various places.
6632954 is described below

commit 6632954ae42d990a0040a728239537f4ed9f87d2
Author: Christopher Schultz 
AuthorDate: Thu Jul 30 17:25:05 2020 -0400

Add test including port numbers in various places.
---
 .../apache/catalina/valves/TestRemoteIpValve.java  | 56 ++
 1 file changed, 56 insertions(+)

diff --git a/test/org/apache/catalina/valves/TestRemoteIpValve.java 
b/test/org/apache/catalina/valves/TestRemoteIpValve.java
index 644f229..5974fc6 100644
--- a/test/org/apache/catalina/valves/TestRemoteIpValve.java
+++ b/test/org/apache/catalina/valves/TestRemoteIpValve.java
@@ -1133,6 +1133,62 @@ public class TestRemoteIpValve {
 request.getAttribute(Globals.REQUEST_FORWARDED_ATTRIBUTE));
 }
 
+@Test
+public void testRequestForwardedForWithPortNumber() throws Exception {
+
+// PREPARE
+RemoteIpValve remoteIpValve = new RemoteIpValve();
+RemoteAddrAndHostTrackerValve remoteAddrAndHostTrackerValve = new 
RemoteAddrAndHostTrackerValve();
+remoteIpValve.setNext(remoteAddrAndHostTrackerValve);
+
+Request request = new MockRequest();
+request.setCoyoteRequest(new org.apache.coyote.Request());
+// client ip
+request.setRemoteAddr("192.168.0.10");
+request.setRemoteHost("192.168.0.10");
+
request.getCoyoteRequest().getMimeHeaders().addValue("x-forwarded-for").setString("140.211.11.130:1234");
+// protocol
+request.setServerPort(8080);
+request.getCoyoteRequest().scheme().setString("http");
+
+// TEST
+remoteIpValve.invoke(request, null);
+
+// VERIFY
+
+Assert.assertEquals("140.211.11.130:1234", 
remoteAddrAndHostTrackerValve.getRemoteAddr());
+   }
+
+@Test
+public void testRequestForwardedForWithProxyPortNumber() throws Exception {
+
+// PREPARE
+RemoteIpValve remoteIpValve = new RemoteIpValve();
+//remoteIpValve.setRemoteIpHeader("x-forwarded-for");
+//remoteIpValve.setProtocolHeader("x-forwarded-proto");
+RemoteAddrAndHostTrackerValve remoteAddrAndHostTrackerValve = new 
RemoteAddrAndHostTrackerValve();
+remoteIpValve.setNext(remoteAddrAndHostTrackerValve);
+
+Request request = new MockRequest();
+request.setCoyoteRequest(new org.apache.coyote.Request());
+// client ip
+request.setRemoteAddr("192.168.0.10");
+request.setRemoteHost("192.168.0.10");
+// Trust c.d
+remoteIpValve.setTrustedProxies("foo\\.bar:123");
+
request.getCoyoteRequest().getMimeHeaders().addValue("x-forwarded-for").setString("140.211.11.130:1234,
 foo.bar:123");
+// protocol
+request.setServerPort(8080);
+request.getCoyoteRequest().scheme().setString("http");
+
+// TEST
+remoteIpValve.invoke(request, null);
+
+// VERIFY
+
+Assert.assertEquals("140.211.11.130:1234", 
remoteAddrAndHostTrackerValve.getRemoteAddr());
+   }
+
 private void assertArrayEquals(String[] expected, String[] actual) {
 if (expected == null) {
 Assert.assertNull(actual);


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



[tomcat] branch master updated: Add test including port numbers in various places.

2020-07-30 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new eed9426  Add test including port numbers in various places.
eed9426 is described below

commit eed94263926e6fba061ed4a56e961b2aab1b17df
Author: Christopher Schultz 
AuthorDate: Thu Jul 30 17:25:05 2020 -0400

Add test including port numbers in various places.
---
 .../apache/catalina/valves/TestRemoteIpValve.java  | 56 ++
 1 file changed, 56 insertions(+)

diff --git a/test/org/apache/catalina/valves/TestRemoteIpValve.java 
b/test/org/apache/catalina/valves/TestRemoteIpValve.java
index 5fc43f9..036cf1a 100644
--- a/test/org/apache/catalina/valves/TestRemoteIpValve.java
+++ b/test/org/apache/catalina/valves/TestRemoteIpValve.java
@@ -1133,6 +1133,62 @@ public class TestRemoteIpValve {
 request.getAttribute(Globals.REQUEST_FORWARDED_ATTRIBUTE));
 }
 
+@Test
+public void testRequestForwardedForWithPortNumber() throws Exception {
+
+// PREPARE
+RemoteIpValve remoteIpValve = new RemoteIpValve();
+RemoteAddrAndHostTrackerValve remoteAddrAndHostTrackerValve = new 
RemoteAddrAndHostTrackerValve();
+remoteIpValve.setNext(remoteAddrAndHostTrackerValve);
+
+Request request = new MockRequest();
+request.setCoyoteRequest(new org.apache.coyote.Request());
+// client ip
+request.setRemoteAddr("192.168.0.10");
+request.setRemoteHost("192.168.0.10");
+
request.getCoyoteRequest().getMimeHeaders().addValue("x-forwarded-for").setString("140.211.11.130:1234");
+// protocol
+request.setServerPort(8080);
+request.getCoyoteRequest().scheme().setString("http");
+
+// TEST
+remoteIpValve.invoke(request, null);
+
+// VERIFY
+
+Assert.assertEquals("140.211.11.130:1234", 
remoteAddrAndHostTrackerValve.getRemoteAddr());
+   }
+
+@Test
+public void testRequestForwardedForWithProxyPortNumber() throws Exception {
+
+// PREPARE
+RemoteIpValve remoteIpValve = new RemoteIpValve();
+//remoteIpValve.setRemoteIpHeader("x-forwarded-for");
+//remoteIpValve.setProtocolHeader("x-forwarded-proto");
+RemoteAddrAndHostTrackerValve remoteAddrAndHostTrackerValve = new 
RemoteAddrAndHostTrackerValve();
+remoteIpValve.setNext(remoteAddrAndHostTrackerValve);
+
+Request request = new MockRequest();
+request.setCoyoteRequest(new org.apache.coyote.Request());
+// client ip
+request.setRemoteAddr("192.168.0.10");
+request.setRemoteHost("192.168.0.10");
+// Trust c.d
+remoteIpValve.setTrustedProxies("foo\\.bar:123");
+
request.getCoyoteRequest().getMimeHeaders().addValue("x-forwarded-for").setString("140.211.11.130:1234,
 foo.bar:123");
+// protocol
+request.setServerPort(8080);
+request.getCoyoteRequest().scheme().setString("http");
+
+// TEST
+remoteIpValve.invoke(request, null);
+
+// VERIFY
+
+Assert.assertEquals("140.211.11.130:1234", 
remoteAddrAndHostTrackerValve.getRemoteAddr());
+   }
+
 private void assertArrayEquals(String[] expected, String[] actual) {
 if (expected == null) {
 Assert.assertNull(actual);


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



Use of "constants" in Manager to generate HTML/CSS content

2020-07-28 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I was looking at this PR[1] and wondering why we have huge swaths of
CSS and HTML in a Java source file, instead of using e.g. JSP or some
other content-generation framework.

I know, I hate JSP, too, but having large blocks of HTML and CSS in
Java strings is just ... awful.

Also, is there a particular reason we are using embedded CSS in the
pages instead of an external CSS file?

Ultimately, it would be a good idea to move all CSS and even styles
into a separate CSS file so we can tighten-up the Content Security
Policy on the manager app. This can help prevent attacks if there
happens to be some kind of XSS vulnerability hiding in there somewhere.

Any objections to evicting the CSS to begin with?

Thanks,
- -chris

[1] https://github.com/apache/tomcat/pull/327
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8gLJsACgkQHPApP6U8
pFgKCw//WY8p/EBS7sxDYgnV6W4pjeuAuhXv6ierajPH28NfdokIRlU4IfFIUVIE
Ck98rK9uH98o6QFkWC70MVYV+NbEi4CwrjPhuFV/rEplyqfA+Ijs5g069a1g15On
fw5V44CK2JBj0AjT4ZtMVWOSxDElHZc3SjZmyaie0pk2zDVxYwSwhoRPtqzms5rH
zTlu48R14t1O9PLsWGthwdVStAn9WlE7hBLI3yLag/QKUqlOR/a8Fy75mbMma5a9
cmG8Lh5Jo8a6YzD0q37sdOmKN5d9lZxZkz3x21Cy3v2qcKcaGUcAttAEe9hFKEzh
I0hOMKYc/2n2aNpMTjIkG86fXzAYB1IIsfiGxlwP/nY6HzJ9XRolD9+kT7LZ/tP3
7SKL8rVoKi5SWiH+g3jGifVkxfiHlMhvZikAbC75ngP7mNXZFHPdnF3rvai/cbum
FWUpLDoW/oTs87v9l071hs+hf2PffvqL/v5AeoMbGf/VDpf/zcuNy0wlB2w6Nxo9
K8sBVHQGJzIlaR9fqLyYJkJ8kmSb37t7BxPXLuGSCr98uUD8bSy2IwC2IxessXQc
E+oIyJ0mlPdKU1dh5yFtMzCp4S9olUg4diqOxpToGm2hnmdnkRY3OarC1OU839NC
Yd5uYA9XoYxBro2oNfB1gCNB5Ve4aLVOV0Q3iKcW83b8jLiNgzY=
=Z+cI
-END PGP SIGNATURE-

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



Re: [tomcat] branch master updated: Avoid reflection for default instantiation

2020-07-23 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Filip,

On 7/22/20 12:41, Filip Hanik wrote:
> Hi Christopher,
>>> environments. -Class clazz =
>>> Class.forName(className); -return
>>> (AuthConfigFactory) clazz.getConstructor().newInstance(); + if
>>> (className.equals("org.apache.catalina.authenticator.jaspic.AuthConf
ig
>>
>>>
FactoryImpl"))
>>> {
>>
>> Why not use AuthConfigFactoryImpl.class.getName()? It may help in
>> the future with refactoring.
>
> [Filip Hanik] Trying to avoid a circular dependency. You see the
> javax/jakarta package should not import org.apache.catalina code. I
> should be able to execute the AuthConfigFactory code without
> needing to load
> org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl
> class. The JVM is smart enough that if the execution doesn't enter
> the if statement block, it won't attempt the classloading of the
> AuthConfigFactoryImpl class. However, if the AuthConfigFactoryImpl
> Class itself is part of the evaluation statement, it will be
> loaded.
>
> The previous implementation also had it as a string, instead of
> AuthConfigFactoryImpl.class.getName() for the same reason.
> https://github.com/apache/tomcat/blob/35dc7b9288aad4a7d70750c157543d4f
f1593c98/java/jakarta/security/auth/message/config/AuthConfigFactory.jav
a#L48-L49
>
>  This way, I can build a jakarta.security.auth.message library,
> that can be used without the org.apache.catalina library.

That's a very good reason. Thanks for explaining.

> I need to change my commit to use the constant, instead of the
> duplicated string in the IF statement.
>
> if (className.equals(DEFAULT_JASPI_AUTHCONFIGFACTORYIMPL)) { return
> new
> org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl(); }
> else { Class clazz = Class.forName(className); return
> (AuthConfigFactory) clazz.getConstructor().newInstance(); }

:)

- -chris

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8ZyrUACgkQHPApP6U8
pFghOg//UxcPA7Xm+SKXtyCWEIcabjFkbdHv9o8kOHTiWVSUOrhXLBvTznDKYmYk
+5zFjxsFbBjj1amQnGER/3zJSSJmvdcEUohpHpYHUHFGLh59YyXTVb0ou8PSiX+B
iFEZCqKrkylZPCn21tPXN4wgmnvQxcD9S3++vZBWyCCiQw/BoUYwYGLtg9/sgCjj
eqk2r/yqGRlVtHsMEu04wMadcqpum6f14LO1b8J1C5jP0N9fwiGTEsD4HXskcUfQ
PeDjHtG6tJPXwfYjwRjzZolQIFmQwJ1B6WLufsyw0ZrUVBUENkU4xQwBy3pcVewn
0xc9+vgg+VSXblrDMnoswUBf2hLmfmpw49evcjeKSY7q0G0Fdoe1lUmt+OM74ppK
EZ6qmvCphWtXakyCU5uXx82nQMsNXdwmgLG3Dni4ya79dVoGvn8j3Guh/7g45Jet
0bc7x7KsouqJIbqQAPqdt8E2xKRARsdUE4BH9S0ENkvTqnhhbCWmlxJk3CiPpwoy
3zD5xt9CoXuKX/CjK92hP+nw4b1j+Mdhmwj4whM4FbcvLC6Rq8JXt0obysArweT8
FbfZD45OsWqbgVrVpwcCt19z25+6Ar02DvUz0CkI1sbxzS+hd1yhp2BRbiqTd6HY
EkUodl2R7H95ZmIRZ0QhcnEyq5tPJUcspXLvmzQ5Li25oJEWLrc=
=XYLJ
-END PGP SIGNATURE-

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



Re: [tomcat] branch master updated: Avoid reflection for default instantiation

2020-07-22 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Filip,

On 7/21/20 11:22, fha...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git
> repository.
>
> fhanik pushed a commit to branch master in repository
> https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this
> push: new c08bf81  Avoid reflection for default instantiation
> c08bf81 is described below
>
> commit c08bf81f0db7742779ab0c5da45818dde8465d34 Author: Filip Hanik
>  AuthorDate: Mon Jul 13 12:43:55 2020 -0700
>
> Avoid reflection for default instantiation
>
> (Most commonly used codepath)
>
> Avoid having to load APR classes in the Connector
>
> Ensure that IntrospectionUtils can call setProperty on
> PersistentProviderRegistrations ---
> .../auth/message/config/AuthConfigFactory.java |  8 ++-
> .../jaspic/PersistentProviderRegistrations.java| 12 -
> java/org/apache/catalina/connector/Connector.java  |  8 +--
> .../apache/catalina/core/AprLifecycleListener.java | 32
> +--- java/org/apache/catalina/core/AprStatus.java   |
> 60 ++
> java/org/apache/catalina/core/StandardHost.java|  4 +-
> java/org/apache/catalina/loader/WebappLoader.java  |  4 ++
> java/org/apache/catalina/startup/Tomcat.java   |  8 ++- 8 files
> changed, 109 insertions(+), 27 deletions(-)
>
> diff --git
> a/java/jakarta/security/auth/message/config/AuthConfigFactory.java
> b/java/jakarta/security/auth/message/config/AuthConfigFactory.java
> index d0e1cbd..6f02fde 100644 ---
> a/java/jakarta/security/auth/message/config/AuthConfigFactory.java
> +++
> b/java/jakarta/security/auth/message/config/AuthConfigFactory.java
> @@ -72,8 +72,12 @@ public abstract class AuthConfigFactory { //
> this class. Note that the Thread context class loader // should not
> be used since that would trigger a memory leak // in container
> environments. -Class clazz =
> Class.forName(className); -return
> (AuthConfigFactory) clazz.getConstructor().newInstance(); +
> if
> (className.equals("org.apache.catalina.authenticator.jaspic.AuthConfig
FactoryImpl"))
> {

Why not use AuthConfigFactoryImpl.class.getName()? It may help in the
future with refactoring.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8YXgIACgkQHPApP6U8
pFgHmA/8CweFBvWtEn14ZzUZHkA/7HVaLPG6r7Y4qzkcrzJfQImYzV7E0x3NL59m
fDagGxJrxugESEKf3HLmq5VIzAlemkbPxYQ7S4KaUJVHbRW/MH9zPVzbvAVXy4Gm
CIpVF/QoXftJ9WYsMkwFFu8ZeRsUQSJ5Z4eFXmHgOzDSj42vUR7VDsFXmpoqdIpC
jp0CV9p+XyfAcvtsJXnTKKmDGFV7liH4d38mz8wNLFw1yFk8jswHeyzzy+6u9QVu
fFno1AZ67UWjeOlMz+kQ4S9n3X+irT03Qpc8+kvWDibnEDYuHivvhvROWOn4ja92
dyF+6YZxOGIf4QHwM0BHL+8IzrcodB15j7Iv0Fw9VKrJvcj55qZTerHvOkiwUDQF
1vsiqPtOEWrE4q87Y7aev3WBpRWfxQFu50IQNIAvPwiBmT9mj+3iztq46m5CTtnt
zjfdzxEMF5n74L+2u+CPIekngJ8i0RJOkq4UGrJmXpbX/82q+eN+TDws6GchRquG
3Hr2EgC3oocITMTbu+5ZjvbBVAh30VhqlOF1GwO8YSBIgvNUyPvIqZXK4Re9gjYm
BSRHl2juGFP3d1OSkdimWBkBc8MHx3QOkcCOzZYgPg3mdAq7beqKgh/DTvqQd5D8
MXGe4cgfHoOEY0X53K/qG1KXcIntRXab9Nue8GriGC9M7oMWgIM=
=48+3
-END PGP SIGNATURE-

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



Re: [ANN] ApacheCon NA 2020 is virtual/online, completely free to attend, and call-for-presentations is CLOSED

2020-07-17 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

While the CFP is officially closed for ApacheCon, there is still some
space in the Tomcat track if anyone is still considering a presentation.

Please email me privately if you'd like to submit a topic. Just put
"apachecon" in the subject. (It's very likely to be selected!) All you
need right now is a title and a one-paragraph explanation of what
you'd like to present.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8SFfgACgkQHPApP6U8
pFg3+w/+LhgcRk4rhof5UzfwNNHPARpi6AH02uhvMfPYAlFEu26eBo9qht2QUdD3
gak3PZf3SKPQaxNpeX/Qvw76Oq89aLbSCWCXWFLZM+GkzN8J/JXqpleMyzs0hxKj
3qzih8U64IK0dP3CC1r4ii+wSLmuiH9pg4Peqf3SOnE9skX5xcTZHDAKyD0eqeOf
mMNPSd87Si4T+xeJupZ3Fnj7vqX/nW6cunAoaxGzAAmOEyWFrlBUAPhRm00FEhGf
dmXHBFfjIQT5r6anKbmY9/Rnky8Lye/d0UT/U2JyAnVrmcBUb5GqDHZYefrOC8Av
9XLX5hOedPqLB6BZl5sM6eB4jPzwEouwE6V5yYB4WrYD0asIvqMzk5FKVwk6b+H7
eu+MtxukZFD9tR7EfSAf/9Jh47z6PYjwqWbV1uqGiwuitCUgtg5BdguYtAC5cYmY
thLGq9K8fzOq+PMRim4NCgiJJPbG7VoJBe6r4AwyjpLN33VkcEeltEUn7bi/2vem
p6GlK75OUpwufiCxCZN9d7ShDN1jq6P0Vi2nRfaG78Nk8d07grqpNwF1AONprz/O
IqRmGb81kdgM62p+hfA03TloLzCFGK+fOJcvze3jItQhL2G3jK35Sg3OC1mTH/1p
KqmI3EIjfMH87pUy3guVaCAO+bozsQPuvDrG8ISIw9EPHVIxQ8Q=
=yRIv
-END PGP SIGNATURE-

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



Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

2020-07-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Merlin,

On 7/14/20 09:49, Merlin Beedell wrote:
> I can confirm that changing the certificate by replacing the
> file(s) with the ones with the same name & password but with an
> updated certificate inside does indeed work.  The reason I thought
> otherwise because (I thought that) the useful Presentation by C
> Schultz said it re-read the config - allowing changes to the cipher
> list and TLS types to be altered at the same time.
Right. That could have been more clear: the in-memory configuration is
re-applied to the running SSLContext. Well, actually, we replace the
SSLContext with a new one and allow the GC to clean up the mess.

So if you want to actually reconfigure things, you ave to specifically
reconfigure them first (in memory, likely using JMX / mbeans to do
that) and then invove the reloadSsl operation.

> I had tested by swapping between 2 pfx certificates that I thought
> were different - stupid rookie mistake, the certificates were
> indeed the same.  I created a new self-signed one and that worked
> straight away.

:)

> I presume that I can the 'set' commands in the manager webapp to
> alter the allowed TLS levels?
This should work.

- -chris

> -----Original Message- From: Christopher Schultz
>  Sent: 13 July 2020 11:44 PM To:
> dev@tomcat.apache.org Subject: Re: Support for LetsEncrypt certs,
> and update process, in
Tomcat without restart.
>
> Merlin,
>
> On 7/13/20 06:09, Merlin Beedell wrote:
>> Hi all,
>
>> Thank you for your valuable assistance and suggestions so far.
>
>
>
>> I did eventually try this (again, using ‘groovy’ as a
>> simple-to-use scriptable wrapper to Java), which looks like it
>> works:
>
>
>
>> @Grab(group='com.github.groovy-wslite', module='groovy-wslite',
>> version='1.1.3')
>
>
>
>> import wslite.rest.*
>
>> import wslite.http.auth.*
>
>
>
>> RESTClient client = new
>> RESTClient("http://localhost:8080/manager;) //or
>> https://localhost/manager
>
>> client.authorization = new
>> HTTPBasicAuthorization("tomcat-users-name",
>> "and-corresponding-password")
>
>
>
>> def path =
>
> "/jmxproxy/?invoke=Catalina:type=ProtocolHandler,port=443=reloadSsl
Ho
>
>
stConfigs"
>
>> def response
>
>> response = client.get(path: path)
>
>> println response.text
>
>
>
>> And it returns (for example): “*OK - Operation
>> reloadSslHostConfigs without return value*”
>
>> If the certificate file now no longer exists or is corrupted – we
>> get an error response. Thus we know this action provokes the
>> certificate file to be re-read.
>
>> /However/
>
>> If the connector section in server.xml is edited to point to a
>> new certificate path/filename, it is ignored.  The current
>> certificate config continues to be used.
>
>> If the certificate file is replaced by a new certificate, the
>> end-user does not see any change – a fresh browser will still see
>> the old certificate.
>
>
>
>> So: Is there some /other/ action that I need to invoke after the
>>  reloadSslHostConfigs?  Or to invoke it under a different “mbean
>> name”?
>
>> When I change the bean name to include *address=127.0.0.1* as per
>> your curl example
>> (Catalina:type=ProtocolHandler,port=443,address=127.0.0.1) it
>> errors.
>
>> For example – under the Catalina:type=Connector,port=443 – I see
>>  operations “destroy / pause / resume / stop / start / init”.
>
>> And under the ProtocolHandler I see “findSslHostConfigs / start /
>>  destroy / pause / resume / getProperty /
>> closeServerSocketGraceful / findupgradeProtocols / init”
>
>> Would these help?
>
>
>
>> The connector config (simple self-signed cert in this case – not
>> yet changed to a letsencrypt one) looks similar to this:
>
>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat
io
>
>
n">
>
>> > className="org.apache.coyote.http2.Http2Protocol">
>
>>
>
>
> > ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
>> honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
>
>> > certificateKeystoreFile="C:\opt\certificates\keystore"
>> certificateKeystorePassword="passphrase"
>> certificateKeystoreType="JKS">
>
>> 
>
>> 
>
>
>
>> And I am trying to reset it to a PKCS12 keystore:
>
>> > certificate

Re: Native Image - Reflectionless Concept

2020-07-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Filip,

On 7/13/20 17:59, Filip Hanik wrote:
> for discussion, all feedback and questions welcome:
>
>
> I've created a concept of having Apache Tomcat, embedded, run
> without reflection in a native image. This concept creates a jar,
> tomcat-embedded-programmatic.jar, that can be fine tuned to only
> include what is needed in a default configuration when an embedded
> tomcat instance is used and configured programatically.
>
> Steps to run Apache Tomcat using Java 8 without reflection
>
> 1. Make sure you have native-image (from the graal installation)
> on your path 2. git clone -b
> feature/embed-minimal-programmatic-jar-file-master
> g...@github.com:fhanik/tomcat.git 3. cd tomcat/res/graal/ 4.
> ./build-tomcat-native-image.sh && ./graal-measure.sh
>
> Should yield an output similar to (Graal 20.1): SUCCESS: the
> servlet is working RSS memory: 20.7M Image size: 20.5M
>
>
> or using an older graal, 19.2 SUCCESS: the servlet is working RSS
> memory: 18.0M Image size: 16.7M
>
>
> This also leaves a file named
> ${java.io.tmpdir}/XReflectionIntrospectionUtils.java so that you
> can review the solution to IntrospectionUtils.java
>
> Goals of this concept
>
> 1. Do not break anything 2. Create a new and optimized for size
> artifact, tomcat-embedded-programmatic 3. Remove reflection by
> introspecting classes that are currently passed into
> IntrospectionUtils.set/getProperty by generating setters/getters at
> build time
>
> How it's done
>
> 1. I've build out a small introspection tool in the package
> org.apache.tomcat.util.xreflect 2. During build time, it analyses a
> set of known classes that are used with IntrospectionUtils.java,
> and generates XReflectionIntrospectionUtils.java 3. When it
> packages tomcat-embed-programmatic.jar it uses the generated code
> when calling setProperty and getProperty
>
> A PR would look like this:
> https://github.com/apache/tomcat/compare/master...fhanik:feature/embed
- -minimal-programmatic-jar-file-master?expand=1

Sounds
>
like a really interesting ApacheCon presentation ;)

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8M5KkACgkQHPApP6U8
pFhhthAAiJjZwWzNNHwx3YQA1J/9sKn2KX50/QrcB+IOkjL8FBbM0bvRCRL1I0ZB
17nQEg5fb7Y+EHOtceYjmJTDrqdj6WIvF60JS5y0E4FUOt0wrqd1v7oTZnKGqgqs
84J8oPW71vpzR/2EL8tzCjn/Oa7rLU58yGtKObBxbgdZcCDa4j0iuklLy6dyktAb
JmxTeHWKmvkezbUKoflydSLb9Dxq7dL2XK2JDGw6iQi4FBiAXleooVw/MpZ1fOAm
jxPjOnf8NhjNoFJooYs/i7H8Oa0MF2BtdrC1qS7gJBJkAp7bOr0HIO2QZLshkSKe
AsC5wp6QfzMWLQsTc25Z5SKGZYNrP6aWkcALYgETjJywDZGmrJ/UO16+zOayqYGq
TvSbE+6+cVzlmj4xMf1UPJf/D9gdpqqWkC/YJpfyZgvqgXkBywbHrSUVyC0AbBKU
REQ6WFNO2idUrZNbmbC0OaLt4BdikjjazhaCoOWQHij83TElQqXCYbH+JcOrc3JE
+9w6Y7fdSwaR+1v2XUUk2McBQtJf9kP7G2iKBYgwrn1JTSrNSB2jvdi5f/HbtGUe
txV6AFJQeFEH/grfHbGeLh21B4UyOa2CkAbAD+dikIJqWBMxvm4DMG1cnJW/x/Rs
vVX3EbVDc6kEBgLQ1blfC7Yl2QdmUap7wP/X399bvH7bmtWJPPI=
=7nG7
-END PGP SIGNATURE-

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



Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

2020-07-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Merlin,

On 7/13/20 06:09, Merlin Beedell wrote:
> Hi all,
>
> Thank you for your valuable assistance and suggestions so far.
>
>
>
> I did eventually try this (again, using ‘groovy’ as a
> simple-to-use scriptable wrapper to Java), which looks like it
> works:
>
>
>
> @Grab(group='com.github.groovy-wslite', module='groovy-wslite',
> version='1.1.3')
>
>
>
> import wslite.rest.*
>
> import wslite.http.auth.*
>
>
>
> RESTClient client = new
> RESTClient("http://localhost:8080/manager;) //or
> https://localhost/manager
>
> client.authorization = new
> HTTPBasicAuthorization("tomcat-users-name",
> "and-corresponding-password")
>
>
>
> def path =
>
"/jmxproxy/?invoke=Catalina:type=ProtocolHandler,port=443=reloadSslHo
stConfigs"
>
> def response
>
> response = client.get(path: path)
>
> println response.text
>
>
>
> And it returns (for example): “*OK - Operation
> reloadSslHostConfigs without return value*”
>
> If the certificate file now no longer exists or is corrupted – we
> get an error response. Thus we know this action provokes the
> certificate file to be re-read.
>
> /However/
>
> If the connector section in server.xml is edited to point to a new
> certificate path/filename, it is ignored.  The current certificate
> config continues to be used.
>
> If the certificate file is replaced by a new certificate, the
> end-user does not see any change – a fresh browser will still see
> the old certificate.
>
>
>
> So: Is there some /other/ action that I need to invoke after the
> reloadSslHostConfigs?  Or to invoke it under a different “mbean
> name”?
>
> When I change the bean name to include *address=127.0.0.1* as per
> your curl example
> (Catalina:type=ProtocolHandler,port=443,address=127.0.0.1) it
> errors.
>
> For example – under the Catalina:type=Connector,port=443 – I see
> operations “destroy / pause / resume / stop / start / init”.
>
> And under the ProtocolHandler I see “findSslHostConfigs / start /
> destroy / pause / resume / getProperty / closeServerSocketGraceful
> / findupgradeProtocols / init”
>
> Would these help?
>
>
>
> The connector config (simple self-signed cert in this case – not
> yet changed to a letsencrypt one) looks similar to this:
>
>  protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementatio
n">
>
>  className="org.apache.coyote.http2.Http2Protocol">
>
>
>
 ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
> honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
>
>  certificateKeystoreFile="C:\opt\certificates\keystore"
> certificateKeystorePassword="passphrase"
> certificateKeystoreType="JKS">
>
> 
>
> 
>
>
>
> And I am trying to reset it to a PKCS12 keystore:
>
>  certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
> certificateKeystorePassword="newpass"
> certificateKeystoreType="PKCS12">
>
>
>
> I’m at a loss to know what to do – other than to abandon SSL
> termination in tomcat and use a proxy to do it instead – that I
> really wish I could avoid.
>
>
>
> Some of my findings from trying to refresh the Tomcat SSL config
> at runtime and trying to decipher the documentation and
> suggestions:
>
> 1. The remote JMX feature does not need to be configured (e.g.
> -Dcom.sun.management.jmxremote.port=9004) if you only need
> localhost management.  But the webapp “manager” does then need to
> be installed – as this acts as the entry point for JMX requests.
> It’s not entirely clear in the documentation about this, nor the
> differences in the format or content of the returned information.
> 2. Not being too familiar with /curl/, I could not determine how
> to pass the manager username / password. 3. Nor is it very obvious
> how interpret the jmx query response in order to form effective
> gets and sets (e.g. the ‘bean name’ to use in a get or set). Nor
> how to obtain operations and parameters.  I see all that stuff if I
> enable remote JMX and use the *JConsole*. But can the manager app
> responses provide the same metadata to determine useful stuff?  I
> also see these messages in a popup window when using JConsole to
> access the operations list: Error setting Operation panel
> :org.apache.tomcat.util.net.SSLHostConfigCertificate
>
> Error setting Operation panel
> :org.apache.tomcat.util.net.SSLHostConfig
>
> Error setting Operation panel :org.apache.coyote.Request
>
> 4. I have used the Tomcat “ant” wrapper for manager. I call the
> ant tasks using ‘groovy’ (just to simplify the preparation of the
> /manager/ web requests and responses). I can use the Query/Get/Set
> calls, but I don’t seem to be able to construct an Invoke
> operation call.  After a lot of trial and error, I gave up using
> this! 5. Re: Tomcat Wiki / Documentation and other cert providers…
> It seems that letsencrypt is currently the only provider with an
> automated update service.  Would be great if they all could – then
> this really could be fully automated (i.e. a tomcat 

Re: [ANN] ApacheCon NA 2020 is virtual/online, completely free to attend, and call-for-presentations is OPEN!

2020-07-09 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 7/8/20 18:37, Christopher Schultz wrote:
> All,
>
> [Cross-posting to dev@, please reply to users@]
>
> ApacheCon NA 2020 is now "ApacheCon @Home" due to the COVID-19
> pandemic, and will be held online 29 September - 1 October 2020.
> This is a great opportunity for anyone who has never attended an
> ApacheCon event to make this year their first ApacheCon.
> Registration is FREE (zero-cost).
>
> For those who have never given a presentation at ApacheCon, this
> is also an opportunity for you to submit a presentation for our
> consideration: the call-for-papers is open and the Tomcat track is
> hoping to fill something like 12 - 36 hours worth of
> presentations, panels, and meet-ups at this conference.
>
> To register to attend or respond to the call-for-presentations,
> please visit https://www.apachecon.com/acna2020/
>
> Because the conference is being held online, obviously things will
> be a little different than previous events. First, all
> presentations will be streamed live and recorded for later replay
> if you can't make a live-streaming event. "Attendance" for a live
> presentation would mean streaming audio/video and at least a text
> channel by which questions can be asked. I don't believe video is
> supported for attendees (to see e.g. attendees faces) but it may be
> possible to ask questions via audio instead text. I will follow-up
> with the organizers regarding audience participation.
>
> To accommodate attendees (and presenters!) in various time-zones
> around the world, we will be attempting to schedule live
> presentations in 4-hour blocks at 3 different daily intervals
> throughout the 72-hour event.

To clarify, here are the presentation blocks we are looking to schedule:

4pm - 8pm China time   (0800 - 1200 UTC)
4pm - 8pm East Europe time (1300 - 1700 UTC)
4pm - 8pm West US time (2300 - 0300 UTC)

(I home my to-UTC math was correct.)

Thanks,
- -chris

> My goal is to encourage each speaker to present their material
> live /twice/ during the event, once in each of two separate
> timezone-centric blocks (e.g. North/South America, Europe/Africa,
> Asia/Oceana) if at all possible, and for several committers to be
> available to "staff" each presentation to introduce speakers,
> provide moderation of questions from the live-audience for the
> speakers, etc.
>
> Schedules will be announced after the presentations have been
> selected and everything is negotiated with the speakers about when
> they are available.
>
> If you are already considering submitting a presentation for
> including in ApacheCon 2020, please head-over to the CFP at
> https://www.apachecon.com/acna2020/
>
> If you aren't sure if you are interested in presenting, or aren't
> sure if you have the experience, knowledge, etc. to warrant a
> position as a speaker, please consider the following:
>
> 1. This is a welcoming community 2. This community exists to serve
> YOU 3. You are a part of this community 4. Helping others within
> the community encourages others to do the same 5. If you'd prefer
> to pre-record your presentation, we can handle that 6. Topics can
> be very wide-ranging. Here are some examples of presentations from
> previous ApacheCon events:
>
> [From Committers / directly about Tomcat] - Running Apache Tomcat
> on GraalVM - Tomcat in clusters and clouds - Using Let's Encrypt
> with Tomcat - Securing Tomcat - Reverse-proxying Tomcat - Load
> balancing with Tomcat - Clustering with Tomcat
>
> [From Non-Committers or not directly about Tomcat] - Packaging
> Tomcat for Linux Distributions - I Love Lucee -- a Java
> implementation of Cold Fusion - Routing CDN traffic at scale using
> Tomcat - Secure Web Applications using Apache Fortress - Monitoring
> Tomcat; various tools - Building Reactive Applications on Tomcat -
> Troubleshooting performance using thread dumps - High Throughput
> Production Systems on Tomcat - Why I Love Open Source -
> Introduction to Spring Boot - Tomcat, TomEE, and Meecrowave
>
> If you are using Tomcat at $work and doing something interesting,
> we'd love to hear about it.
>
> 7. You don't need to be the foremost expert in $feature to talk
> about it 8. We are actively looking for speakers to talk about
> these and other topics:
>
> - How to get started hacking on Tomcat ("How can I help?") -
> Running a "split" Tomcat installation (BASE vs HOME) for easy
> upgrades - Deploying Tomcat in an auto-scaling environment (e.g.
> AWS EBS) - Tomcat should really have [Feature X] - Whatever you
> think might be interesting!
>
> Please consider speaking if you haven't done so before. If you are
> worried about

[ANN] ApacheCon NA 2020 is virtual/online, completely free to attend, and call-for-presentations is OPEN!

2020-07-08 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

[Cross-posting to dev@, please reply to users@]

ApacheCon NA 2020 is now "ApacheCon @Home" due to the COVID-19
pandemic, and will be held online 29 September - 1 October 2020. This
is a great opportunity for anyone who has never attended an ApacheCon
event to make this year their first ApacheCon. Registration is FREE
(zero-cost).

For those who have never given a presentation at ApacheCon, this is
also an opportunity for you to submit a presentation for our
consideration: the call-for-papers is open and the Tomcat track is
hoping to fill something like 12 - 36 hours worth of presentations,
panels, and meet-ups at this conference.

To register to attend or respond to the call-for-presentations, please
visit https://www.apachecon.com/acna2020/

Because the conference is being held online, obviously things will be
a little different than previous events. First, all presentations will
be streamed live and recorded for later replay if you can't make a
live-streaming event. "Attendance" for a live presentation would mean
streaming audio/video and at least a text channel by which questions
can be asked. I don't believe video is supported for attendees (to see
e.g. attendees faces) but it may be possible to ask questions via
audio instead text. I will follow-up with the organizers regarding
audience participation.

To accommodate attendees (and presenters!) in various time-zones
around the world, we will be attempting to schedule live presentations
in 4-hour blocks at 3 different daily intervals throughout the 72-hour
event.

My goal is to encourage each speaker to present their material live
/twice/ during the event, once in each of two separate
timezone-centric blocks (e.g. North/South America, Europe/Africa,
Asia/Oceana) if at all possible, and for several committers to be
available to "staff" each presentation to introduce speakers, provide
moderation of questions from the live-audience for the speakers, etc.

Schedules will be announced after the presentations have been selected
and everything is negotiated with the speakers about when they are
available.

If you are already considering submitting a presentation for including
in ApacheCon 2020, please head-over to the CFP at
https://www.apachecon.com/acna2020/

If you aren't sure if you are interested in presenting, or aren't sure
if you have the experience, knowledge, etc. to warrant a position as a
speaker, please consider the following:

1. This is a welcoming community
2. This community exists to serve YOU
3. You are a part of this community
4. Helping others within the community encourages others to do the same
5. If you'd prefer to pre-record your presentation, we can handle that
6. Topics can be very wide-ranging. Here are some examples of
presentations from previous ApacheCon events:

  [From Committers / directly about Tomcat]
  - Running Apache Tomcat on GraalVM
  - Tomcat in clusters and clouds
  - Using Let's Encrypt with Tomcat
  - Securing Tomcat
  - Reverse-proxying Tomcat
  - Load balancing with Tomcat
  - Clustering with Tomcat

  [From Non-Committers or not directly about Tomcat]
  - Packaging Tomcat for Linux Distributions
  - I Love Lucee -- a Java implementation of Cold Fusion
  - Routing CDN traffic at scale using Tomcat
  - Secure Web Applications using Apache Fortress
  - Monitoring Tomcat; various tools
  - Building Reactive Applications on Tomcat
  - Troubleshooting performance using thread dumps
  - High Throughput Production Systems on Tomcat
  - Why I Love Open Source
  - Introduction to Spring Boot
  - Tomcat, TomEE, and Meecrowave

  If you are using Tomcat at $work and doing something interesting,
we'd love to hear about it.

7. You don't need to be the foremost expert in $feature to talk about it
8. We are actively looking for speakers to talk about these and other
topics:

  - How to get started hacking on Tomcat ("How can I help?")
  - Running a "split" Tomcat installation (BASE vs HOME) for easy
upgrades
  - Deploying Tomcat in an auto-scaling environment (e.g. AWS EBS)
  - Tomcat should really have [Feature X]
  - Whatever you think might be interesting!

Please consider speaking if you haven't done so before. If you are
worried about whether your idea is good enough: don't. Just submit
your idea to the CFP -- you don't have to write-up the presentation in
order to submit an idea, just write a paragraph or two about what you
want to do -- and the track chairpersons (chairpeople?[1]) will decide
whether or not to include your presentation in the event. (And chances
are good that if you submit an idea it will be accepted.)

Please reply to the users list with any questions you may have about
ApacheCon, the Tomcat track, or submitting a talk proposal.

Thanks,
- -chris

On behalf of all ApacheCon 2020 Tomcat Track chairpersons


[1]
https://vignette.wikia.nocookie.net/rickandmorty/images/c/cd/Furniture.p
ng/revision/latest/scale-to-width-down/1000?cb=20160910223642

Re: Improving SameSite support

2020-07-08 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 7/8/20 11:47, Rémy Maucherat wrote:
> On Wed, Jul 8, 2020 at 5:10 PM Christopher Schultz
>  <mailto:ch...@christopherschultz.net>>
wrote:
>
> Rémy,
>
> On 7/8/20 10:35, Rémy Maucherat wrote:
>> On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz
>> > <mailto:ch...@christopherschultz.net>
>> <mailto:ch...@christopherschultz.net
> <mailto:ch...@christopherschultz.net>>> wrote:
>
>>>> Clearly, no, with multiple elements, the digester rules
>>>> added to ContextRuleSet would be something like (in addition
>>>> to the unchanged ones for CookieProcessor):
>>>
>>> digester.addObjectCreate(prefix + "Context/CookieProcessor",
>>>
>>>> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
>>> "className"); digester.addSetProperties(prefix +
>>> "Context/CookieProcessor"); digester.addSetNext(prefix +
>>> "Context/CookieProcessor", "setCookieProcessor",
>>> "org.apache.tomcat.util.http.CookieProcessor");
>>>
>>> digester.addObjectCreate(prefix +
>>>> "Context/CookieProcessor/SameSiteCookie",
>>>
>>>> "org.apache.tomcat.util.http.SameSiteCookie",
>>> "className"); digester.addSetProperties(prefix +
>>>> "Context/CookieProcessor/SameSiteCookie");
>>> digester.addSetNext(prefix +
>>>> "Context/CookieProcessor/SameSiteCookie",
>>> "addSameSiteCookie",
>>> "org.apache.tomcat.util.http.SameSiteCookie");
>>>
>>>> If the bean class is
>>>> org.apache.tomcat.util.http.SameSiteCookie.
>
>> So you are okay with:
>
>> digester.addSetProperties(prefix +
>> "Context/CookieProcessor/SameSiteCookie");
>
>
>> But not with:
>
>> digester.addCallMethod(prefix +
>> "Context/CookieProcessor/SameSiteCookie/Cookie");
>
>> ?
>
>
>> The digester works best with beans so I don't see what is so
>> surprising about this.
>
> What's surprising is that you are -1 to what I see as an
> improvement to Tomcat without much in the way of disruption. I
> think it's pretty clean.
>
> Would proposing an actual patch help, or will you still be -1 on
> anything other than a complicated "sameSiteCookies" string value
> which needs to be unpacked by Tomcat code rather than using
> standard XML element/attribute syntax?
>
>
>> The digester rules I posted add a new SameSiteCookie element I
>> only>> mentioned a complex sameSiteCookies attribute syntax once
>> (I considered it would be better for API compatibility; the
>> CookieProcessor API should not break in Tomcat 9 when things are
>> backported, or the feature would be limited to Tomcat 10) but I
>> didn't mention it again since you did not like it.

I can't tell you if you are saying you'd be -1 to add that new
SameSiteCookie element (because it is "too big a change", or because
it requires "changes to digester configuration"), or that you are -1
to use digester.addCallMethod (because you don't like it), or that you
are -1 to really supporting any improvements to SameSite at all.

Can you clarify?

I won't waste my time if you are going to -1 anything I do, here.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8GFogACgkQHPApP6U8
pFg1UQ/+M9SU2f9YkLUnRU0f2MqdIwKFguLHFfFxZSnxoEOhIVJOmJbm5YrZlwIv
skzgJiPvX7wMWfq0wO8mc/ALjOAn/XhEE66sIWZe9bc9Hte0mrXHV8wmHZXhTW+O
LqLNGJgXH/m8Mxui27h2EfpRXYDEKEGLUU71j3NMOxd6xa0xfYv/MiBI3asMZpvQ
k688fWGa4EeoTj4yRtR+eIOYpcPFZlaT+uNFGPNr7HVMvSB0SAx/Ui732bMEXpRT
2CRaPSZ4TAFBhZLNXxfBodErGWA6QHQPgnPgB0oPbCM78R0zldVyXLMRpksZL/V7
Dx6cJE/Da7fISufomcMsdrpFmQ3LylXbKNTdbkzlDT9hdpgSn7kc4tDYJzwTt0NS
K2/fbi8gQOEg7VB6pRVeXxODhEovFizEKfuGhwFNyuw7q0cxK+w6W+zFdu+wgcj/
Epa/XDmtuKz5doGOnuwzpudf3For8rdVpdpmRUU7+1PiLX6xsj2cueY1ku7e45LL
ZR9cMGkW/sEU1oWw2HKM3fMqAuZEkFiNvYhua/KM6tVbqFXC49GeF+K+qe/zx2DK
W+xrPOnQ2A4viyLVAFbidPkxemdnp5VX+VXeXvgmCeRmsmWqvza73UJzf1Es4qg5
inLHbksUnsokixJHF2KwbsFFdubldl5HogNIpExmwwlb9Eg2fFI=
=j71t
-END PGP SIGNATURE-

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



Re: Improving SameSite support

2020-07-08 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 7/8/20 10:35, Rémy Maucherat wrote:
> On Wed, Jul 8, 2020 at 4:26 PM Christopher Schultz
>  <mailto:ch...@christopherschultz.net>> wrote:
>
>>> Clearly, no, with multiple elements, the digester rules added
>>> to ContextRuleSet would be something like (in addition to the
>>> unchanged ones for CookieProcessor):
>>
>> digester.addObjectCreate(prefix + "Context/CookieProcessor",
>>
>>> "org.apache.tomcat.util.http.Rfc6265CookieProcessor",
>> "className"); digester.addSetProperties(prefix +
>> "Context/CookieProcessor"); digester.addSetNext(prefix +
>> "Context/CookieProcessor", "setCookieProcessor",
>> "org.apache.tomcat.util.http.CookieProcessor");
>>
>> digester.addObjectCreate(prefix +
>>> "Context/CookieProcessor/SameSiteCookie",
>>
>>> "org.apache.tomcat.util.http.SameSiteCookie",
>> "className"); digester.addSetProperties(prefix +
>>> "Context/CookieProcessor/SameSiteCookie");
>> digester.addSetNext(prefix +
>>> "Context/CookieProcessor/SameSiteCookie",
>> "addSameSiteCookie",
>> "org.apache.tomcat.util.http.SameSiteCookie");
>>
>>> If the bean class is
>>> org.apache.tomcat.util.http.SameSiteCookie.
>
> So you are okay with:
>
> digester.addSetProperties(prefix +
> "Context/CookieProcessor/SameSiteCookie");
>
>
> But not with:
>
> digester.addCallMethod(prefix +
> "Context/CookieProcessor/SameSiteCookie/Cookie");
>
> ?
>
>
> The digester works best with beans so I don't see what is so
> surprising about this.

What's surprising is that you are -1 to what I see as an improvement
to Tomcat without much in the way of disruption. I think it's pretty
clean.

Would proposing an actual patch help, or will you still be -1 on
anything other than a complicated "sameSiteCookies" string value which
needs to be unpacked by Tomcat code rather than using standard XML
element/attribute syntax?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8F4eMACgkQHPApP6U8
pFhhkxAAgQdr7vdbaO0qeWHPbKdh2hcy5NuKMOozOWaERHowTsx3yv9rHfiVKaXG
gti6mzcLIqXMPiMbqCE+fYpOCAfqJsAtjjg3zWs9Sh1vk7HOrOmZ7V2s5bbvjeqe
zCcrgdC+PKMO9Up/OWdwfAj8oARhtYFfTQfgoEiT61ElDYNnCU+swuDh9CZwJpv0
HzQ+U+kEEYpgZrawzuk4xCvOSk+HKNAcG5LDphYgLUGUNg3Eq7tlvzDSQ/PX1Hbd
VFHipCk4pDcRgvFq9GYK3b81QAlxcizFOW129+CPRSYINg1ztomv1Gqw+JXiwnG5
YCcd6LaBT0fn3SldtE/rWNZResK3qnQG0aeAFvdl1qzzWvOSMMzyuJB7XMxkRlTZ
lo3w7nJ9dJ4RdtjSshuBj6vrjFxqmAexbhy+e/aWmjKjjuEPl9oZx7jYbGKg79ER
Bn+6nkUEP7YxBMSg9LTqFJvzGw6PPplunn6MTef7PZYpj9qwJh5xg2AXGZqrndmD
XaowT4zNASfguq34BxmACWkqQrc6+3Wvdutafz7yvr0yxrvZz2+pmT6fJ9C6nBQO
4xyqxYRUa+Bt+4b2ppAzrVIJ+egk+6tbcUiqxMvbH1RV7GD+rwyEI5DRtv1RsTiw
lCI9Y4K3R2a1pEN/0nArQrkBAzEttlxTPoZ9eJyUxsuVXtLor6g=
=lUHF
-END PGP SIGNATURE-

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



Re: Improving SameSite support

2020-07-08 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 7/8/20 10:20, Rémy Maucherat wrote:
> On Wed, Jul 8, 2020 at 4:14 PM Christopher Schultz
>  <mailto:ch...@christopherschultz.net>>
wrote:
>
> Rémy,
>
> On 7/8/20 04:16, Rémy Maucherat wrote:
>> On Tue, Jul 7, 2020 at 4:26 PM Christopher Schultz
>> > <mailto:ch...@christopherschultz.net>
>> <mailto:ch...@christopherschultz.net
> <mailto:ch...@christopherschultz.net>>> wrote:
>
>> Rémy,
>
>> On 7/7/20 03:10, Rémy Maucherat wrote:
>>> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
>>> >> <mailto:ch...@christopherschultz.net>
>>> <mailto:ch...@christopherschultz.net
> <mailto:ch...@christopherschultz.net>>
>>> <mailto:ch...@christopherschultz.net
> <mailto:ch...@christopherschultz.net>
>> <mailto:ch...@christopherschultz.net
> <mailto:ch...@christopherschultz.net>>>> wrote:
>
>>> All,
>
>>> Jakarta EE 5.0 does not appear to include support for SameSite
>>> cookies. Tomcat's CookieProcessor allows an administrator to
>>> set the SameSite cookie policy, but it's a blanket policy.
>
>>> So for example, if you want a JSESSIONID cookie to be "strict"
>>> but some other cookie (e.g. "FOO") to be "unset" or "lax" or
>>> whatever, you will have to manually-build your "Set-Cookie"
>>> headers for your FOO cooki e.
>
>>> This is not terribly convenient.
>
>>> Unfortunately, *any* solution to this problem will be
>>> container-specific. The current Tomcat solution is of course a
>>> solution only for Tomcat, and only for versions which contain
>>> that SameSite support.
>
>>> I'm wondering if we can do better.
>
>>> Instead of a single "sameSiteCookies" setting which applies to
>>> *all* cookies, perhaps the CookieProcessor could have a
>>> different policy for specific cookies. Something like this:
>
>>> >> className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
>>> sameSiteCookies="unset"> >> cookieName="JSESSIONID" policy="strict" /> >> cookieName="FOO" policy="lax" /> ... 
>
>>> In the above setup, the "sameSiteCookie" attribute of the
>>> CookieProcessor sets the default policy for the
>>> CookieProcessor. Then, each of the  elements
>>> sets the policy for a specific cookie by name.
>
>>> This would allow applications to set their policies without
>>> having to construct their own Set-Cookie response headers,
>>> handle encoding, etc. and it would also inherit any other
>>> Tomcat-supplied cookie-related policies.
>
>>> Another option would be to provide a subclass of j.s.h.Cookie
>>> which includes a setSameSite(String) method. The
>>> CookieProcessor could check for instanceof EnhancedCookie (or
>>> whatever) and use that setting for each Cookie object. But that
>>> seems like less of a good idea -- except that it would be
>>> easier for refactoring tools to locate instances of the
>>> Tomcat-specific Cookie class and replace them with a future
>>> SameSite-supporting official Jakarta EE Cookie class.
>
>>> WDYT?
>
>
>>>> This is a big configuration and API change. Adding a new
>>>> element is significant, so maybe an expanded syntax could be
>>>> added to the attribute instead (ex:
>>>> "unset,JSESSIONID=strict,FOO=lax"; or maybe a more compact
>>>> "unset;strict=JSESSIONID,FOO;lax=BAR"). It's still a
>>>> breaking change though.
>
>> I think it's *either* an API change *or* a configuration change,
>> not both, and it can be done in a backward compatible way.
>
>> Using a single "complex" configuration value makes it difficult
>> or impossible to write an XML schema for validation. Not
>> critical, but it's a consideration IMHO.
>
>> Nobody HAS to use e.g. a new Cookie class and/or new
>> configuration. My proposed configuration remains
>> backward-compatible because the sameSiteCookies attribute sets
>> the default policy and it's only overridden if you supply some
>> cookie-specific configuration.
>
>> I don't think adding a new XML element as a child of
>> SameSiteCookies is a huge deal: it just requires a bit of
>> Digester configuration and a method to append custom
>> configuration to SameSiteCookies. A quick change to
>> *CookiePro

Re: Improving SameSite support

2020-07-08 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 7/8/20 04:16, Rémy Maucherat wrote:
> On Tue, Jul 7, 2020 at 4:26 PM Christopher Schultz
>  <mailto:ch...@christopherschultz.net>>
wrote:
>
> Rémy,
>
> On 7/7/20 03:10, Rémy Maucherat wrote:
>> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
>> > <mailto:ch...@christopherschultz.net>
>> <mailto:ch...@christopherschultz.net
> <mailto:ch...@christopherschultz.net>>> wrote:
>
>> All,
>
>> Jakarta EE 5.0 does not appear to include support for SameSite
>> cookies. Tomcat's CookieProcessor allows an administrator to set
>> the SameSite cookie policy, but it's a blanket policy.
>
>> So for example, if you want a JSESSIONID cookie to be "strict"
>> but some other cookie (e.g. "FOO") to be "unset" or "lax" or
>> whatever, you will have to manually-build your "Set-Cookie"
>> headers for your FOO cooki e.
>
>> This is not terribly convenient.
>
>> Unfortunately, *any* solution to this problem will be
>> container-specific. The current Tomcat solution is of course a
>> solution only for Tomcat, and only for versions which contain
>> that SameSite support.
>
>> I'm wondering if we can do better.
>
>> Instead of a single "sameSiteCookies" setting which applies to
>> *all* cookies, perhaps the CookieProcessor could have a
>> different policy for specific cookies. Something like this:
>
>> > className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
>> sameSiteCookies="unset"> > policy="strict" /> > /> ... 
>
>> In the above setup, the "sameSiteCookie" attribute of the
>> CookieProcessor sets the default policy for the CookieProcessor.
>> Then, each of the  elements sets the policy for
>> a specific cookie by name.
>
>> This would allow applications to set their policies without
>> having to construct their own Set-Cookie response headers,
>> handle encoding, etc. and it would also inherit any other
>> Tomcat-supplied cookie-related policies.
>
>> Another option would be to provide a subclass of j.s.h.Cookie
>> which includes a setSameSite(String) method. The CookieProcessor
>> could check for instanceof EnhancedCookie (or whatever) and use
>> that setting for each Cookie object. But that seems like less of
>> a good idea -- except that it would be easier for refactoring
>> tools to locate instances of the Tomcat-specific Cookie class and
>> replace them with a future SameSite-supporting official Jakarta
>> EE Cookie class.
>
>> WDYT?
>
>
>>> This is a big configuration and API change. Adding a new
>>> element is significant, so maybe an expanded syntax could be
>>> added to the attribute instead (ex:
>>> "unset,JSESSIONID=strict,FOO=lax"; or maybe a more compact
>>> "unset;strict=JSESSIONID,FOO;lax=BAR"). It's still a breaking
>>> change though.
>
> I think it's *either* an API change *or* a configuration change,
> not both, and it can be done in a backward compatible way.
>
> Using a single "complex" configuration value makes it difficult or
> impossible to write an XML schema for validation. Not critical,
> but it's a consideration IMHO.
>
> Nobody HAS to use e.g. a new Cookie class and/or new configuration.
> My proposed configuration remains backward-compatible because the
> sameSiteCookies attribute sets the default policy and it's only
> overridden if you supply some cookie-specific configuration.
>
> I don't think adding a new XML element as a child of
> SameSiteCookies is a huge deal: it just requires a bit of Digester
> configuration and a method to append custom configuration to
> SameSiteCookies. A quick change to *CookieProcessor.generate() to
> check for custom settings would be easy, tool. (I'd suggest that
> the code be refactored so that the SameSiteCookies class returns
> the proper SameSite cookie attribute (or null/blank) so that each
> CookieProperssor doesn't have to repeat the logic.)
>
>
>> If new elements are added, they need to correspond to an object
>> structure (= there needs to be a SameSiteCookie object with
>> fields "cookieName" and "policy" being added to a map in
>> CookieProcessorBase).

The SameSiteCookies class already exists, and it can have a field and
method added (e.g. addCookie(String cookieName,String policy)). The
SameSiteCookies object can manage the policies and the CookieProcessor
classes can delegate the policy decisions to the SameSiteCookies object.

>> I am 

Re: Improving SameSite support

2020-07-07 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 7/7/20 03:10, Rémy Maucherat wrote:
> On Mon, Jul 6, 2020 at 9:27 PM Christopher Schultz
>  <mailto:ch...@christopherschultz.net>>
wrote:
>
> All,
>
> Jakarta EE 5.0 does not appear to include support for SameSite
> cookies. Tomcat's CookieProcessor allows an administrator to set
> the SameSite cookie policy, but it's a blanket policy.
>
> So for example, if you want a JSESSIONID cookie to be "strict" but
> some other cookie (e.g. "FOO") to be "unset" or "lax" or whatever,
> you will have to manually-build your "Set-Cookie" headers for your
> FOO cooki e.
>
> This is not terribly convenient.
>
> Unfortunately, *any* solution to this problem will be
> container-specific. The current Tomcat solution is of course a
> solution only for Tomcat, and only for versions which contain that
> SameSite support.
>
> I'm wondering if we can do better.
>
> Instead of a single "sameSiteCookies" setting which applies to
> *all* cookies, perhaps the CookieProcessor could have a different
> policy for specific cookies. Something like this:
>
>  className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
> sameSiteCookies="unset">  policy="strict" />  /> ... 
>
> In the above setup, the "sameSiteCookie" attribute of the
> CookieProcessor sets the default policy for the CookieProcessor.
> Then, each of the  elements sets the policy for a
> specific cookie by name.
>
> This would allow applications to set their policies without having
> to construct their own Set-Cookie response headers, handle
> encoding, etc. and it would also inherit any other Tomcat-supplied
> cookie-related policies.
>
> Another option would be to provide a subclass of j.s.h.Cookie
> which includes a setSameSite(String) method. The CookieProcessor
> could check for instanceof EnhancedCookie (or whatever) and use
> that setting for each Cookie object. But that seems like less of a
> good idea -- except that it would be easier for refactoring tools
> to locate instances of the Tomcat-specific Cookie class and replace
> them with a future SameSite-supporting official Jakarta EE Cookie
> class.
>
> WDYT?
>
>
>> This is a big configuration and API change. Adding a new element
>> is significant, so maybe an expanded syntax could be added to the
>> attribute instead (ex: "unset,JSESSIONID=strict,FOO=lax"; or
>> maybe a more compact "unset;strict=JSESSIONID,FOO;lax=BAR"). It's
>> still a breaking change though.

I think it's *either* an API change *or* a configuration change, not
both, and it can be done in a backward compatible way.

Using a single "complex" configuration value makes it difficult or
impossible to write an XML schema for validation. Not critical, but
it's a consideration IMHO.

Nobody HAS to use e.g. a new Cookie class and/or new configuration. My
proposed configuration remains backward-compatible because the
sameSiteCookies attribute sets the default policy and it's only
overridden if you supply some cookie-specific configuration.

I don't think adding a new XML element as a child of SameSiteCookies
is a huge deal: it just requires a bit of Digester configuration and a
method to append custom configuration to SameSiteCookies. A quick
change to *CookieProcessor.generate() to check for custom settings
would be easy, tool. (I'd suggest that the code be refactored so that
the SameSiteCookies class returns the proper SameSite cookie attribute
(or null/blank) so that each CookieProperssor doesn't have to repeat
the logic.)

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8EhfEACgkQHPApP6U8
pFhXkxAAje++q65o9aq3L61hG+2y3B8yY+kFdiE+PwyvsVqbikHCSWNCVC3s8bpn
W56cYtajSGCItQvdrZfi76TowY2tnZHbzcJcquk6WMph/24nVMCekJ66ypQ3T1Hq
v6sn4sN8PZh8n3KoomeW2vy3oknbh0wX4IoTID333t02X15qdZbkngMmwouodH7d
aKF0yI2zBasz4J3XmCKWp/w7kfptp7Lf4TmxBcyEFJ1YKgQGMQCvQWUq6nBG9s6x
lt3fJJxNj44TtLQhu1k7LV/yesVO5V7IDQmvM7QfHo2Ny1M6eeMIMK2Yfelwa0uR
3yA5AmcVAVxh2d2PXKDJs1iy6u5hXZJtdXcPwE5qoTA9i4Au8SMDwJZPTmFlwPYc
NBsJWW4ahXFgcg+TyEZ1qSdk0HOsIrj21gLcsKZ6JMeu0mW2XZ1ekDS49+cBiXon
IUP7gfvMpGrp1eNbu6qVS6V8Odg1f11+iEC4w7gEhRER3KluHA9ujhMTR3lzR9ns
FcSmt16S6MNr1PK/5is2pNp4vFeGFVFUxvXxEt4SJGshF+WPrxDnWkCSs/hlRXR9
4bhUbXaBQuf827B4rONNepUf+fXoUQHkRmLcXFSF5Gx6rdtl1xm+OP9cPm+D0k6x
VAh5pLoXRtFv4NTMFyftBUVk0Kcm7EAsCwKbhDTEh8vsCKGFRTo=
=0n3F
-END PGP SIGNATURE-

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



Re: Catalina internals available from HttpServletRequest?

2020-07-07 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 7/6/20 16:45, Mark Thomas wrote:
> On 06/07/2020 21:23, Christopher Schultz wrote:
>> All,
>>
>> I'm looking at modifying the existing LoadBalancerDrainingValve
>> to also function as a Filter if necessary (my application uses a
>> Filter to establish authentication information, so I'd like the
>> "valve" to act *after* the filter if possible) and it looks like
>> I need access to some Tomcat internals.
>>
>> Specifically, I'd like to be able to get to the
>> org.apache.catalina.Context object for the request. Is this
>> available without reflection and/or other ugly things?
>>
>> Hmm. It looks like a Valve *cannot* be a Filter because of the
>> presence of the incompatible destroy() method.
>>
>> I still want to provide a Filter if possible, so the above
>> question still stands.
>>
>> If the Context isn't available, could it be added to the
>> ServletContext attributes, possibly under a non-reported hash
>> key?
>
> That would create security issues.
>
> A Filter equivalent to ContainerServlet could work - although that
> is a fairly invasive change for something that could be fixed more
> easily.
>
> How about a Valve that injects the necessary internal object(s) as
> request attributes? Alternatively, you could inject some custom
> object that held the references internally and just exposed the
> functionality you wanted to expose.

The calls I'm having trouble with are similar to this one:

if (drain) {
boolean ignoreRebalance = false;
Cookie sessionCookie = null;

final Cookie[] cookies = request.getCookies();

final String sessionCookieName =
SessionConfig.getSessionCookieName(request.getContext());


That last call to request.getContext is calling
o.a.c.connector.Request.getContext to hand to
SessionConfig.getSessionCookieName.

This valve also does something similar for
SessionConfig.getSessionCookiePath and
SessionConfig.getSessionUriParamName.

I could read those values from elsewhere (e.g. during startup?), or
even make them init-param of the Filter and avoid the whole thing, but
that does require some additional configuration. The valve is nice and
magical :)

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8EgfoACgkQHPApP6U8
pFhQaw/9GS6/JH7IGNMhbuRMHwdYBlCLam9cBZuEz1tiJW4F+hk7kr7/phGJu+Sy
DAHPGMIlUpcSaH0KoPnE2OWzM0xqBJydIuoI+pydc1/MEPNVDD/uUbvHyIacRWoa
ucgYbwDDq8n23cujJYstvm4MJBcFOhxgnyaG+XFSUuDUZARCw6hXSJx7kxr+V07z
4K0P0wcYUisPzN3bFQhzRanJ494izfYz0w7AybnmWYPLmBEX5PObt3aYCW6ZaTXs
ajQjyg441pSFkjk1F6MeYJSbAFW+aomU9zrgTgHEcZJ1OkZG6EwS0dD2tbDi7vVU
Ns1jjxDD0ZPgHI9rkiFzhI1gb38/HmbgeU2AIF64r3DIol9/d2R/6bYS5yh6jMXl
1ne5XIXlNq8SLMvbcbCtHE4t5hfKgCQ54jsAY7tgHCRbixwJnftUQMYCfmImuIko
NAQ3BzZw3P04XGXPEDZ0NqKvplxV/yoAf/BtD1xE6bySPoXbrx2UMDEIHU5zeiP8
xH5JC9Dg0Qz6yAEKQd1Sk9BrxmY3Fr4spnVTcuU/fU7OSWF+1vf0wTZ1CT/JcQmB
aYvTQcGYjxi9GynZKDS6TM1kAenul5QF5sDLmLMGtXpzSXjMKK0IEKhpXlG2013F
ktDMhbaM4tXAmZr3lBjpYwYiWSFCZ7tJDflO2EAHbGXweU+ehkQ=
=eS0L
-END PGP SIGNATURE-

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



Catalina internals available from HttpServletRequest?

2020-07-06 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm looking at modifying the existing LoadBalancerDrainingValve to
also function as a Filter if necessary (my application uses a Filter
to establish authentication information, so I'd like the "valve" to
act *after* the filter if possible) and it looks like I need access to
some Tomcat internals.

Specifically, I'd like to be able to get to the
org.apache.catalina.Context object for the request. Is this available
without reflection and/or other ugly things?

Hmm. It looks like a Valve *cannot* be a Filter because of the
presence of the incompatible destroy() method.

I still want to provide a Filter if possible, so the above question
still stands.

If the Context isn't available, could it be added to the
ServletContext attributes, possibly under a non-reported hash key?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8DiCYACgkQHPApP6U8
pFh3KA//X9HEOKbQPvMJ981Zo0xzIaPvM3t2RqCDJPxVqGi2A0URPAEuIy13eSNu
oApBBMetDHCwYKZ6T6gzPzCR9JUm6xzCu8jBXP0spqlockQqFM5jW6CIBJxoWeWn
uFujY8hnh4wY0K3c7seIkvsogiaNHnCSZPl/0rIEhk2KVI+Loh0KhywURDgLvCab
Flry3UaKxt3j+PEat1wlL2NCVJGtNHnxukQIKfMUl0LuolYlq99mfP/qzfvmt2q/
9ALVvSjQ8++xurIeIS1O1d9QaJWai1maxAxUssdIAodDm4iSot1vdJGMWdojuYur
bctZniM2c2zJfLCQE6OtdLzFpppjLVYpXNkJCRn7QdaN6SLTdl5jL8itdsHrtSsV
9kyebADc9iqF6GoX2Q5EfAC2DbIuwG5DqofSeha8gByMSwT2/dv6bQjybKVCiSOL
bS1HF03XxnNGm8txfwyBCHvbz0j7NcGxWm/qdN0DbT4bYTPozYbj4xkyabbsqTw1
4vD2/qGncH3M9npRMYq1qf5DG+js0RnGj+Vx9F6XDV7KEc9WEYrvBxj5zdDjfxlV
xwJIr7Tn9o4Fa9uRO8WpvJap/qS1wZ31uXQJXIqps8foizefBtewocKYFIegtOG1
CTe5GiBBRDrJezx+gLTxPLlgCrOCp9OTboWNWSQprtMwyCiTekA=
=J09l
-END PGP SIGNATURE-

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



Improving SameSite support

2020-07-06 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Jakarta EE 5.0 does not appear to include support for SameSite
cookies. Tomcat's CookieProcessor allows an administrator to set the
SameSite cookie policy, but it's a blanket policy.

So for example, if you want a JSESSIONID cookie to be "strict" but
some other cookie (e.g. "FOO") to be "unset" or "lax" or whatever, you
will have to manually-build your "Set-Cookie" headers for your FOO cooki
e.

This is not terribly convenient.

Unfortunately, *any* solution to this problem will be
container-specific. The current Tomcat solution is of course a
solution only for Tomcat, and only for versions which contain that
SameSite support.

I'm wondering if we can do better.

Instead of a single "sameSiteCookies" setting which applies to *all*
cookies, perhaps the CookieProcessor could have a different policy for
specific cookies. Something like this:


  
  
  ...


In the above setup, the "sameSiteCookie" attribute of the
CookieProcessor sets the default policy for the CookieProcessor. Then,
each of the  elements sets the policy for a specific
cookie by name.

This would allow applications to set their policies without having to
construct their own Set-Cookie response headers, handle encoding, etc.
and it would also inherit any other Tomcat-supplied cookie-related
policies.

Another option would be to provide a subclass of j.s.h.Cookie which
includes a setSameSite(String) method. The CookieProcessor could check
for instanceof EnhancedCookie (or whatever) and use that setting for
each Cookie object. But that seems like less of a good idea -- except
that it would be easier for refactoring tools to locate instances of
the Tomcat-specific Cookie class and replace them with a future
SameSite-supporting official Jakarta EE Cookie class.

WDYT?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8DexAACgkQHPApP6U8
pFjDZBAAiaKBAla3DJ+SHvHTkADOeGXqrMX9kbrIZB3ajnq+m4MEWPH6dmQrg9+j
ROcPVNsj8gahrJSWEzvdu7bQc96tWQ8RD265DQ1pbjwNCfWGHMM8FPJaRp4DO7av
zvWMtNLI/Sv+63CmZr27mzE1o/iJturdNAu/12kOUDd5RVVnM8CROKVtE5rmbVN8
dFQIuMD6mQov+J+Eqg6sqJLPVNoxcjRo25QsrfEOUnsbXx+0sHCe0QMiv4wgMf3G
LnPEY7GhOBOcjaN6lWENAWAkeuoUZIlVpbndk6RRihziSGNAZ+uNORy54mP8SGkR
z33lWKMIolYBBqcmvuFy7OOsfdLGI50kUIc05Hd+T9XMO4p7OSOeJDwvGTmN6Kie
2ZChodQYnWEN//VrD0UxN7t4rlujXF0sS40hryoehzDge/UjVFabR/nEKsySWigR
eddvNhumWqxtjEt8K+/5um366ybVr6VkzpaGfBZ6inzYZtmLmMNr1xd/hz9V5c7j
4KZiGvB5qxZpcrNtmiYJHYzEE8PHauGsEUzG08Skd4SJmo6TkyvefdnaPHezNOse
Ikd78TLvPLNMEE2dUqZ508wYTmR14/ZEiEOt2IUYHD1Dk1oFOgmnR8jbG6+ONZMp
Fjmv5qWfAAeGmWsuMUCHpiz0w3LGJGGlrLur1NXwLkhtz+epx4M=
=dJAO
-END PGP SIGNATURE-

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



Re: [tomcat] branch master updated: Use StringBuilder instead of StringBuffer

2020-07-06 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 7/6/20 03:09, mgrigo...@apache.org wrote:
> diff --git
> a/java/org/apache/catalina/connector/CoyotePrincipal.java
> b/java/org/apache/catalina/connector/CoyotePrincipal.java index
> 1ae5608..93d7c02 100644 ---
> a/java/org/apache/catalina/connector/CoyotePrincipal.java +++
> b/java/org/apache/catalina/connector/CoyotePrincipal.java @@ -64,7
> +64,7 @@ public class CoyotePrincipal implements Principal,
> Serializable { public String toString() { StringBuilder sb = new
> StringBuilder("CoyotePrincipal["); sb.append(this.name); -
> sb.append("]"); +sb.append(']'); return sb.toString(); }

Might I suggest further improvements?

Step 1:

  public String toString() {
  return new StringBuilder("CoyotePrincipal[")
  .append(this.name);
  .append(']');
  .toString();

It turns out that the generated bytecode is something like 2/3 as long
as the sb.append(); sb.append(); sb.append(); code. JIT probably does
the same thing eventually, but why not help it out?

Step 2:

  public String toString() {
  return "CoyotePrincipal[" + this.name + ']';
  }

This has a few advantages:

1. It's dead easy to read

2. The compiler makes the best decision as to how to perform the
concatenation

In very old versions of Java, you'll get StringBuffer concatenation as
the pre-commit version. Later versions get you StringBuilder as
post-commit version. Post 9.x-versions get you a call to
StringConcatFactory.makeConcatWithConstants which is presumably even
more efficient.

I understand that this was supposed to be a small patch, but I think
further improvements are possible in many cases like this one.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8DMT8ACgkQHPApP6U8
pFgUtA/+OoHnIgHBLoIOXqP5t10g/dBFxGrIpOUOe1MvIhWMdObcNIlZmnM1vv0Z
xCRYXxGCj20xm4P/NEzvRlEPWfd0uvoZczr34JVPlgOWUBJeRHmLQ+KlGdCeuuKk
cmxV4ZXZSt8bzVMufQ+N2RPOCGUvti2kin0CSj9BlygKuTAMuXgwVcyEo7XvLf3z
153dHylBL3ka5jo2lR4vYlj8U6PvzoZuLj3NAnrRZP3YttbQKimhXDcOg7zkeVP+
GFINDBE+fux+s5P38vqRLqzA4JEDFfjsKzT4JV21BrSbxhdUbXyYE4RMhW+izKB8
B/SJhBtEN1huED3GkZbg/DN0nYgY4vVeoHz4kdal1E5uVybG5SLj6xoz6tkRsayB
pOHguW1ds8NLPJwHBEATq6YQOXGfqECbW+iWuP54F7eBzo57CiZWsnQPalpSo9pn
mdBRbcfyI7z9vJFaiGCpudKGKK5+F1VFj6KELxZP7nAO0Lyhwapsai9TzLXLOTk1
8ReS5GENoZDrzrb3Gn/YCmdYAxdED9ejjkiY5qVjX3ZXWXaeytcz1h3bY2opV4Ks
a+tahArWqI1t44cemejJuiXFZB0xrDjji6pnd3ZqZ4vG1TREKxK2hdLjuwP3vaw9
fqt4d3E596rPtqF2e0aJLGfW+3iJ2r67c7DP9ARHMAdadMIi23U=
=N+0c
-END PGP SIGNATURE-

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



Better handling of AJP errors if corruption is discovered?

2020-07-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I recently had the displeasure of tracking-down a mismatched AJP "max
packet size" on a service. The symptom was that when a large POST
request came in ( > 8192 bytes ), Tomcat would log two errors in quick
succession:

1. org.apache.catalina.connector.ClientAbortException:
java.io.IOException: Invalid message received with length [-1]
at
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java
:348)
at
org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer
.java:663)
at
org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:370)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.j
ava:183)


and then immediately:

2. java.lang.IllegalArgumentException: Header message of length
[8,194] received but the packetSize is only [8,192]
at
org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:685)
at
org.apache.coyote.ajp.AjpProcessor.receive(AjpProcessor.java:626)
at
org.apache.coyote.ajp.AjpProcessor.refillReadBuffer(AjpProcessor.java:73
4)
at
org.apache.coyote.ajp.AjpProcessor$SocketInputBuffer.doRead(AjpProcessor
.java:1456)
at org.apache.coyote.Request.doRead(Request.java:581)
at
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java
:344)
at
org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer
.java:663)
at
org.apache.catalina.connector.InputBuffer.readByte(InputBuffer.java:358)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.j
ava:93)

It's strange to see the "invalid length" message at all IMO; I would
have expected only to see the "message is too big" error.

Is it possible to kind of merge these two errors together?

When this happens, what happens to the AJP connection? Assuming there
is a very large request coming-in and it takes e.g. 3 chunks of 64k
followed by a smaller chunk, will Tomcat throw an error for each of
the chunks, or will the connection be dropped and the request fail?

I'm actually having trouble reproducing this right now or I would have
simply tried it myself.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7+NdkACgkQHPApP6U8
pFi6PhAAmP8mLKHjaDdCX9tRYDXOFDq/Y4qA/Y9lG2giMpI+/3SZU0DTS4SS4v8K
vgX/3E6bG2y8HDTZeNJu6GX/bYizLTnegp3bkZC+S8feTOHB92BoGDLFNjqkar6R
eCqPcWHjMSj1jUfGa1cLgVuvb97euPyQHKdiAq8eimu+jMT3EDcXuvuYztt/eFq/
/br7Kf60weArq19QKPVDakyzw5ONvjo046QKjpPMemLzS2DBIAJocjAXJzXEHwnv
wiD5eeSrFu83SDSXgEIjFi9TGXctAUhbgEJJV8GcSQc/t82VpGN+in8sOkPi7ZaT
JbXFSOFvYsCOwaCQPGpiD7oxozxp3i8i4W+x8UVnDiVK1UROTypk1CYEcorbBkgl
TJqZHPaFh3734C5F8RJNSk5juz/+eFTZJ/GxLo0Pp2NvCJsXLm/XdGSxZtGrW14j
K8LD1ylD7ULv28BI9iBzQ/PO2qahEVGb35hT7J7E9NJKA1lOdDJug69GSjDOkurw
M9MHNM0dyohsHN6X0KZoshmkToLBx1dBqfnvgjnKgc/RXmfRl0V+Xsa70kvNoGdd
RETgya5hFASD4FWkp+L4UCIqjH5GYxwGOyIKNBZveeOtQv+1KyxEzHqr8rI1aQXT
Q91qEZXtoofR+Agt5cODbqGj0n6m6KcmFW9bnpwt2+qLoRdL9p0=
=Lqqj
-END PGP SIGNATURE-

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



Re: Changing the name of the default branch in our git repos

2020-06-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/26/20 10:48, Mark Thomas wrote:
> Picking up this thread again I see a range of views. "main" seems
> to be the most popular although several folks suggested "10.0.x"
> and "use whatever GitHub use". There was also interest in "trunk".
> Particularly with the additional suggestion of "10.0.x" appearing
> in the middle of the discussion, I'm not sure where consensus lies
> at the moment.
>
> One suggestion I particularly liked was to do the rename at the
> point we branch 10.0.x and start on 10.1.x since we will need to be
> updating CI and various things anyway. That is currently looking
> like September as that is the target date for the Jakarta EE 9
> release.
>
> I suspect that this could get tricky as I'd prefer "main" or
> "10.0.x", could work with "trunk" but really don't want to continue
> with "master". I imagine others have similar views in different
> combinations. Maybe if others express their views in a similar way
> to the above we'll end up with a natural consensus. If not, we'll
> have to figure something out.

I understand the motivation to use more inclusive language, but IMO in
the absence of the word "slave", this "master" branch is more
analogous to a "master copy" of an artifact (usually recording) and
reflects the true etymology of the term, here.

If it's more convenient to make this change in September, then let's
wait until then. Changing twice doesn't really help anybody and causes
a certain amount of chaos.

- -chris

> On 19/06/2020 16:32, Emmanuel Bourg wrote:
>> Le 16/06/2020 à 10:02, Mark Thomas a écrit :
>>
>>> Thoughts?
>>
>> I'd prefer the status-quo and keep "master", I've always
>> understood this as the 'master record' (I know it might be
>> historically wrong) and I haven't seen evidences it has ever
>> offended or deterred anyone from contributing.
>>
>> If there is a consensus to change I suggest waiting to see what
>> GitHub plans to do. The "master" name is a de-facto standard for
>> Git repositories, and I think we should remain consistent with
>> the new name that will be popularized by GitHub.
>>
>> That said, I have a preference for "main".
>>
>> Emmanuel Bourg
>>
>> -
>>
>>
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
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl72WbcACgkQHPApP6U8
pFgzxQ//ZyTsETf5CjZ9S2CQ65GbSVY+FdhWB1Tuy6qrdmZgkII48PQWsu7SeFJL
yCH0LM9DdMEmjBx9uoHWmFtOSxgPgAPGzqQYRsDcB2zwGpkyN/kHwFDVxRyBSy7Q
NmRbE6K0orMalD86XjvFQlv/ClyOe4rNSbqywT8nw0zJFwiM2HVLJXV1CgvEor1k
Z7uVd6f10mm/F4jxQxW2nQ0rvyiMaEEOKtnZG/nGL9kb5iLz/10LlFot1Wzg49Hf
tbAbnH6k34u0OXkteYhbVNklhlGGMDKmbYCPUV+LJGZLl+pRb+Y6U1UDM22W+GCZ
HnFYMPExDPj9QSd4C3sBWx8X7oT9fyf56puK0BqP3SQhAbKUp752f7y7bdLxoQq7
aQgZm3kvNH3Vk7tkSLtnroLGuZ7yelbZXtMqvLCgoX98JaoxqejUuSB7uL9zFZ/n
Cu19NPxgRMSIyvrwredHhm2lDl0IBDeac/MeMwVplwb1VqLEZvrTdqwhg+Xe7NXo
2TilY/pLZhwnA/clyxwOo1wT+w/11s1tCMzZObSU5bVH1vbJH8Y6qVxot644Z303
QE5lPJprS6t/zIN3WVi6oSTcAo64fTdjIvlIUZ5oKakmclRvF0I2sWDt7d5m5CEI
sdt7HBbH/gAZ1h96096Qp5PmyABFnaF1OmAkorKG94mAkQvQSO4=
=l8h0
-END PGP SIGNATURE-

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



New home for EncryptInterceptor.BaseEncryptionManager and friends

2020-06-19 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'd like to refactor a bit and move BaseEncryptionManager and
associated code out of the EncryptInterceptor class. Where would be a
good place to put it?

Some potential candidates:

org/apache/catalina/util
org/apache/catalina/security
org/apache/tomcat/util
org/apache/tomcat/util/security

Or perhaps a new package.

I'm a little unclear when to decide between org.apache.catalina and
org.apache.tomcat in general.

I think it will only be the following classes that are moved, so maybe
a new package isn't appropriate:

BaseEncryptionManager
GCMEncryptionManager

I may decide to create an interface for EncryptionManager, but I don't
see it as strictly necessary at this point.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7sxXcACgkQHPApP6U8
pFiimxAAjO02A+5RN+Ywqj4/+zeksVjAb7Riv3zRunnWk90N51lwdqC4klpLYcrg
92wt+gAsN/jLmGX+tBgc2dACYaWHDEX3QBf6JLIzrlXrisPGnVPimsm1bPKUtViB
EPDk2aIfwpxknNde+PBs5xR2Og9e9BS9Aib6DrgFunOGA6WIpHccdOLz/OmCBXDp
d6y3rZkyRluekMn7+jCoMyC0bpsAdvTZTH4y1+mgKhXsoP3QpkcoZxpbEldUBPQN
JhsJG7ELC6htm5otM38/3/gevSV/1jJe85u5l9CD0Bbvna0ivJaMm4eLqfLY9YFh
bX/XTWKSxheQ3iLI/5+W3n+Ef7y9f5KpbCu4cq+PJFifDjzV8Sormr0DyEp0wpca
chKb+YaiUWHlRKvAqm4blohNLrGZ7Zi1hi0yaA0sUXwyC9sDqxu/0sKXuF1UYHxx
45eexi+kQMMpyxfSjEsFqC2VOPr3psorpxd0ijstYDVCb47hutgFowwvzkZvRU1A
utaqj2R8dswLQ8jp5Ebc671iRH+ABPEpQWZYwV6jHK+G3lNRTGtj5eOMek9gMrW+
h676ghEnO1Y3eXx+wsSDTNiF788/2Vfney5gu+VbRBOThq3UZjTbYOeqxGGDnp/G
YbXXUGz4+/7FnyN94YRNq2jyNqLhJMPNB27WT3wc46+/CB3iXqA=
=JvsT
-END PGP SIGNATURE-

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



Re: Implementing TNO (Trust No One) for Session Stores

2020-06-19 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/9/20 08:13, Mark Thomas wrote:
> On 08/06/2020 22:29, Christopher Schultz wrote:
>> I think that's enough for now. So the questions are:
>>
>> 1. Does anyone really want Tomcat to be worried about this stuff?
>> I know the answer is "some people care" but I want to get a sense
>> of how many actually care. So if you think this would be a good
>> thing to implement in one way or another, please speak up.
>
> My instinct is that this is a fairly rare requirement at the
> moment.

As I think more about this, I think it's important that we investigate
this a little further. Especially because I do not think it will be
terribly complicated.

>> 2. If we implement this, is it okay to change the API to do so?
>> I think we can do this in a backward-compatible way so that we
>> don't have to e.g. use an ObjectOutputStream to write a byte[]
>> which has been encrypted after using another ObjectOutputStream
>> to generate those bytes for storage.
>
> It depends which API. There are lots of 3rd-party session managers
> so we need to be very careful. Default methods could be useful.
>
> I'm wondering if we need a new Filter/Valve/Interceptor style API
> for this. Or a wrapper around an existing store. Or a wrapper
> around an existing Manager. Or...

I've been looking at where ObjectOutputStream is being used in Tomcat
code, and it's quite limited:

XByteBuffer (not relevant)
DeltaManager (serves a different purpose)
StandardManager
JDBCStore
FileStore

Obviously, it's the last 3 of these which are interesting to me.

StandardManager, when configured with a pathname (or left to default
SESSIONS.ser), will use a local-file to store *all* sessions when
Tomcat is shutting-down, and will load from that file on startup. This
is fundamentally different from the session Store concept which deals
with sessions individually instead of in bulk.

The Store interface and the various implementations thereof deal with
individual session-storage.

So I think we need separate solutions for each of the two above cases,
even if they end up sharing a lot of code (e.g. implementation of an
encrypted wrapper).

> I think we need to look a some of the 3rd party session managers
> out there to get an idea of how this might integrate with them. Or
> if that is even possible.

If we can do this at the Manager/Store level (separately) then I think
we won't disturb 3rd-party session managers. If we package the code in
a helpful way, 3rd-party session managers could probably re-use the
code if it makes sense to do so.

What is a little strange is that the JDBCStore and FileStore
implementations delegate the session serialization to the
StandardManager, probably in the spirit of code-reuse. Here is where
the unfortunate internal Tomcat API is working against us:
StandardManager.writeObjectData accepts an ObjectOutputStream instead
of an OutputStream.

What if we add something like this in StandardSession:

public void writeObjectData(OutputStream out) {
if(encrypt) {
  out = addEncryptionDecorator(out);
}

writeObjectData(new ObjectOutputStream(out));
}

This should not disturb any existing code.

We update the Store implementations to call
writeObjectData(OutputStream) instead of
writeObjectData(ObjectOutputStream). Any 3rd-party session manager can
use addEncryptionDecorator() if it wants to, and any 3rd-party Store
implementation can use writeObjectData(OutputStream).

StandardManager's implementation of bulk-session-storage can create a
single encrypted stream and continue to call
writeObjectData(ObjectOutputStream) as before.

Symmetric changes to readObjectData would be made as well.

WDYT?

>> 3. Is encryption "enough", or should we try to implement some
>> kind of replay-mitigations? I don't think we'll ever be able to
>> completely close this hole because (a) Tomcat can't be expected
>> to have a priori information about the session before it's being
>> loaded (e.g. after restart) and (b) all the validation
>> information must be inside the stored session data. I can't think
>> of a way to avoid a replay attack short of maintaining yet
>> another database of session-versions for validation. I can see a
>> man in the corner wearing an "Over-Engineering Police Force"
>> uniform staring at me intently.
>
> Symmetric encryption should be enough. Not persisting
> authentication (already an option) and not restoring expired
> sessions (already done) should go some way to mitigating replay
> attacks.

I agree that symmetric encryption is sufficient.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7sv7wACgkQHPApP6U8
pFjSdRAAj8pcYvEAMHwKyQA/N1ys

Re: Changing the name of the default branch in our git repos

2020-06-19 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/16/20 04:02, Mark Thomas wrote:
> All,
>
> You may have seen the recent discussions both inside and outside
> the ASF about the user of "master" as the name of the default git
> branch. If you haven't, the short version is that the name can be
> traced back to master/slave and its associations with human
> slavery.
>
> I'd like to propose that the Apache Tomcat project renames the
> master branch in all of the project repositories.

+1

> I think there are two front runners for the new name:
>
> - main - this looks to be the name GitHub and a number of OSS
> projects will be switching to
>
> - trunk - reflects the Subversion heritage of both the project and
> the ASF

I'm not picky about the name, but perhaps there is an opportunity, here.

Historically, trunk/master is where new development has been done, and
releases of the current-latest version of Tomcat are released directly
from that branch. Perhaps we could be more clear in that our new
development branch is 10.whatever and not trunk/main/master/foo which
just happens to cut releases called 10.x from it?

Perhaps I am suggesting that we have main/trunk *and* 10.x but I
haven't really thought it out.

> Committers and contributors will rebase any local branches to
> $new_branch

A short set of instructions post-migration would be very helpful for me.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ssSQACgkQHPApP6U8
pFgp5g/8DNrNJk425nRu01rASo9TLLGqYcf5tVT27b+jFhLH9JnPFQJ6qDODN8QJ
o8srgUHsiOnk/HNI+wxjfN2rklIP4gDEEJG8wsqvVQEuHbk3hxrXMHyKdOCENcsp
NeuiIdXduJVmJAHHziXs7Aqddf6fnu4yFOBMbaq8uncRqrM0EUgJipMLax0FOBfG
tpfp+oefynWyK/whoGGuWUkoiLSjhS6YlrJ2ElU18mztQsAZg1VtDpM1H4C4S9vC
HIUoGlor8J14zo2DMt34kleo5YZDbgSbKJzhmXhqfpq0sGtFpUJSRoJjlieHsDMT
T1AM12HOT6rXhTHLkxo8pl9ariM0ieHI/YtKDi5NlzHStwII3C0ZAcyPHTYGTeIb
7XFPP1mT7mEEUXW+g2fbpNyUNwceXO/zDg2NfEbUKN+yG94PWcY1tSgoLRrv9o2h
/U81iM/rFZqxqZ+YOLtYoAcjVYaR106/fTCLeRMZWO7sgzknLHrDE52EoHA6cnkr
ABkQX4fKt70V9oVf61v/0WuKyI2O3EB3R5Yc5NZgmx+gFoqSarE6HOX/5sOAPoHj
/zFTUt19zf/6yyTLIQSbz/Sh6jzAhi44nVArNO4kX/S4w55jf7mJbZRiryhYW1xN
gfwq9RvNtvR+r22NAlvKKRKJjMpslnAgbUDqENvuF+qurdrEgtg=
=xOny
-END PGP SIGNATURE-

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



Re: Java library bug in JCEKS keystore loader

2020-06-16 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 6/13/20 14:54, Michael Osipov wrote:
> Am 2020-06-12 um 23:54 schrieb Christopher Schultz:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> All,
>>
>> I've been writing a Java-based certification-expiration checking
>> utility that can handle all kinds of file formats like PEM and
>> the various keystore formats supported by the JVM.
>>
>> Since it's not possible to tell what type of keystore is being
>> loaded without writing a bunch of magic-checking code or
>> implementing an ASN.1 parser (no thank you), I simply try all
>> keystore types until I find one that works. I'm using a
>> rewindable InputStream which works well .
>
> there is no need to, use Apache Directory Kerby ASN.1 module. I use
> it too and it works very well for my certiticate tasks at work.

It's pretty simple to look for "-BEGIN" or hand-off things to
KeyStore.load. Right now, this is a single-class utility with no
dependencies. No need to add more dependencies if they aren't
necessary. I'm not looking to build a complete certificate
manipulation framework.

Attempting to load using KeyStore.load will be required, anyway, for
keystore types such as JKS, JCEKS, Windows-MY, Windows-ROOT,
KeychainStore, etc. which aren't ASN.1 files like PKCS12.

Anyway, the point was that there is a bug in one of the keystore
implementations that may cause some troubles.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7o4iMACgkQHPApP6U8
pFiiiQ/+I2UHDRSi2xqP1ehQIBvwMXDxtXq71nCeZrN6VTEyPJS3V1IqJVKG4eks
9rAc7QnVYBMSaWglzVJQKKl8zdf8GncOYhk8JkDEON7LjLDuyLRj2m/bHkivQs6Q
AY/Fo9CRSscxV1YS78erNdMDLwWr7YXmkeJypJ1IL8OaB5kNzIak3t70zb3XRSWb
3JQ4F/64AYv+nnapGbsT2pYTMy6vKOVTearrXKZQJGRD0NIbz7xAh/tceem4eeUh
SGQLPJW6Bg1fN52bmKOuluCCu95K8u2eblqoPVlTvtJutxGDSz2HGCjJLISqgJrZ
PvwIpsbpCQ8x1vOXL4geu0XhXmpEtA49s3sj8c0aFUM2Aq9z4kRfQz0/BQQaeZo4
r1inQ4CSj2dhtE/7lGtMG4aXjoJgtvC81rcJR/rrr2VjZwQOWSHmcPVWKAG0Pk00
NffUll3+BcZnFbeMzV/GkMonY7bXfHvDkvlwjdA8ykAWAYXUy4fsQoHwU+RiODLh
ds7OwjtA6WlJMPvWprZXucmhEAXDBJJsU55ttEtIeDMf3NU6j9ckHwDvzg9M1BcW
2rPgZyOoZiz9vwsjRyEXp7V/luMZI7KnbTpa/l/DkU+ET5284B/zy95V3/CU8HgD
oYY5D/PtEdE6S4Y34whpcb7dUffKoFIMDVaDXGbcaA8D5VwRi1g=
=0dZ2
-END PGP SIGNATURE-

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



Building mod_jk for Windows

2020-06-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I see Mladen has gone crazy updating mod_jk for IIS. The build process
looks fairly straightforward in a way that isn't so straightforward
for e.g. libtcnative.

I suspect most of it is the work that has gone into his "Custom
Microsoft Compiler Toolkit Compilation" to make sure it has everything
it needs.

I wonder if this could be Dockerized to make it even easier for just
about anyone to perform a Windows build of mod_jk. Even better,
perhaps a similar toolchain could be used to build libtcnative as well.

Does anyone have extensive Docker experience? I certainly do not...

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7lE2MACgkQHPApP6U8
pFgfDhAAq7i544Rb5JdlzwQao9PJjMOlpseKBioO7peF1Yofqf1o9SutLoIU7hyt
LXrdU5kevTQepHWJxbS7cHPmbnnWtdGaU88rMjDP9hote9ftQUDYiAfeL45fmufB
T1a76YXFXLvsae3rdupLy9RfRTlvLcHoKGscre5J/vACpzjsFoq0B3KVHerBxPJe
dsbaZAlM0CslzJ6AkbZKS5ZaVYuOM9XiXhY37c5Ki8Yy7NjuhPOcksotlcKph37P
RHW9Y0QEUNqtn4xn3KGyPPsiaMgHkgaSJ/md7pyvr3CQMefUuwSaiY2DQif5fMgD
Yigo69bCuqXcM3KytgPO4tZa48mCIc0oFIHZ1G3v+XNkBeFmteTRRp/fUmptmALC
1Js1dL7Xf0VuyO4eQU96fQ1aXg+PpIOO6sRil4xEIiIUfB3pyWowIV+qGXu0iGKk
+TzFWYp01S+uDW6tXAAbrwKCkPGwxSgsHW1ewQ0u+X+NvIHOak8XbaAYvDKXclsh
qz+6cX84cd4GrKU8ieP9RqtP/n4SI2yIFmEw2MCHyi/ojccIb7OdLgfftbfmCZo2
oBhHd3MvS0gtyLDxs0VI2dEi6bh3ly/AKHIylEwXnvY+BTD6kRkXL1y4S/LCcaXN
nKoplRvg2m9UzYaCW0oy9IyJUS/otsXe3eHjFNZ8hfV1/qizcp4=
=i0Jr
-END PGP SIGNATURE-

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



Java library bug in JCEKS keystore loader

2020-06-12 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I've been writing a Java-based certification-expiration checking
utility that can handle all kinds of file formats like PEM and the
various keystore formats supported by the JVM.

Since it's not possible to tell what type of keystore is being loaded
without writing a bunch of magic-checking code or implementing an
ASN.1 parser (no thank you), I simply try all keystore types until I
find one that works. I'm using a rewindable InputStream which works well
.

Until you try to use the JCEKS keystore loader, specifically in Java
versions 8 - 13. I haven't checked that later versions, and it appears
that it's been fixed in Java 14.

The API call is KeyStore.load(InputStream, char[]) and usually it
behaves well. Unfortunately, in these affected versions, the JCEKS
provider (which happens to be com.sun.crypto.provider.JceKeyStore, in
the public engineLoad method) calls InputStream.close on the stream
passed-into it. Yuck.

JCEKS is a little-used keystore format, but it is required to store
secret keys (different from private keys) because JKS can't support
those. So it's possible that some users have been forced to use JCEKS
keystore format.

I haven't looked-through the Tomcat code yet to see if there could be
places where this could cause a problem. Sane code usually looks like
this:

try(FileInputStream fin = new FileInputStream("keystore.jceks")) {
  KeyStore ks = KeyStore.getInstance("JCEKS");
  ks.load(fin);
}

This code will fail with "java.io.IOException: Stream closed", which
is of course incorrect resource management.

My solution was to simply wrap the InputStream in one that will simply
ignore any attempts to close it:

try(FileInputStream fin = new UnclosableInputStream(new
FileInputStream("keystore.jceks"))) {
  KeyStore ks = KeyStore.getInstance("JCEKS");
  ks.load(fin);
}

public class UnclosableInputStream
 extends java.io.FilterInputStream
{
protected UnclosableInputStream(InputStream in) {
super(in);
}

@Override
public void close() throws IOException
{
// System.out.println("DEBUG: Ignoring attempt to close
InputStream by provider of keystore type " + keystoreType);
// new Throwable("trace").printStackTrace();
}
}

I'll be looking at Tomcat's keystore-loading code to see if this would
be helpful, as not many people are running Tomcat on Java 14 yet, I
would guess.

- -chris

P.S. I'll probably be releasing this tool on GitHub, soon, if anyone
wants to have a look.
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7j+XgACgkQHPApP6U8
pFgUPQ/+L7DQhP19ELBKYUbXQgdKN+aieiJoQap5wID+QZSXBJmbEgnUvrRcLdte
oBaTgOJc3pKc6lV2K6PYIzT2HTpB4420h9cbn6vtFAuTdbN08RTxO5e6IGBUovtT
o/Y0iVSy4m3aQfOg7nISqGoaVggDffTrr/ZQDPgjxbTbAeTHEhk7eCN0nNMWmzFD
V2jn7b7IOowZoXRSWlMZ4FqmjPIugckmIs1qDfzooPQhdplLpbJn1ucLikG/j5jj
kmeCRaiPtNCC3FmhlBgkU5Ac50LksoY4uR0dROzpxyZbClyUnq2zAIY/9paygG8s
ZK/FZIaTdzJU3VeemaE3mMuCIDtTwzmRJH29kMTz1X4GOvsL3PbHFqeav9KGmUWO
H3ASkTe27jhXSzxLrbxIsaQDRTAjscMMBAjy11Nsp5Qism7JQ7OgKiX0nOnR2Vne
hP7cgk9snAkI9QhnTnyqnSd7dYKjMqEmmIa58YuRc+OaUeNf3wwmljSpKYvI2D31
ldBCEVF4PE+GNT0DXGfX2osTLMkglkDkgElHWennTDkHko72aexNX7c3Ut3+ldRu
ho6CG2Fwaugw/QS3uk9E/ZfXwl5ZU2Rn4ysWac17FHgOA7A/yHrPkJxDxKGZHSHI
rzMgeyquIpizAJEj6NKNQJdwujcZeVAhvUae+mQyoaJYplEpKRs=
=AakA
-END PGP SIGNATURE-

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



Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

2020-06-11 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Romain,

On 6/11/20 13:34, Romain Manni-Bucau wrote:
> @Chris:
https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/
java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java
?

Thanks!

Stupid GitHub. I searched all your repositories for "encrypt" and it
didn't find "letsencrypt". I guess "search" means "prefix match".
*facepalm*

> it is more or less what we have in meecrowave except meecrowave
> can hotreload whereas this (pre reloadSslHostConfig method) impl
> does not.

Your LetsEncryptManager seems to call reloadSslHostConfigs. What does
Meecrowave do differently?

- -chris

> Le jeu. 11 juin 2020 à 19:20, Christopher Schultz
>  <mailto:ch...@christopherschultz.net>> a écrit :
>
> Merlin,
>
> On 6/10/20 12:32, Merlin Beedell wrote:
>> Well thanks Christopher - that presentation link was just what I
>> needed (well - it was your presentation after all!). Really
>> good. Ideally this could be written into the Tomcat standard
>> Documentation, as it will crop up quite a bit.
>
>> In summary, 3 steps:
>
>> 1. Fetch cert update (requires port 80).
>
>> – certbot-auto renew
>
>> 2. Reformat for Tomcat usage [might be natively handled in later
>> Tomcat releases?]
>
>> – openssl pkcs12 -export -in [cert] -inkey [key] -certfile
>> [chain] -out [p12file]
>
>> 3. Use JMX to flush/reload the SSH Host config (including cipher
>> list & protocol level) at runtime.
>
>> https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl
e
>
>>
r,port=8443,address=
> <https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl
er,port=8443,address=>"127.0.0.1"=reloadSslHostConfigs
>
>  While
>
> "[documentation] patches are always welcome", I don't think I'd
> want to put this into the Tomcat user's manual. If we add
> information about Let's Encrypt, why not DigiCert? VeriSign?
> GoDaddy? WhoeeverElseCA ?
>
> I could see this being something useful in the Tomcat Wiki.
>
> At least one person who has seen my presentation has said "we, I
> was hoping there was just a letsencrypt='true' configuration flag".
> I like the outside-in approach certbot takes with their Apache
> plugins, rather than an inside-out approach where the server
> actually has a plug-in for let's encrypt (or similar).
>
> Romain @ TomEE has written a WAR file that implements this
> inside-out approach as a generic ACME servlet (context listener?),
> but I can't seem to find his code anywhere...
>
> -chris
>
>> -Original Message-
>
>> From: Christopher Schultz  <mailto:ch...@christopherschultz.net>>
>
>> Sent: 08 June 2020 9:14 PM
>
>> To: Tomcat Developers List  <mailto:dev@tomcat.apache.org>>; Merlin Beedell
>> mailto:mbeed...@cryoserver.com>>
>
>> Subject: Re: Support for LetsEncrypt certs, and update process,
>> in Tomcat without restart.
>
>
>
>> Hash: SHA256
>
>
>
>> Merlin,
>
>
>
>> On 6/8/20 10:17, Merlin Beedell wrote:
>
>>> I am getting a lot of flack from some senior devs who insist
>>> that
>
>>> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which
>>> will
>
>>> handle the SSL offloading etc.
>
>
>
>>> While this seems sensible for multi-server environments, they
>>> want it
>
>>> for single server too.  But Tomcat can do all the things that
>>> are
>
>>> required:
>
>
>
>>> * Certificate handling. * TLS level and Cipher restrictions *
>>> CORS
>
>>> handling (though this could be simpler!)
>
>
>
>>> But now with the requirement for LetsEncrypt certificates, we
>>> find
>
>>> that Tomcat has to be restarted every 3 months.  Indeed – any
>>> changes
>
>>> to the above require tomcat restarts – and that is found to be
>
>>> unacceptable.
>
>
>
>> Nonsense.
>
>
>
>> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
>
>
>
>> Updating CORS configuration may require a redeployment of your
>> web application, but it does not require Tomcat to be shut-down.
>
>
>
>> There are other reasons to use a reverse proxy in front of
>> Tomcat, but none of the above are good reasons.
>
>
>
>>> So what I really want to understand is if Tomcat has any plans
>>> to
>
>>> include the ability to restart an https connector WITHOUT
>>> needing to
>
>>> restart the wh

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

2020-06-11 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Merlin,

On 6/10/20 12:32, Merlin Beedell wrote:
> Well thanks Christopher - that presentation link was just what I
> needed (well - it was your presentation after all!). Really good.
> Ideally this could be written into the Tomcat standard
> Documentation, as it will crop up quite a bit.
>
> In summary, 3 steps:
>
> 1. Fetch cert update (requires port 80).
>
> – certbot-auto renew
>
> 2. Reformat for Tomcat usage [might be natively handled in later
> Tomcat releases?]
>
> – openssl pkcs12 -export -in [cert] -inkey [key] -certfile [chain]
>  -out [p12file]
>
> 3. Use JMX to flush/reload the SSH Host config (including cipher
> list & protocol level) at runtime.
>
> https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandle
r,port=8443,address="127.0.0.1"=reloadSslHostConfigs

While
>
"[documentation] patches are always welcome", I don't think I'd
want to put this into the Tomcat user's manual. If we add information
about Let's Encrypt, why not DigiCert? VeriSign? GoDaddy? WhoeeverElseCA
?

I could see this being something useful in the Tomcat Wiki.

At least one person who has seen my presentation has said "we, I was
hoping there was just a letsencrypt='true' configuration flag". I like
the outside-in approach certbot takes with their Apache plugins,
rather than an inside-out approach where the server actually has a
plug-in for let's encrypt (or similar).

Romain @ TomEE has written a WAR file that implements this inside-out
approach as a generic ACME servlet (context listener?), but I can't
seem to find his code anywhere...

- -chris

> -Original Message-
>
> From: Christopher Schultz 
>
> Sent: 08 June 2020 9:14 PM
>
> To: Tomcat Developers List ; Merlin Beedell
>  
>
> Subject: Re: Support for LetsEncrypt certs, and update process, in
>  Tomcat without restart.
>
>
>
> Hash: SHA256
>
>
>
> Merlin,
>
>
>
> On 6/8/20 10:17, Merlin Beedell wrote:
>
>> I am getting a lot of flack from some senior devs who insist
>> that
>
>> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which
>> will
>
>> handle the SSL offloading etc.
>
>
>
>> While this seems sensible for multi-server environments, they
>> want it
>
>> for single server too.  But Tomcat can do all the things that
>> are
>
>> required:
>
>
>
>> * Certificate handling. * TLS level and Cipher restrictions *
>> CORS
>
>> handling (though this could be simpler!)
>
>
>
>> But now with the requirement for LetsEncrypt certificates, we
>> find
>
>> that Tomcat has to be restarted every 3 months.  Indeed – any
>> changes
>
>> to the above require tomcat restarts – and that is found to be
>
>> unacceptable.
>
>
>
> Nonsense.
>
>
>
> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
>
>
>
> Updating CORS configuration may require a redeployment of your web
>  application, but it does not require Tomcat to be shut-down.
>
>
>
> There are other reasons to use a reverse proxy in front of Tomcat,
>  but none of the above are good reasons.
>
>
>
>> So what I really want to understand is if Tomcat has any plans
>> to
>
>> include the ability to restart an https connector WITHOUT needing
>>  to
>
>> restart the whole of Tomcat.  Better still, a hook that would
>> help
>
>> refresh certificates – like LetsEncrypt.
>
>
>
>
> https://stackoverflow.com/questions/43571572/programmatically-update-c
ertificates-in-tomcat-8-without-server-restart
>
>
>
>
>
>
> There
>
>
>
> are no currently-correct answers to that question.
>
>
>
> I can fix that.
>
>
>
> -chris
>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7iZ88ACgkQHPApP6U8
pFiMOQ//XsUcdESt//fApST4TGad+KpkTX964+jhgqaC0uprpTpd/GRpo81yxupI
oRbQ/UVwZHOWglClZCQoL8fbFYSCcizAIWhJqmMiTMshx6sYXIINC478zcO/B7VY
V8i+DpT0mdi3jYwc59lZD4e/P/v9jJJjGAuS6YrlrHjdAt5IcEJ5+2JG3HaGnhzp
ALYbq0OaQfM0jTnDymIHuXmuoAZbhon0+4tYAO/hHIbMJE+xvgeud3qRJXNhjpIv
YjWfQ06zNAuuOMvUtYjN8ONAUAl8FR5rOcC0lT6nMK1EpIglmtqcu3CIuXxtEu3M
zEkOSWDVqziN00lmcaoZ2GqYYOPS0+GH+OfcM489X731bZDJR9VUlepFBaYM21X6
BAsdmT2U6yvpEw/wOyuRMbo50toMLc1eULeAPgsCudNaWWA2T7AUaxpYbzw8jt4t
oIZhIGsEEHySWzxO7e17Puq/Z9zWC0T9+vFIfL19n1EDC+8UuhPOBnZ7Vvgu1GHn
wdHG26+Rc9NPUnkY5L2AG33itBD/lvo53HRryFHxzgbw1n0KdxethczsBarzdKGl
7W0GUkYZi4aSxcdcOHcs0Brcnv7RwWEU2FcI96BHoVn80TW8qUuE83Dfr6py2gzR
EP2dqd7JiGpTrDZZdIBkcoQ5B4/z/39KuyZkeYPNPp85gcPdayI=
=5mUH
-END PGP SIGNATURE-

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



Likely incorrect wiki redirect

2020-06-11 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm not sure who can fix this, but when I go to
wiki.apache.org/tomcat, I'm redirected to
https://cwiki-test.apache.org/confluence/display/tomcat which returns
a "Service Unavailable" error.

Without the /tomcat, I get redirected to the new Apache cwiki site as
expected.

Looks like maybe there is still a Redirect configured for /tomcat that
should either be removed, or updated to point to the new Tomcat wiki.

Thanks!
- -chris

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7iY7MACgkQHPApP6U8
pFgcMA//VTK2HpVJsUUDOIdmwCVZLKu5cUtAF7fIR6QeR/MGWXkivSOgwPM0n2lO
QMeV2KW4FTWX2ZJjtGrKGTozaHL8TjZmrHLolChQLoKeYbLMPrBPTxJ/Fu2V/wVU
J7+Vy/d9tQBqupWkdu7YNbj1nsnlfaPuoDAe7lPhCwsGkHg0gZf/B/pk4Wu5nNao
2wyRW06t516VhAk2mntsDjAcwOxTUCkOmS+dyC5/1CEQwHnOQnpfl7mhsk5Po1Gf
y0YyiCS89ZxDjmQ9LYP3k15Kb1kFcQ8dgGK6eafLucA1uUrirQ6GN7HvhGgqbu2f
+fBxaKLHJ9PTQx3hglD5R6qwqZna1Ayd1f9LOpfrEp6K2MHY6fwcACwXB3PgF+QE
RSymHa8VVP3sHi30ryPgxXYHSmjsOQvhddGlxgWQ9iBOlir84Q3B2zX0SpCsdOcf
F9pFr+Y4NSdlOvlFLP6LCL/k4qvnH2Mq9zcLpFsm2k6d1C7K9wQ0bLc0f4WPXc5G
dqHvSkOwLA2CgII9te1TkvGhavs+y72NIczv81I2BHE+/qwp6QG2BVX9y+5oljqe
DLAoSkPzhVyVK7N4/rHXbKyyhvSXB1kzA8jM8bTIij2/aluQIyEb3uj+J2G9MMSh
eVALrMPro4900eSaTOsOZGOvqDfG6Bs8xF7BioeAilPUDKOQPNM=
=y6Hc
-END PGP SIGNATURE-

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



Implementing TNO (Trust No One) for Session Stores

2020-06-08 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Tomcat stores sessions without any encryption and/or authentication,
and anyone with write-access to the session-store can poison a session
and mount an attack. This kind of attack is (arguably appropriately)
declared to be outside of the scope of Tomcat's responsibilities,
because the system administrator should arrange for appropriate
access-controls to whatever storage medium is being used.

Note that sessions can also be read from such a store, of course, but
I'm more concerned with a privilege-elevation attack, here and not a
loss of privacy. It turns out that the solution to one problem can
solve them both.

If you want to be as  paranoid as possible (and why not?), you'll want
to make sure that your session persistence mechanism isn't readable by
anyone but Tomcat. I'm sure there are use-cases for making those
session stores readable outside of Tomcat, but then again, those
people aren't asking Tomcat to provide secure session storage.

It would be simple to encrypt (or sign) the session-data and decrypt
(or validate) the data coming back in when reloading.

Of course, it would be a deployment headache because it's another
shared secret that needs to be deployed to all servers in e.g. a
cluster. I'll be talking to Rémy about his cloud provider for clusters
to see if we can do things like trade-around cluster-encryption keys
via a cloud manage r(e.g. Kubernetes), and then it seems logical that
we could do the same kind of thing for the session manager, too.
Environments without such orchestration would have to arrange to
distribute their shared secrets in some other way.

This could be implemented either at the Store level or -- even better
IMO -- at the StandardSession level, since
StandardSession.wrireObjectData/StandardSession.readObjectData can do
anything it likes to its own data such as signing or encrypting. No
interfaces would have to change.

I didn't see an opportunity to install any kind of
shim/interceptor/decorator into the existing pipeline to add this
"outside" of either the Session or the Store without any API change,
so the above idea seemed to me to be the best way to look at
implementing such as thing.

The interface for Session doesn't help at all, since this
facet (session persistence) is only introduced at the StandardSession
level. Also, the interface is basically:

writeObjectData(ObjectOutputStream)
readObjectData(ObjectInputStream)

In order to provide arbitrary manipulations, we could introduce a new
interface:

interface DataMassager {
  writeObjectData(ObjectOutputStream)
  readObjectData(ObjectInputStream)
}

Then we just wrap these things around the existing implementations.
Maybe the DataMassager is a field in StandardSession.

I generally like the idea of an interceptor, but with a stream-based
API -- especially when the stream class isn't very generic -- it's
difficult to do. If we were able to change from
Object(In|Out)putStream to (In|Out)putStream or just simply
writeObjectData(byte[]), then various interceptors could mutate the
data arbitrarily on the way in or out (or, likely, both).

If we could get away from Object(In|Out)putStream, I think that would
be a win.

We might be able to do that by introducing new API methods in
Session.java:

public void writeObjectData(OutputStream);
public void readObjectData(InputStream);

Those can, by default, just wrap an Object(In|Out)putStream around
those streams and call the existing code. But other implementations
could use the generic streams directly.

But without an API change, I think we are going to have to have a
single session-data mutator object. Stacking things up will have to be
an exercise for someone who wants something beyond the complexity I
expect to introduce, which is simply to encrypt data in the persisted
session-store.

If Tomcat encrypts session data with a symmetric key (shared with any
other Tomcat instance which would need to read the session data from
the same store), then we can guarantee that session data loaded by
Tomcat was generated by Tomcat. (Or at least was generated by code
which knew the key. We can only do so much.) Such encryption protects
the data from being viewed by unauthorized parties or from being
forged and/or manipulated.

The only thing I can think of that it will not prevent is replay
attacks: grabbing a copy of a stored session and then re-injecting it
into the session-store. I'm not sure there is an attack against Tomcat
hidden in there, but certainly there is an attack against the
application in there. Applications could version sessions or add
timestamps to things as a mitigation against session-replay attacks.

Tomcat could add replay-mitigations in a few ways, but I'm not
entirely sure these are worth is. In the spirit of academic
navel-observation, let me lay out a few ways that could be done.

First, we could version sessions. Each time a session is written-out,
its version number is incremented. Or a timestamp 

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

2020-06-08 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Merlin,

On 6/8/20 10:17, Merlin Beedell wrote:
> I am getting a lot of flack from some senior devs who insist that
> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which will
> handle the SSL offloading etc.
>
> While this seems sensible for multi-server environments, they want
> it for single server too.  But Tomcat can do all the things that
> are required:
>
> * Certificate handling. * TLS level and Cipher restrictions * CORS
> handling (though this could be simpler!)
>
> But now with the requirement for LetsEncrypt certificates, we find
> that Tomcat has to be restarted every 3 months.  Indeed – any
> changes to the above require tomcat restarts – and that is found to
> be unacceptable.

Nonsense.

http://tomcat.apache.org/presentations.html#latest-lets-encrypt

Updating CORS configuration may require a redeployment of your web
application, but it does not require Tomcat to be shut-down.

There are other reasons to use a reverse proxy in front of Tomcat, but
none of the above are good reasons.

> So what I really want to understand is if Tomcat has any plans to
> include the ability to restart an https connector WITHOUT needing
> to restart the whole of Tomcat.  Better still, a hook that would
> help refresh certificates – like LetsEncrypt.
>
> https://stackoverflow.com/questions/43571572/programmatically-update-c
ertificates-in-tomcat-8-without-server-restart

There
>
are no currently-correct answers to that question.

I can fix that.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7em/oACgkQHPApP6U8
pFiuqw//SfBmQ4eMhXUw0WkiQ5Fe9dJIa724h0wv60ghJQK80n9cu7CdcB9om9R4
w4tbhvxkBCc/ENBQP2gfszRwT8Y7EleyDTY09OKaQ1aiqgnWaE4hj2Srmoi/kUFi
LAbgNm/vpHzTS/ozp3+T/vD8GtLHc1UXDnsKY3zzMc8CFgRo10YDyAMJoC8S4SGe
1Ji4NF1uY2aqeY7LPBMDU1IrQTK4EW2SNFV9JSyEjsPBB8yKCzvGdCJRPvJih/mg
ZsTI6w/X2cldSbVvpAUh5hOUglo8+5BqN2W1aOKttwxbds/KbckQg5vOHs4+sCPk
M6ngE0sYggz2JsF/IZQ9PtMDtuZdKxmCWsXwbTw7G5qpjv6RWQW2GtMl52d1qabO
Xna7npVd1kiGOvA/uuNPxI7Z3qOhYiCs78JCG6oaUQejqywgvKO4HyibNlFJD1F+
P3S/SLuxQB7uhC5CuY3wKXckJEbGbL7D04wkCY90N1q5PQO0oy5j/jyS3y6cDmHw
SZNuH3Gvc7WUE8xbJNx5W8fP9m5mpwAJ0lwcCgqN8zqUEqbbE4imrMOrVxjmqPiT
V/jySH8D0ckk+jyQ8gADmId8vGF5KrQCrfTwxjpLhxSuEZ+cB3d7tsOCCI6Xw9o1
ShMM500fXsMgHkrhyqg7gG6Pf7zVutqhgOBkUZUntFkuMEB38Ow=
=O9u2
-END PGP SIGNATURE-

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



Re: [tomcat] branch master updated: Fix BZ 64483 Log a warning when an AJP request is rejected

2020-06-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/2/20 11:44, Mark Thomas wrote:
> On 02/06/2020 16:37, Christopher Schultz wrote:
>> Mark,
>>
>> On 6/2/20 06:24, ma...@apache.org wrote:
>>> This is an automated email from the ASF dual-hosted git
>>> repository.
>>
>>> markt pushed a commit to branch master in repository
>>> https://gitbox.apache.org/repos/asf/tomcat.git
>>
>>
>>> The following commit(s) were added to refs/heads/master by
>>> this push: new 186aae3  Fix BZ 64483 Log a warning when an AJP
>>> request is rejected 186aae3 is described below
>>
>>> commit 186aae31791ea120cf1b4ddd2f9fcb974bd1d5f9 Author: Mark
>>> Thomas  AuthorDate: Tue Jun 2 11:22:35 2020
>>> +0100
>>
>>> Fix BZ 64483 Log a warning when an AJP request is rejected ---
>>> java/org/apache/coyote/ajp/AjpProcessor.java   | 14
>>> --
>>> java/org/apache/coyote/ajp/LocalStrings.properties | 1 +
>>> webapps/docs/changelog.xml |  4  3
>>> files changed, 9 insertions(+), 10 deletions(-)
>>
>>> diff --git a/java/org/apache/coyote/ajp/AjpProcessor.java
>>> b/java/org/apache/coyote/ajp/AjpProcessor.java index
>>> d24a818..77d6a94 100644 ---
>>> a/java/org/apache/coyote/ajp/AjpProcessor.java +++
>>> b/java/org/apache/coyote/ajp/AjpProcessor.java @@ -30,7 +30,6
>>> @@ import java.util.HashMap; import java.util.HashSet; import
>>> java.util.Map; import java.util.Set; -import
>>> java.util.regex.Matcher; import java.util.regex.Pattern;
>>
>>> import jakarta.servlet.http.HttpServletResponse; @@ -779,17
>>> +778,12 @@ public class AjpProcessor extends AbstractProcessor
>>> { // All 'known' attributes will be processed by the previous
>>> // blocks. Any remaining attribute is an 'arbitrary' one.
>>> Pattern pattern =
>>> protocol.getAllowedRequestAttributesPatternInternal(); - if
>>> (pattern == null) { +if (pattern != null
>>> && pattern.matcher(n).matches()) { + request.setAttribute(n,
>>> v); +} else { +
>>> log.warn(sm.getString("ajpprocessor.unknownAttribute", n));
>>> response.setStatus(403); setErrorState(ErrorState.CLOSE_CLEAN,
>>> null);
>>
>> Possible DOS by spamming the log file?
>>
>> I suppose you can DOS by filling the access log, too :/
>
> How? This is AJP.

Exposed endpoint. *shrug*

I understand that this was added to make debugging of
secured-endpoints easier (so the owner can whitelist whatever they
seem to have forgotten) but anyone spamming the AJP port can cause a
lot of output.

This would be similar to sending malformed HTTP requests, which we
currently log a single time and then subsequent errors are logged "at
debug level" so you can at least disable them for production.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7WdvgACgkQHPApP6U8
pFhbtxAAlbaqmiPAMduW/gJrHIbL/FWvO7CgxSeUCbVMTo5mJmEZfJseiu/8jIMJ
8oejSRodPGeQhy8bdhelI3btQ69j5FYoXhN1Xn5A1vfEHP2EgsZj1hMp8FklYSo6
XJBqG+mpbASOvQS8iDhwX3S6mNrhOLZYhDO6otQ1mTz3MIbquK8fvMNxvltmmti6
gXyag9WwBY/Ln1M3vn7VcYAbY5NrhnR8QQn8BJq2FVWxxXeuhJV8CJeV860/0kkl
MufKzLKt7xEyWp4Bd+iH0qOpWdib57vjXSzPc6DQw7LU0npOO68kcRc1H8RIqqjY
GuL8m1LX4OuBJZ0S7JkOH3EpPwQrM9QkUHkKyR3XYFKOHiAJx1YHWSAJczFG8CWH
Iu+E9Rc1bcLSe+9UbvTkNEj/nie2JiDNa+DV+xL56tnkHlAMn1uULwAUE9aff827
amiLosBInW0QvzqwPV0CA/WbIkdNxAOjI2mqYETxuBeFKHdGVdCtY/bDfhrLenT3
GYA88fNiWaRGkJHWRFaBrTpFlV5h/zgBygEPwazL/dXVXk46IR7viOfRugGipbE+
YiyJMVFR/TbkNN2CIm9zymHBhOwSe3cgUTasSNn5jucU2kWrp2qiVE+6jtlMpWtt
zIyt8y8IxxOyNXgo7kaVMboixYrgH5aZYlgGcde6IMCNn1Q898M=
=iDD7
-END PGP SIGNATURE-

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



Re: [tomcat] branch master updated: Fix BZ 64483 Log a warning when an AJP request is rejected

2020-06-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/2/20 06:24, ma...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git
> repository.
>
> markt pushed a commit to branch master in repository
> https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this
> push: new 186aae3  Fix BZ 64483 Log a warning when an AJP request
> is rejected 186aae3 is described below
>
> commit 186aae31791ea120cf1b4ddd2f9fcb974bd1d5f9 Author: Mark Thomas
>  AuthorDate: Tue Jun 2 11:22:35 2020 +0100
>
> Fix BZ 64483 Log a warning when an AJP request is rejected ---
> java/org/apache/coyote/ajp/AjpProcessor.java   | 14
> -- java/org/apache/coyote/ajp/LocalStrings.properties |
> 1 + webapps/docs/changelog.xml |  4  3
> files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/java/org/apache/coyote/ajp/AjpProcessor.java
> b/java/org/apache/coyote/ajp/AjpProcessor.java index
> d24a818..77d6a94 100644 ---
> a/java/org/apache/coyote/ajp/AjpProcessor.java +++
> b/java/org/apache/coyote/ajp/AjpProcessor.java @@ -30,7 +30,6 @@
> import java.util.HashMap; import java.util.HashSet; import
> java.util.Map; import java.util.Set; -import
> java.util.regex.Matcher; import java.util.regex.Pattern;
>
> import jakarta.servlet.http.HttpServletResponse; @@ -779,17 +778,12
> @@ public class AjpProcessor extends AbstractProcessor { // All
> 'known' attributes will be processed by the previous // blocks. Any
> remaining attribute is an 'arbitrary' one. Pattern pattern =
> protocol.getAllowedRequestAttributesPatternInternal(); -
> if (pattern == null) { +if (pattern != null &&
> pattern.matcher(n).matches()) { +
> request.setAttribute(n, v); +} else { +
> log.warn(sm.getString("ajpprocessor.unknownAttribute", n));
> response.setStatus(403); setErrorState(ErrorState.CLOSE_CLEAN,
> null);

Possible DOS by spamming the log file?

I suppose you can DOS by filling the access log, too :/

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7Wci4ACgkQHPApP6U8
pFhpnhAAjfeGXFsvte7M84+FCwtlA/AKeXDkdf3cq87D2G1lKPfMHAuiDYNJCnwP
G7CZRxP8S3yAxEd/tzplqFzRYwHK/ZHVfGMOscFSvREb/XxbUvCwdau3Zl/S0LHZ
kvw54K2M5BWpvz9fy7vcqlDlK5ccGkVY5y4J+F8vxyWojLU2KJUPQ0L7Zn750VDI
vUyapcc8xBgMvKMSyBWeWgpuHRzutgssxy/K3OX7xKn4o2OnGgc5C/5tgBRhEUv5
g1dQxD38GC8CoYmw5fPP5kWmRkQ9JWG4sgicrIRw1ZWidmbAhPPcEeibyclPhrw+
c5NegVCblAkGHbnEkxyCIKWoUmkq+w5uStIA7pzTLHK5JbTjALneOgjq3xPRRHa+
sD7R6rhMHWGQ3uZKLicasx8qDug/mscIMiVczSSyj5TAffT71+WetIxDztXnU6uD
2Z1ObTirdGVXAmqd7JcB9Rf2nMQcP4VQrR9yvM40x/zKXsfZytmtNgH3fR587EaI
rK1ye7ftSiR+Tiu/BGhfCbi2mIdVBoXwQ/2T/BR46xKMtsdksna8lZKhzf612PIF
WXVcQdWqDtlOhclIJOXYKyEn1/dhe3G5Mj41eR5h14SU3OrHTz3fCDEVwodrZUH4
8jK7/j6tN3WWHdJw6cFFxoSUzlG7JmYFOr7UniYjrG91cFVwf4g=
=BTn3
-END PGP SIGNATURE-

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



Re: [tomcat] 01/04: WIP for more TLS env resolution

2020-05-31 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 5/29/20 11:25, r...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git
> repository.
>
> remm pushed a commit to branch 8.5.x in repository
> https://gitbox.apache.org/repos/asf/tomcat.git
>
> commit ddc3027029dae386221d355686278dde608c60ee Author: remm
>  AuthorDate: Thu May 28 16:28:19 2020 +0200
>
> WIP for more TLS env resolution
>
> Make explicit each missing env value, to help eventual
> documenting. --- .../catalina/valves/rewrite/ResolverImpl.java
> | 107 +++-- 1 file changed, 97 insertions(+), 10
> deletions(-)
>
> diff --git
> a/java/org/apache/catalina/valves/rewrite/ResolverImpl.java
> b/java/org/apache/catalina/valves/rewrite/ResolverImpl.java index
> 8c108ab..b9749e0 100644 ---
> a/java/org/apache/catalina/valves/rewrite/ResolverImpl.java +++
> b/java/org/apache/catalina/valves/rewrite/ResolverImpl.java @@
> -16,10 +16,12 @@ */ package org.apache.catalina.valves.rewrite;
>
> +import java.io.IOException; import java.nio.charset.Charset;
> +import java.security.cert.X509Certificate; import
> java.util.Calendar; +import java.util.concurrent.TimeUnit;
>
> -import org.apache.catalina.Globals; import
> org.apache.catalina.WebResource; import
> org.apache.catalina.WebResourceRoot; import
> org.apache.catalina.connector.Request; @@ -135,16 +137,101 @@
> public class ResolverImpl extends Resolver {
>
> @Override public String resolveSsl(String key) { -if
> (key.equals("SSL_PROTOCOL")) { -return
> String.valueOf(request.getAttribute(SSLSupport.PROTOCOL_VERSION_KEY));
>
>
- -} else if (key.equals("SSL_SESSION_ID")) {
> -return
> String.valueOf(request.getAttribute(Globals.SSL_SESSION_ID_ATTR));
> -} else if (key.equals("SSL_CIPHER")) { -return
> String.valueOf(request.getAttribute(Globals.CIPHER_SUITE_ATTR)); -
> } else if (key.equals("SSL_CIPHER_USEKEYSIZE")) { -
> return
> String.valueOf(request.getAttribute(Globals.KEY_SIZE_ATTR)); +
> SSLSupport sslSupport = (SSLSupport)
> request.getAttribute(SSLSupport.SESSION_MGR); +try { +
> // FIXME SSL_SESSION_RESUMED +// FIXME
> SSL_SECURE_RENEG +// FIXME SSL_CIPHER_EXPORT +
> // FIXME SSL_CIPHER_ALGKEYSIZE +// FIXME
> SSL_COMPRESS_METHOD +// FIXME SSL_SRP_USER +
> // FIXME SSL_SRP_USERINFO +// FIXME SSL_TLS_SNI +
> if (key.equals("SSL_PROTOCOL")) { +return
> sslSupport.getProtocol(); +} else if
> (key.equals("SSL_SESSION_ID")) { +return
> sslSupport.getSessionId(); +} else if
> (key.equals("SSL_CIPHER")) { +return
> sslSupport.getCipherSuite(); +} else if
> (key.equals("SSL_CIPHER_USEKEYSIZE")) { +return
> sslSupport.getKeySize().toString();

These above lines are now within the try/catch block which reduces
performance somewhat for the attributes that don't need try/catch. Any
reason to bring them under the try/catch?

In fact... which exceptions can actually be thrown, here? Or is the
issue that Java might parse the certificates at this stage in the
pipeline instead of already having been done (because it's rewrite, it
might be "early").

- -chris


> +} else if (key.startsWith("SSL_CLIENT_")) { +
> X509Certificate[] certificates =
> sslSupport.getPeerCertificateChain(); +if
> (certificates != null && certificates.length > 0) { +
> key = key.substring("SSL_CLIENT_".length()); +
> String result = resolveSslCertificates(key, certificates); +
> if (result != null) { +return result; +
> } else if (key.startsWith("SAN_OTHER_msUPN_")) { +
> key = key.substring("SAN_OTHER_msUPN_".length()); +
> // FIXME return certificates[0].getSubjectAlternativeNames() +
> } else if (key.equals("CERT_RFC4523_CEA")) { +
> // FIXME return certificates[0]; +} else if
> (key.equals("VERIFY")) { +// FIXME return
> certificates[0]; +} +} +
> } else if (key.startsWith("SSL_SERVER_")) { +
> X509Certificate[] certificates =
> sslSupport.getLocalCertificateChain(); +if
> (certificates != null && certificates.length > 0) { +
> key = key.substring("SSL_SERVER_".length()); +
> String result = resolveSslCertificates(key, certificates); +
> if (result != null) { +return result; +
> } else if (key.startsWith("SAN_OTHER_dnsSRV_")) { +
> key = key.substring("SAN_OTHER_dnsSRV_".length()); +
> // FIXME return certificates[0].getSubjectAlternativeNames() +
> } +} +} +} catch (IOException
> e) { +// TLS access error +} +return
> null; +} + +private String resolveSslCertificates(String
> key, X509Certificate[] certificates) { +if
> (key.equals("M_VERSION")) { +return
> String.valueOf(certificates[0].getVersion()); +

Re: [tomcat] branch 7.0.x updated: Use parametric replacement to ensure the proper version of wsdl4j is written to Eclipse's .classpath file.

2020-05-15 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'd like to talk about this.

First, this is a patch to Tomcat 7 where a single version number
(wsdl4j) wasn't updated in all the places it needed to be updated
(specifically, the Eclipse .classpath file).

Rather than simply updating the version number, I replaced it with a
replaceable token which always uses the version set in
build.properties.default.

This means that the version number is set in only one place:
build.properites(.default)? instead of having to be set in at least 2
places.

If everyone likes this strategy, I can extend it to the other
versioned libraries we use, and also push it to the other branches.

WDYT?

- -chris

On 5/15/20 10:07, schu...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git
> repository.
>
> schultz pushed a commit to branch 7.0.x in repository
> https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/7.0.x by this
> push: new afda9f0  Use parametric replacement to ensure the proper
> version of wsdl4j is written to Eclipse's .classpath file. afda9f0
> is described below
>
> commit afda9f0d2d2d0bc7b5a870f6df97603354655109 Author: Christopher
> Schultz  AuthorDate: Fri May 15
> 10:05:59 2020 -0400
>
> Use parametric replacement to ensure the proper version of wsdl4j
> is written to Eclipse's .classpath file. --- build.xml
> | 3 ++- res/ide-support/eclipse/eclipse.classpath | 2 +- 2 files
> changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/build.xml b/build.xml index 866bad3..973646e 100644
> --- a/build.xml +++ b/build.xml @@ -3297,9 +3297,10 @@
> skip.installer property in build.properties" />
> depends="download-compile, extras-webservices-prepare,
> download-test-compile" description="Prepares the source tree to be
> built in Eclipse">
>
> + value="${wsdl4j-lib.version}" />   file="${tomcat.home}/res/ide-support/eclipse/eclipse.project"
> tofile="${tomcat.home}/.project"/> - file="${tomcat.home}/res/ide-support/eclipse/eclipse.classpath"
> tofile="${tomcat.home}/.classpath"/> + file="${tomcat.home}/res/ide-support/eclipse/eclipse.classpath"
> tofile="${tomcat.home}/.classpath" filtering="true" />
>
>   dir="${tomcat.home}/.settings" /> diff --git
> a/res/ide-support/eclipse/eclipse.classpath
> b/res/ide-support/eclipse/eclipse.classpath index afd1232..74c174b
> 100644 --- a/res/ide-support/eclipse/eclipse.classpath +++
> b/res/ide-support/eclipse/eclipse.classpath @@ -23,7 +23,7 @@
>  path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/>  kind="var" path="ANT_HOME/lib/ant.jar"/>  path="TOMCAT_LIBS_BASE/jaxrpc-1.1-rc4/geronimo-spec-jaxrpc-1.1-rc4.jar
"/>
>
>
- -
> + path="TOMCAT_LIBS_BASE/wsdl4j-@wsdl4j-lib.version@/wsdl4j-@wsdl4j-lib.
version@.jar"/>
>
>

>  path="TOMCAT_LIBS_BASE/easymock-3.2/easymock-3.2.jar"/>
>  path="TOMCAT_LIBS_BASE/hamcrest-1.3/hamcrest-core-1.3.jar"/>
>
>
> -
>
>
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6+pRAACgkQHPApP6U8
pFhX5w/+O0dVTHL5UROhgJzTq74AmBrKHml57IkY1LVN+Wv9sWnw+X1s/QCFzamb
fVZ+TZV4hg2xIkFDyzUTwCtPULVtqsBZChIyQDzW/rh9ClHKqTsOE2D6qOHMpcwa
KMlOFb2wb/Z1GuxtHaH8cHZJnVtUjSv0STkKTZhewXGbNkMnXoacXO/1ezaY5vDY
5v4O8PRCDiTIXAMfncI1jORwDvbGBMqyQHl++QG6SiY5L5bp0xIyvtf+j/+8g6Ly
BljCXZQC69ddm3dX5K88gdhsiXphzVZMaeyfGVk3AvCygwy3vAimTsuB8Dho6RUZ
A+Wm2BmEYUpS3bdhhh8VpsD54rJ0q5L1BFLqrfot4+KLA78VLVWsam3IUqHZqIyu
jl8TWHGl4NzRdsMFNm5Y4PnfkWBtMWtG7HyVea2uBLKmwFa9UQ3NA+/dwE8EKGAg
ptz1e2GtgCAwUPWx8d/Z9+4hPOKLBgCuKVpm0YvVedrBCwHZCNKUbJiQspI2lSOF
X4fqzFT5WrSBXpBOUk3FuwLQraDeXecEfalNVgfaJESeRM/KoohHULSWBLCfFQ2R
kvueI0Kxi5WXFcdLFp2AvenL4fHPVYyt0MoAZ6gIArCSfvVZKNPFa1saVtr+yoKr
94A7aOoVjOLR6DygUNj7UFBlGz/uCbg9MkHxvBAxykH0zZg2oik=
=VYFy
-END PGP SIGNATURE-

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



Re: Session serialization uses wrapper objects instead of primitives

2020-05-15 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 5/15/20 07:36, Konstantin Kolinko wrote:
> чт, 14 мая 2020 г. в 18:48, Christopher Schultz
> :
>>
>> All,
>>
>> I'm interested in the history of the
>> StandardSession.writeObjectData method. I've been looking at it
>> lately because I'm interested in possibly (optionally) encrypting
>> the sessions in the backend session store. But this isn't about
>> encryption at all.
>>
>> The code for StandardSession.doWriteObject(ObjectOutputStream
>> stream) looks like this:
>>
>>
>> // Write the scalar instance variables (except Manager)
>> stream.writeObject(Long.valueOf(creationTime));
>> stream.writeObject(Long.valueOf(lastAccessedTime));
>> stream.writeObject(Integer.valueOf(maxInactiveInterval));
>> stream.writeObject(Boolean.valueOf(isNew));
>> stream.writeObject(Boolean.valueOf(isValid));
>> stream.writeObject(Long.valueOf(thisAccessedTime));
>
> If I understand correctly, with objects you can read them with the
> same 'readObject()' object method and decide what to do with the
> received value.  With primitives you have to decide upfront what
> reading method you are going to call, and calling a wrong one will
> result in a fatal failure where the rest of the data cannot be read
> at all.
>
> For example, StandardSession.doReadObject has the following code:
>
> // The next object read could either be the number of attributes
> (Integer) or the session's // authType followed by a Principal
> object (not an Integer) Object nextObject = stream.readObject(); if
> (!(nextObject instanceof Integer)) {

This is true: changing from objects to primitives means that no
changes can be made in the future such as re-ordering, changing the
data type, etc. without breaking backward-compatibility.

The metadata at the "beginning" of the stream is fairly stable, so I
think it's safe to make this change.

We could always write a version-number to the storage if we wanted. If
we want to get really crazy, we can go full protobuf[1].

- -chris

[1] https://developers.google.com/protocol-buffers/
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6+pIYACgkQHPApP6U8
pFiRhRAAyCgUGymuV5dlYqVEYPkHtiOUHlmbxrcoeTGU9KfEDnKPZ0frOtdit1X8
POiBEelQooQYwC2AuYxQy0IbdZhCjtZwTX/voi1ieTTH0SQXADVVkD94jkbd2qVQ
Izzn5aWc2KN0/+tDA0iPQtzntP7NhBJ3eCziz7cPxXbPcJCTSLAJr2OZJC7qPvGv
Tit35FLpVyoMD0XE83tnZmEtczTSgKXC2qTHVtOP4/yObl/+JkAG7cUroKINv510
0bAvkqZ1BQnM6ocrKjUcA3GHOw8wPlnwu4B5g2sVXlfbm/Yg0VK9J8r5nUb/KOeZ
iHwPop/FUammNIFJUHGwoVps8pvYHRn4GC2dFotIodrmi62P8B/7NiDW6fXfK/0E
DCJoPdK29Kwy6r9CvMBRy9lbYx/0FcYv3Gb1m9nknAdJgaql55RCVSEUPSZ7J5on
6cnmIFNxKZw0evpBbTMzfuSu+3uGwSnp1VzRN4wCM8d8Ram8pt/3GmK0tt41ADDw
VS8nbzeEmG1G/6MwCj5W1u11I1KLQl6bVcoLHLrREQQyS0X5+1Spg4v1av+kU7N9
uccb2sv6480LiaZvr+oWv5V1QlWKdSZgfekAsv5zWtaBIdw7MLwuY+0vvOYB682u
xpUs2PBLWQHHHrHQRqLtYLBsa3l5imP4w2h1z3F5pwZTQfoJXwk=
=UE1r
-END PGP SIGNATURE-

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



[tomcat] branch 7.0.x updated: Use parametric replacement to ensure the proper version of wsdl4j is written to Eclipse's .classpath file.

2020-05-15 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new afda9f0  Use parametric replacement to ensure the proper version of 
wsdl4j is written to Eclipse's .classpath file.
afda9f0 is described below

commit afda9f0d2d2d0bc7b5a870f6df97603354655109
Author: Christopher Schultz 
AuthorDate: Fri May 15 10:05:59 2020 -0400

Use parametric replacement to ensure the proper version of wsdl4j is 
written to Eclipse's .classpath file.
---
 build.xml | 3 ++-
 res/ide-support/eclipse/eclipse.classpath | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/build.xml b/build.xml
index 866bad3..973646e 100644
--- a/build.xml
+++ b/build.xml
@@ -3297,9 +3297,10 @@ skip.installer property in build.properties" />
   depends="download-compile, extras-webservices-prepare, 
download-test-compile"
   description="Prepares the source tree to be built in Eclipse">
 
+
 
 
-
+
 
 
 
diff --git a/res/ide-support/eclipse/eclipse.classpath 
b/res/ide-support/eclipse/eclipse.classpath
index afd1232..74c174b 100644
--- a/res/ide-support/eclipse/eclipse.classpath
+++ b/res/ide-support/eclipse/eclipse.classpath
@@ -23,7 +23,7 @@
 
 
 
-
+
 
 
 


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



[tomcat] branch 7.0.x updated: Clarify how to set an authenticated principal using tomcatAuthentication="false".

2020-05-15 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/7.0.x by this push:
 new 50fafec  Clarify how to set an authenticated principal using 
tomcatAuthentication="false".
50fafec is described below

commit 50fafec09c1b4313d8296312065204f092962112
Author: Christopher Schultz 
AuthorDate: Fri May 15 09:56:56 2020 -0400

Clarify how to set an authenticated principal using
tomcatAuthentication="false".
---
 webapps/docs/config/ajp.xml | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/webapps/docs/config/ajp.xml b/webapps/docs/config/ajp.xml
index 0b93fd8..98df292 100644
--- a/webapps/docs/config/ajp.xml
+++ b/webapps/docs/config/ajp.xml
@@ -524,9 +524,11 @@
 
   If set to true, the authentication will be done in 
Tomcat.
   Otherwise, the authenticated principal will be propagated from the native
-  webserver and used for authorization in Tomcat. Note that this principal
-  will have no roles associated with it.
-  The default value is true. If
+  webserver and used for authorization in Tomcat. 
+  The web server must send the user principal (username) as a request
+  attribute named REMOTE_USER.
+  Note that this principal will have no roles associated with it.
+  The default value is true. If
   tomcatAuthorization is set to true this
   attribute has no effect.
 


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



[tomcat] branch 8.5.x updated: Clarify how to set an authenticated principal using tomcatAuthentication="false".

2020-05-15 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/8.5.x by this push:
 new 7393b00  Clarify how to set an authenticated principal using 
tomcatAuthentication="false".
7393b00 is described below

commit 7393b00780838e5735d9d482409a290931e7c0e2
Author: Christopher Schultz 
AuthorDate: Fri May 15 09:56:56 2020 -0400

Clarify how to set an authenticated principal using
tomcatAuthentication="false".
---
 webapps/docs/config/ajp.xml | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/webapps/docs/config/ajp.xml b/webapps/docs/config/ajp.xml
index 9d10525..b7afdd4 100644
--- a/webapps/docs/config/ajp.xml
+++ b/webapps/docs/config/ajp.xml
@@ -538,9 +538,11 @@
 
   If set to true, the authentication will be done in 
Tomcat.
   Otherwise, the authenticated principal will be propagated from the native
-  webserver and used for authorization in Tomcat. Note that this principal
-  will have no roles associated with it.
-  The default value is true. If
+  webserver and used for authorization in Tomcat. 
+  The web server must send the user principal (username) as a request
+  attribute named REMOTE_USER.
+  Note that this principal will have no roles associated with it.
+  The default value is true. If
   tomcatAuthorization is set to true this
   attribute has no effect.
 


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



[tomcat] branch 9.0.x updated: Clarify how to set an authenticated principal using tomcatAuthentication="false".

2020-05-15 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new dfba434  Clarify how to set an authenticated principal using 
tomcatAuthentication="false".
dfba434 is described below

commit dfba4345c120f461b028d58271eb53aa4d26114b
Author: Christopher Schultz 
AuthorDate: Fri May 15 09:56:56 2020 -0400

Clarify how to set an authenticated principal using
tomcatAuthentication="false".
---
 webapps/docs/config/ajp.xml | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/webapps/docs/config/ajp.xml b/webapps/docs/config/ajp.xml
index 5b20d6f..2d4fa42 100644
--- a/webapps/docs/config/ajp.xml
+++ b/webapps/docs/config/ajp.xml
@@ -534,9 +534,11 @@
 
   If set to true, the authentication will be done in 
Tomcat.
   Otherwise, the authenticated principal will be propagated from the native
-  webserver and used for authorization in Tomcat. Note that this principal
-  will have no roles associated with it.
-  The default value is true. If
+  webserver and used for authorization in Tomcat. 
+  The web server must send the user principal (username) as a request
+  attribute named REMOTE_USER.
+  Note that this principal will have no roles associated with it.
+  The default value is true. If
   tomcatAuthorization is set to true this
   attribute has no effect.
 


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



[tomcat] branch master updated: Clarify how to set an authenticated principal using tomcatAuthentication="false".

2020-05-15 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 8598bd1  Clarify how to set an authenticated principal using 
tomcatAuthentication="false".
8598bd1 is described below

commit 8598bd1d9f202d31f729bf9cc57f845b56fc29bb
Author: Christopher Schultz 
AuthorDate: Fri May 15 09:56:56 2020 -0400

Clarify how to set an authenticated principal using
tomcatAuthentication="false".
---
 webapps/docs/config/ajp.xml | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/webapps/docs/config/ajp.xml b/webapps/docs/config/ajp.xml
index 579c9fa..cd7a8ad 100644
--- a/webapps/docs/config/ajp.xml
+++ b/webapps/docs/config/ajp.xml
@@ -524,9 +524,11 @@
 
   If set to true, the authentication will be done in 
Tomcat.
   Otherwise, the authenticated principal will be propagated from the native
-  webserver and used for authorization in Tomcat. Note that this principal
-  will have no roles associated with it.
-  The default value is true. If
+  webserver and used for authorization in Tomcat. 
+  The web server must send the user principal (username) as a request
+  attribute named REMOTE_USER.
+  Note that this principal will have no roles associated with it.
+  The default value is true. If
   tomcatAuthorization is set to true this
   attribute has no effect.
 


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



Re: Session serialization uses wrapper objects instead of primitives

2020-05-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 5/14/20 14:21, Mark Thomas wrote:
> On 14/05/2020 18:41, Christopher Schultz wrote:
>> Mark,
>>
>> On 5/14/20 12:53, Mark Thomas wrote:
>>> On 14/05/2020 17:46, Mark Thomas wrote:
>>>> On 14/05/2020 16:48, Christopher Schultz wrote:
>>>>> All,
>>>>>
>>>>> I'm interested in the history of the
>>>>> StandardSession.writeObjectData method. I've been looking
>>>>> at it lately because I'm interested in possibly
>>>>> (optionally) encrypting the sessions in the backend session
>>>>> store. But this isn't about encryption at all.
>>>>>
>>>>> The code for
>>>>> StandardSession.doWriteObject(ObjectOutputStream stream)
>>>>> looks like this:
>>>>>
>>>>>
>>>>> // Write the scalar instance variables (except Manager)
>>>>> stream.writeObject(Long.valueOf(creationTime));
>>>>> stream.writeObject(Long.valueOf(lastAccessedTime));
>>>>> stream.writeObject(Integer.valueOf(maxInactiveInterval));
>>>>> stream.writeObject(Boolean.valueOf(isNew));
>>>>> stream.writeObject(Boolean.valueOf(isValid));
>>>>> stream.writeObject(Long.valueOf(thisAccessedTime));
>>>>>
>>>>>
>>>>> Is there any reason we are writing object wrappers for
>>>>> these primitive members instead of just writing the
>>>>> primitives directly?
>>>>
>>>> That code goes all the way back to at least Tomcat 3.1.x
>>>> (20+ years ago).
>>>>
>>>>> It turns out that the byte stream is identical whether one
>>>>> uses objects or primitives,
>>>>
>>>> That surprises me. Looking at the JRE source code it really
>>>> surprises me. So much that I am going to go and try it for
>>>> myself.
>>
>>> My testing shows the opposite. There is a significant
>>> difference between writing primitives and writing objects.
>>
>> Hmm. I did a micro-test with just writing a single
>> Long.valueOf() value and a (primitive) long alone to an
>> ObjectOutputStream. I didn't test the StandardSession itself.
>
> I performed the same micro-test.
>
>>> Given backwards compatibility requirements we can't change this
>>> in 9.0.x and earlier.
>>
>> Agreed.
>>
>>>> One reason we might want to stick with writing objects is to
>>>> support sessionAttributeValueClassNameFilter. I'm only going
>>>> from reading the source so I could easily have missed
>>>> something but it looks like that will only work if we
>>>> write/read objects.
>>
>>> We only care about this for session attributes. We know our
>>> internal attributes are safe so we could switch to primitives
>>> in 10.0.x.
>>
>> I'll have to play-around a bit to see what was wrong with my
>> initial tes t.

So my test was bunk, the data on-the-wire (so to speak) is very
different, and there is no way at all to make them compatible. :/

Perhaps a rewindable input stream would work, but it's just not really
that important.

I think it's okay to make a breaking change at 10.0, but only if
anyone really cares. It saves a couple of bytes which can add up.

In my microtest, I wrote a java.lang.Long value and a (primitive) long
to two separate files. The object-file was 82 bytes and the
primitive-file was 14 bytes. It looks like after the 2-byte header and
2-byte version identifier, the primitive long is written as "block
data" with a 1-byte length (8) and then the 8 bytes of the long. The
object flavor is ... more verbose.

So we get almost 90% savings for a single long value. On the other
hand, the primitive only values going into sessions are the metadata
and not the attributes, which will dominate the bulk of the data (or
should, anyway).

I still think this is worth doing.

Any objections?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl69sXYACgkQHPApP6U8
pFi6pg/9ExBQhRRlUv4QPUVDJEhJ8pN6KfBIoHgd/UWw2zYxjeifhDrN+biK2lLG
GHWmJuF+wEAFz9xtYqN46q1QqSKIQcWTAqI05NchNlqFd29JHwj+9QZV00VTd0eK
My4MTCVY4dSObJrePyw14tEHyRVcFl539bDhtez7fnjOGkq4EGNXvr7ep9L3w5GB
ckwKAp1OuFYz5/0ZCCDEVdRiSpoXAac06B5v0FUQb3TBn06gdavUJb9q0HM57RjI
0FkQHPyZ1ibfWOOLldBrCgA+7SygGiD6LO2nMo5Fgy1A4l5W/uekkhW96FXBKHng
/ocXJRQSkeDoanpQmu5pC/Ru1S0bNjZCIo9OMS0de6iEMEO3wPtvuLYhINYydk6E
3ZNx+EPZEFPoZuB1K0peWNDgFsE3ar5gL+y6cvztNoZtT1WymoDS6uQ4OvGXcXNL
61SOSe3CmqHF0dQTlD/Xikakumz4Kefny5QGw/XlchPVNCqUmvgxUwYPb965kwz3
Vt/3nib0QgKxbR0j54InFIRkG7gPuGyUaL0kwtMbFEdOTw+PqAEyIPSqIRtmkhVG
Mzf6ikh+TOToYi+OIJXUMloaVL8xafAo6hKTc7lbu2hAUv9bE47X6uVyQmD7Yxqu
R3LQGo3OYX9+GBdKBhgvbZB9bEkUImMbsgIXKIUScGaMH4RdtBE=
=AZle
-END PGP SIGNATURE-

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



Re: Session serialization uses wrapper objects instead of primitives

2020-05-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 5/14/20 14:21, Mark Thomas wrote:
> On 14/05/2020 18:41, Christopher Schultz wrote:
>> Mark,
>>
>> On 5/14/20 12:53, Mark Thomas wrote:
>>> On 14/05/2020 17:46, Mark Thomas wrote:
>>>> On 14/05/2020 16:48, Christopher Schultz wrote:
>>>>> All,
>>>>>
>>>>> I'm interested in the history of the
>>>>> StandardSession.writeObjectData method. I've been looking
>>>>> at it lately because I'm interested in possibly
>>>>> (optionally) encrypting the sessions in the backend session
>>>>> store. But this isn't about encryption at all.
>>>>>
>>>>> The code for
>>>>> StandardSession.doWriteObject(ObjectOutputStream stream)
>>>>> looks like this:
>>>>>
>>>>>
>>>>> // Write the scalar instance variables (except Manager)
>>>>> stream.writeObject(Long.valueOf(creationTime));
>>>>> stream.writeObject(Long.valueOf(lastAccessedTime));
>>>>> stream.writeObject(Integer.valueOf(maxInactiveInterval));
>>>>> stream.writeObject(Boolean.valueOf(isNew));
>>>>> stream.writeObject(Boolean.valueOf(isValid));
>>>>> stream.writeObject(Long.valueOf(thisAccessedTime));
>>>>>
>>>>>
>>>>> Is there any reason we are writing object wrappers for
>>>>> these primitive members instead of just writing the
>>>>> primitives directly?
>>>>
>>>> That code goes all the way back to at least Tomcat 3.1.x
>>>> (20+ years ago).
>>>>
>>>>> It turns out that the byte stream is identical whether one
>>>>> uses objects or primitives,
>>>>
>>>> That surprises me. Looking at the JRE source code it really
>>>> surprises me. So much that I am going to go and try it for
>>>> myself.
>>
>>> My testing shows the opposite. There is a significant
>>> difference between writing primitives and writing objects.
>>
>> Hmm. I did a micro-test with just writing a single
>> Long.valueOf() value and a (primitive) long alone to an
>> ObjectOutputStream. I didn't test the StandardSession itself.
>
> I performed the same micro-test.
>
>>> Given backwards compatibility requirements we can't change this
>>> in 9.0.x and earlier.
>>
>> Agreed.
>>
>>>> One reason we might want to stick with writing objects is to
>>>> support sessionAttributeValueClassNameFilter. I'm only going
>>>> from reading the source so I could easily have missed
>>>> something but it looks like that will only work if we
>>>> write/read objects.
>>
>>> We only care about this for session attributes. We know our
>>> internal attributes are safe so we could switch to primitives
>>> in 10.0.x.
>>
>> I'll have to play-around a bit to see what was wrong with my
>> initial tes t.
>
> JRE version? I used a newish Java 8. Long value? I used 1000. I
> did something stupid? Source code here:
>
> https://github.com/markt-asf/tomcat-bugs/blob/master/src/java/org/apac
he/tomcat/ObjectStreams.java

My
>
problem appears to be that I copy-pasted and didn't change one of
the calls. *eyeroll*

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl69rfEACgkQHPApP6U8
pFgO2w/+Mld4Akm77AOAOWRaqVQVi6BOXOUJE5uRGq8XlsTvx2U4GM6PTuT4F/Tp
Ow9g9NdpK89kPxBDDK+wfZF2qDmwO7uXWqKUr6OQ24qJR2aEerTQsn90GvbKp3j3
SmqeKVGMK8TZJlLtsw7YiMguH0z8v38wulwovBFPdVBZsPTKETo0DjrTxR0oZhrD
lZYKo5qwIF+LWd9NtdLSog9s/nMuC9jJoqwjD5azcRbmpAjYU9oIeQX8q3nqcOFh
DFxXVCbzzLe6EQlkSg0Bpc0PU3FoK5qKPaAcMdjtaVP+L28nbTVkTCugDcxcwNou
M2yi88gxtCk7OOknfum3ukNZI1gvRHvEHMQINdQaXmJ32oxy5QpdJ1ICew2Elo45
Hakms9os6i5QIz2XdF8BZ7ihqtuxkb3stzEi66KTtiTp41V6aHHTiAHIpsJfTsHZ
ZTiaS9UPHZVAMnSE6/QvIAz68IkA3/cQvz9Ed+lClp6r4vqWDomkFsqKH1NDMQCX
gCnTj/3zNXb4+FovhzFnEEM+Pbwe0c20y/I+piTe5S6U6Zcl958au4MNToBCr/t0
YXn0OkAlc24EJBOP37b3406SQEfmBDd4FP7z8fY9QTwT3cOBH3dvzaqYhL8mMBhF
ToVs/lbO5KoBJG0xDC3gK/22r19oyNUaiLa1OlUC533IeMpmloc=
=DHdr
-END PGP SIGNATURE-

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



Re: Session serialization uses wrapper objects instead of primitives

2020-05-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 5/14/20 12:53, Mark Thomas wrote:
> On 14/05/2020 17:46, Mark Thomas wrote:
>> On 14/05/2020 16:48, Christopher Schultz wrote:
>>> All,
>>>
>>> I'm interested in the history of the
>>> StandardSession.writeObjectData method. I've been looking at it
>>> lately because I'm interested in possibly (optionally)
>>> encrypting the sessions in the backend session store. But this
>>> isn't about encryption at all.
>>>
>>> The code for StandardSession.doWriteObject(ObjectOutputStream
>>> stream) looks like this:
>>>
>>>
>>> // Write the scalar instance variables (except Manager)
>>> stream.writeObject(Long.valueOf(creationTime));
>>> stream.writeObject(Long.valueOf(lastAccessedTime));
>>> stream.writeObject(Integer.valueOf(maxInactiveInterval));
>>> stream.writeObject(Boolean.valueOf(isNew));
>>> stream.writeObject(Boolean.valueOf(isValid));
>>> stream.writeObject(Long.valueOf(thisAccessedTime));
>>>
>>>
>>> Is there any reason we are writing object wrappers for these
>>> primitive members instead of just writing the primitives
>>> directly?
>>
>> That code goes all the way back to at least Tomcat 3.1.x (20+
>> years ago).
>>
>>> It turns out that the byte stream is identical whether one
>>> uses objects or primitives,
>>
>> That surprises me. Looking at the JRE source code it really
>> surprises me. So much that I am going to go and try it for
>> myself.
>
> My testing shows the opposite. There is a significant difference
> between writing primitives and writing objects.

Hmm. I did a micro-test with just writing a single Long.valueOf()
value and a (primitive) long alone to an ObjectOutputStream. I didn't
test the StandardSession itself.

> Given backwards compatibility requirements we can't change this in
> 9.0.x and earlier.

Agreed.

>> One reason we might want to stick with writing objects is to
>> support sessionAttributeValueClassNameFilter. I'm only going from
>> reading the source so I could easily have missed something but it
>> looks like that will only work if we write/read objects.
>
> We only care about this for session attributes. We know our
> internal attributes are safe so we could switch to primitives in
> 10.0.x.

I'll have to play-around a bit to see what was wrong with my initial tes
t.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl69guMACgkQHPApP6U8
pFg40BAAowAyGeHKQAWyj4OjZVwuZJnZpNaBsK0Rthw2rmCPFVVzBb37IDV7svxk
HjmYyvKSM3NxRke/ftSysfg7hnGAaK0gFuyk8XSqUp5ZXkJUzHoS/44Ite1Fsqux
8iwc+djveuybUEacxz9PGLH9+vmXVI9EhvYUHKXyWS5w5KKXBVghPcrnL9gjBbTs
F7a92V6xiRUdnhDBpixOEBnwihfAisd1CS9XQjIAhVB2T0mkSsinZBFqzy5HZX4a
ohMhX1aAFKyHEV9rHeNlV9mTzj1Wg+rgXEVW4hWnGzmt+iS3KdLxdRZRw+6v78O6
M4cYPclPYek//toB7mf+FFyrPtyfVMjG9lvqP3serXQ8Ujh7HvUNQX91/kgpC9mQ
xWJQqpsR7CwkmleU/XFFcyz9Dp+N/SlZSomPneeLRj4+Epx+AX8WgXVZMZdJNXVf
MN5IIix7K9ff+drbCgwFsC2Yf1M76Mf6VQSXKdNmxZ5AfXJy9Kzk8z2rukj63wMA
wHs3CEjHjN7PevbgUbvQnA6Ze92ZRlzQqhrZl400/lriYzGeePQmqeVg5/mlAWLW
2YJQRsmaA8Q7QI63vZXkBYGBA1/lh6NDFF3mVqHCxAy3nUfSx3VNgwVZSk3aItqw
eDgNxRJkhR43MLj1GDQTAVjHF+XrMw87xDp58cI0pxhgavGzlsI=
=2xPi
-END PGP SIGNATURE-

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



Encrypting session data

2020-05-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Tomcat has provided session-persistence mechanisms as far back as I
can remember, and on-disk/in-database/in-memcached/in-redis storage is
a somewhat popular practice.

Occasionally, we (the community) are asked how to protect the data in
those back-end stores e.g. using encryption. The answer has usually
been "you need to trust your data store" and that Tomcat simply
doesn't provide this kind of facility.

A few years ago, I started advocating treating all networks as
un-trusted, including "trusted" ones. If you've seen any of my
presentations or read any of my comments on networks, you'll know that
I think all network communications should be encrypted, even within
corporate networks or other environments where the network should be
considered "trusted".

I think a reasonable extension of this policy is to not trust your
storage mechanisms any farther than necessary. For example, if you are
storing Tomcat sessions on-disk or in a database, there are very few
other things that need to snoop (or modify!) that data besides Tomcat
itself. So there isn't any reason NOT to add something like encryption
to Tomcat for session stores.

I've been looking at StandardSession, which is Serializable.
DeltaSession extends StandardSession and adds some magic for
clustering which is /separate from/ the standard serialization
mechanism -- at least when sending session-changes; I haven't yet
looked at bulk-migration of sessions between cluster nodes.

Such encryption could easily be implemented in
StandardSession.doWriteObject/doReadObject by simply performing the
existing serialization operation but adding an encryption step,
finally writing a byte string into the ObjectOutputStream. An
encryption algorithm+key could be added to the SessionManager and, if
present, we add symmetric encryption to the process.

I have a few questions about this for the community:

1. Does anyone want this? (I definitely know there are some yesses out
there)

2. Is it sufficient to implement this in StandardSession, or do we
need something more configurable / customizable / extensible?

3. Is symmetric encryption sufficient, or is there a reason to
muck-around with asymmetric encryption.

4. Can anyone think of anything that might break (or significantly
degrade) if this were to be added? I'm specifically thinking about
clustering which has its own separate encryption mechanism.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl69a8AACgkQHPApP6U8
pFhbAg/7BkhoAJUx8+r3mfFWx8ClSS0x5A4VMb86tLLM3zt7HTVyCrMuvOP3UTrh
6MnSbLFChJDeZfj39ypqWcocW5R+oB78ROVsJPiIOTsNPxyas7+hCL7D91BqxtGT
U/Q9DGnyWZTYObxlXqI0qqtFSnhN+UWa8ANpFQWGcuI/l1i8rIPHjkSazhFyBkbQ
Rxzed1/15KepSpBunXd3QzPeR3Nn7eFzL/J8EiVEe+T4psscoKGzJ8xRs2OcDj54
q88KqBfq04Dk+G9+KHLxDY2ZXmiP+Mt8uYNXwe/7zLbBtiv6aPdrNMNMS+ejdY+D
lRYX4u7KQmNdO/zIMyJJ/5DHy4MDktl803am+x4Cng4Skeh3Cg78TjeCf+NJ2toE
/lO9aCe/OGKAbZfczV8HSdMDKCgzon4G+6g/8glFlRk1MeuGMs/EfbLnyOB7cb/a
ixT/Tcx0l2U6W9iDNjSfq9+/sxDcmV64htSB5X+IP7GZyd8daOWg4QedkRyN04Dg
cjVPf8/rXtpUR4hY3DQG5GCStCyp7c1+dbBL1b/lBueV2arLK8V6Qz/8oQ2ERags
ZQUgRMuSaNHIp78djg6wDjUg+93ZhQ6Qxt/9pRuPqzkuZZsOGJ6vz9SPJaCYfz2F
9OjUY/G+VOyZi8jryu7c9fwYGO8WU7lGPBFjptOy4pgJdnaZLa4=
=l94x
-END PGP SIGNATURE-

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



Session serialization uses wrapper objects instead of primitives

2020-05-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm interested in the history of the StandardSession.writeObjectData
method. I've been looking at it lately because I'm interested in
possibly (optionally) encrypting the sessions in the backend session
store. But this isn't about encryption at all.

The code for StandardSession.doWriteObject(ObjectOutputStream stream)
looks like this:


// Write the scalar instance variables (except Manager)
stream.writeObject(Long.valueOf(creationTime));
stream.writeObject(Long.valueOf(lastAccessedTime));
stream.writeObject(Integer.valueOf(maxInactiveInterval));
stream.writeObject(Boolean.valueOf(isNew));
stream.writeObject(Boolean.valueOf(isValid));
stream.writeObject(Long.valueOf(thisAccessedTime));


Is there any reason we are writing object wrappers for these primitive
members instead of just writing the primitives directly?

It turns out that the byte stream is identical whether one uses
objects or primitives, but the code is a little more complicated,
generates objects when none are necessary, etc. Here is the
doReadObject code:

creationTime = ((Long) stream.readObject()).longValue();
lastAccessedTime = ((Long) stream.readObject()).longValue();
maxInactiveInterval = ((Integer) stream.readObject()).intValue()
;
isNew = ((Boolean) stream.readObject()).booleanValue();
isValid = ((Boolean) stream.readObject()).booleanValue();
thisAccessedTime = ((Long) stream.readObject()).longValue();

If using primitives, it would be:

creationTime = stream.readLong();
lastAccessedTime = stream.readLong();
maxInactiveInterval = stream.readInt();
isNew = stream.readBoolean();
isValid = stream.readBoolean();
thisAccessedTime = stream.readLong();

I don't believe there is any benefit to using objects over primitives
in this case. If the stream doesn't contain the right object types in
the right order, the operation will fail so they are providing any
e.g. type-safety that you might get by casting to (Number) and then
pulling long value (to convert an int -> long, possibly).

I think the code is easier to read and will generate less temporary
garbage if the wrapper objects are removed.

I think the change will also remain interoperable between versions
since the byte-stream is unchanged.

Any objections to making this change?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl69aFEACgkQHPApP6U8
pFiiGA/+OTShGMP1QvzP9rINT8hyrjhoiXTxCN6cfazQZ3Q8UUXAFA6514tLLkli
3FBfu6CWyAe1S8WvzgkeWg0UospfKjSi3pod/uVjF9Bo4JYyPAe39FV8k74Suotk
HpQNbrrFMp7MeQowXdtns/ua8F+uo77JXTHrdc3eZIhBpfiyyyPQLaC73r/djMwf
v/0iDF/SBAL98fTQsnTqeFVGJGBUkHS1Yvuhr1DQ+I6gpSRn+wUGlvUmrxaNF6J6
opYfBpU53L/2skjN7yC/DC5pnYbgRRzKdoNKzgrNbEbK9dyqEztr4N82+8VdIccj
BJJA+7LqYDkVvrrTSCBL8hTlWr10P609rwX7t+/LHl0SzBVdsdiZurpBD/SRZXbQ
nNU2n2DauAVUDUsKoLR/MvzpGVW3cNJNOqMX8mscA9RkLJwfWTnrohD7YFXtj6iv
D03ekPpOBGSF1TX6JAjgDuciSPD2/Z9NV6wR1yKcfjm/rKkoAnv/orP/ccTsuXnq
fggNFZQAmfp93QJFf2G3wntmR/3fCWjETVWT5CxyTxSdn/Zmj08P2lKiyRUriLd1
4kGnNxLSFgo/UWIgoFaPeITbkupmI9rGQq+LZM1UlnhoHxWj3vVOdCN/Zu+3OpLQ
rFD5YTunZmHDBIcbtHbOmHeAGq7VU1BpvJ7V50jz9LW6OoX6GfQ=
=vEuO
-END PGP SIGNATURE-

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



Re: [VOTE] Release Apache Tomcat 8.5.55

2020-05-06 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

Thanks for RM'ing.

On 5/5/20 18:37, Mark Thomas wrote:
> The proposed Apache Tomcat 8.5.55 release is now available for
> voting.
>
> The major changes compared to the 8.5.54 release are:
>
> - Improve the handling of requests that use an expectation. Do not
> disable keep-alive where the response has a non-2xx status code but
> the request body has been fully read.
>
> - Change default value separator for property replacement to ":-"
> due to possible conflicts. The syntax is now "${name:-default}".
>
> - Update the packaged version of the Tomcat Native Library to
> 1.2.24.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.55/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-126
7/
>
>  The tag is: https://github.com/apache/tomcat/tree/8.5.55
> c8a57e4a2db8e5af314bae48123fb5990da5b7a5
>
> The proposed 8.5.55 release is: [ ] Broken - do not release [X]
> Stable - go ahead and release as 8.5.55

No issues with vanilla servlet application. No Websocket or other
fancy stuff. AJP and HTTP connectors; no TLS.

Unit test failures have to do with OpenSSL version mismatches that I
haven't bothered working-around, yet.

Details:
* Environment
*  Java (build): openjdk version "1.8.0_252" OpenJDK Runtime
Environment (build 1.8.0_252-8u252-b09-1~deb9u1-b09) OpenJDK 64-Bit
Server VM (build 25.252-b09, mixed mode)
*  Java (test): openjdk version "1.8.0_252" OpenJDK Runtime
Environment (build 1.8.0_252-8u252-b09-1~deb9u1-b09) OpenJDK 64-Bit
Server VM (build 25.252-b09, mixed mode)
*  OS:   Linux 4.9.0-9-amd64 x86_64
*  cc:   cc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
*  make: GNU Make 4.1
*  OpenSSL:  OpenSSL 1.1.1 11 Sep 2018
*  APR:  1.5.2
*
* Valid SHA-512 signature for apache-tomcat-8.5.55.zip
* Valid GPG signature for apache-tomcat-8.5.55.zip
* Valid SHA-512 signature for apache-tomcat-8.5.55.tar.gz
* Valid GPG signature for apache-tomcat-8.5.55.tar.gz
* Valid SHA-512 signature for apache-tomcat-8.5.55.exe
* Valid GPG signature for apache-tomcat-8.5.55.exe
* Valid SHA512 signature for apache-tomcat-8.5.55-src.zip
* Valid GPG signature for apache-tomcat-8.5.55-src.zip
* Valid SHA512 signature for apache-tomcat-8.5.55-src.tar.gz
* Valid GPG signature for apache-tomcat-8.5.55-src.tar.gz
*
* Binary Zip and tarball: Same
* Source Zip and tarball: Same
*
* Building dependencies returned: 0
* tcnative builds cleanly
* Tomcat builds cleanly
* Junit Tests: FAILED
*
* Tests that failed:
* org.apache.tomcat.util.net.openssl.ciphers.TestCipher.APR.txt
* org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO.txt
* org.apache.tomcat.util.net.openssl.ciphers.TestCipher.NIO2.txt
*
org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfiguratio
nParser.APR.txt
*
org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfiguratio
nParser.NIO.txt
*
org.apache.tomcat.util.net.openssl.ciphers.TestOpenSSLCipherConfiguratio
nParser.NIO2.txt


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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6y5ccACgkQHPApP6U8
pFiIZg/7BMGvGRlQfRx0KLCPaTXfBiIyVhPYv0EMP29RkqOL5NYyliVMEt5jAgOJ
J+Iifl4P6UX/G3nANLfIYaN3jowhraeGLc2PV7CCrEtQfkQO0QXnXbvALNoloqvq
puFzhTKJp2+Slkf3VnF59TCXcCqWTJsuAG8hTIF+Nvq7aup+IQ/RjSj3HLSrn36q
dKpANrDh3SA2FQL8jMPnb2nHx4BJmJ4BVv8vtNAV163vruSOOoaQou9uTDtlQqtI
/ZGV8GRqTNjoWX003sZ66JirHs8RZyD6sUcmp7XZWSBOolqNCXQWmxdPKWbl/vQT
TLC/cS4r7Xen2yKPNZ6lEcuxPFtmRljw7JUHbZekYIyVqkYqqrhIYKxQ2JYBw9oO
9HV5UCbnJQZO8QnK49Pse0wtJw5172NT2awgEUatTUxvMoI7yOoCb+P5K43LlEHZ
EreWMHY2aE1EVntmPIHOBrtd+owx30v56HagsalMVwvsY9rFDtXDMpt4PPw6al7v
/EIl8E1c4J76as4rUo6gJ+EHz4YVsozg1zo3rYHCMo++emD+I31xU6+CWQzmBLvb
mY8/CRSuStyh1wLndQe8Uyc0Sgf66lHC+BqiZaJUGtUjQSQLq1grGOozCy89wt3h
WeUofjR+3ESYKCZff+EqqGZGQxJR1hE0/7m0ZA3d0QZy8Ftjhl4=
=s4yp
-END PGP SIGNATURE-

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



Re: [Bug 64402] New: mr.vta

2020-05-01 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 5/1/20 04:49, Mark Thomas wrote:
>> Reporter: mblehkos...@gmail.com
>
> Yet another "security researcher" that failed to notice that if you
> try and upload an attachment with MIME type text/html our Bugzilla
> instances will always render it as text/plain.
>
> I'd mind less if these folks actually checked if the attack worked
> and then apologied for wasting our time when they found it didn't.
>
> I've disabled this idiot's account.
>
> I'll delete the issue shortly.

Actually, I think you should leave the issue in BZ and we can
encourage the community to laugh at them for claiming "victory" for a
hack that didn't occur.

Kinda like laughing at the small anatomy of people who "zoom bomb"
meetings.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6sTl8ACgkQHPApP6U8
pFg0nBAAyWvD3GNP974gy9RY4ur6cXlxN9sEibJ3kXGgKsIAeDD4uMdCJMTGUMOR
zh8lspJulxgdTRCacne/PUWqOL8LU2n0SLKw8VAMgH/nxeEFBd4g/zBJY4sj7918
RySlisHU6deMfvaRFMoaJu4/v2Xt9R4/GwDYFR2e4jUirqHNbIB7o+235XvNVLDe
nPeKYoPcjimTvhHyVDPS0fbr2UdlauFjxYbHhz5qvbCQqC2fDpiCNPzulZme9C4v
ZoBJPUiM3DFJG/10ix+cRPds/6RhLguWq+bYjUGZpnp4VnCt8cRDnVkr/MX8xM4g
sFGtFuRhR0gMDWNwy6yw2uyueOSzjgjsJCrbAV9lm27rGEAaGwtKUTkhYxdQlx3r
FE5gMPMlzhNqIiNNo75+1/MoqA0zPPmt3WZpGJRIKxuvGmO7bM/3pZ+6db0bgeUt
BcLtxAKp0q3zd+uK3mkBiRccasb3As6q4iSruTYB1uHD+yIpflXbgZqUGQfHnYRT
IZfjw6b5xtfAguu5EG1rihfTVsKkXiSNbFGkhacfBLWRsYYf3hXD3n6qrrvYRH5A
40hKN+4YLVGYtbU25ihpBMiAaewK81CzjyeOzMmKnXg5+GqC7/bA1bF6IxwJ75if
W4FEleeO+m+FfeP6qDy8k3Dj7w6dEUxq6aCoNd8XTjd3BtuW3JY=
=ocmV
-END PGP SIGNATURE-

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



Re: Dropping reason phrase in WebDavServlet

2020-04-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 4/29/20 15:37, Michael Osipov wrote:
> Am 2020-04-29 um 18:51 schrieb Christopher Schultz:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> Michael,
>>
>> On 4/28/20 18:06, Michael Osipov wrote:
>>> Am 2020-04-20 um 10:25 schrieb Mark Thomas:
>>>> On 18/04/2020 21:19, Michael Osipov wrote:
>>>>> Folks,
>>>>>
>>>>> the WebDAV servlet still sends a reason phrase on
>>>>> multistatus (207).I'd like to drop it in master and 9.0.x.
>>>>> It is inconsistent with the behavior with these versions.
>>>>> Any objections/opinions on dropping it?
>>>>
>>>> I agree it is inconsistent and I'm generally in favour of
>>>> anything that improves consistentcy, simplifies, etc.
>>>>
>>>> RFC 4918 (WebDAV) references RFC 2616 (HTTP/1.1) where the
>>>> language is slightly less strong (the client is "not
>>>> required" to examine it) than RFC 7230 (the client SHOULD
>>>> ignore it). However, even in RFC 2616 an empty reason phrase
>>>> is valid. So I think the specs support this change.
>>>>
>>>> WebDAV clients, particularly the Microsoft implementations,
>>>> can have very specific expectations about server behaviour
>>>> that are not required by the RFC. I think it would be prudent
>>>> to at least test this change to the WebDAV server
>>>> implementation with the current Microsoft WebDAV client
>>>> implementations before rolling it out.
>>>
>>> Finally dropped locally. Tested with CarotDAV, WinSCP and
>>> Windows WebDAV Mini Redirector (Windows Explorer DAV Client)
>>> set with anonymous and SPNEGO authenication. Works like before
>>> (with reason phrase).
>>>
>>> I will go ahead and apply the change to master and 9.0.x.
>>> 8.5.x disables the reason phrase by default. Shall this applies
>>> to it as well? Any objections?
>>
>> Seeing how well-received the original change was (drop reason
>> phrase), perhaps we should limit this to master and not back-port
>> to 9.0, etc.
>
> I understand your concerns. Please consider that 9.0.x doesn't send
> the phrase and doesn't allow to enable it. I think it was an
> oversight that this one wasn't dropped earlier. I won't back port
> this to 8.5.x and 7.0.x. Let's keep it in 9.0.x and see whether we
> receive complains. Is that acceptable?

+1

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6p+m0ACgkQHPApP6U8
pFhp2RAAtLufhy8Iuaq6OywkrRyHTQ6VvFTHRPVtGpOBX5BNXBFwsfgVU4VG7K4g
AZimKlM84s5OIbz671ZOrF9+FmCv8w4n1Ae3paEPEwlRGBv6QPEnIRHpXd1Up2uQ
BBt+cZOYGHnBZ1GDC3YNhCJWCQyg8eWVlCA9TqPcG1AYwhu+3F9F1Lfsb9+gsZ0O
T6BcRJI2yRvh8kwQFtWeZ4Et4rOCfoL3ZNQYNsAmzjB/85ol+Issz2+tOM/82sl9
vA6dIL6BbyaWoNZU5i+HN30Zr+r5EfOPPiBA72CsZJZhkYdriTx8DNFl/a9qZKly
EEyIxioB5z82TtFFqD8ssKUVhnpIZkk3gC34Z7fwdJ1hRHrqZCmc6I3Eili7AdAE
P87tqQu9/egL/CMP7EX3xStXlyergJBgjl/sE/lfsHhrpjsV0mUe8BsLiiafPYVY
j4HXFx1WfL0NB3XUxEckIqlNIQKauMkvJwxXlQ9zqcCW8hirPNpwnerOl27dNWTn
t3geJ6tt9JVa2fpxh61O/x4pVj62ZhASlBtX2T3kOnliHiXMJkz8e92EjiXI+fIS
mynM8v11ehyKjmlcWaolgI97QeRaT2Swg/hl/d0ezymp9J8Fo377V8sTlnV6TNo3
D3UIeiq1IFBoY1Ad6r1N1wb2K9My+no4daRxI0aSqWzWOYeBITY=
=obsQ
-END PGP SIGNATURE-

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



Re: Dropping reason phrase in WebDavServlet

2020-04-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 4/28/20 18:06, Michael Osipov wrote:
> Am 2020-04-20 um 10:25 schrieb Mark Thomas:
>> On 18/04/2020 21:19, Michael Osipov wrote:
>>> Folks,
>>>
>>> the WebDAV servlet still sends a reason phrase on multistatus
>>> (207).I'd like to drop it in master and 9.0.x. It is
>>> inconsistent with the behavior with these versions. Any
>>> objections/opinions on dropping it?
>>
>> I agree it is inconsistent and I'm generally in favour of
>> anything that improves consistentcy, simplifies, etc.
>>
>> RFC 4918 (WebDAV) references RFC 2616 (HTTP/1.1) where the
>> language is slightly less strong (the client is "not required" to
>> examine it) than RFC 7230 (the client SHOULD ignore it). However,
>> even in RFC 2616 an empty reason phrase is valid. So I think the
>> specs support this change.
>>
>> WebDAV clients, particularly the Microsoft implementations, can
>> have very specific expectations about server behaviour that are
>> not required by the RFC. I think it would be prudent to at least
>> test this change to the WebDAV server implementation with the
>> current Microsoft WebDAV client implementations before rolling it
>> out.
>
> Finally dropped locally. Tested with CarotDAV, WinSCP and Windows
> WebDAV Mini Redirector (Windows Explorer DAV Client) set with
> anonymous and SPNEGO authenication. Works like before (with reason
> phrase).
>
> I will go ahead and apply the change to master and 9.0.x. 8.5.x
> disables the reason phrase by default. Shall this applies to it as
> well? Any objections?

Seeing how well-received the original change was (drop reason phrase),
perhaps we should limit this to master and not back-port to 9.0, etc.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6psJEACgkQHPApP6U8
pFjqChAAmskw1+bgKOe9NZ+amXvfOCk/CEzisHcgsPdROREri18PeqluS79AUG9l
x+3DiUq5/L2jf9nVyUQmj4GFxzHR3eCAyI2y0c4hlLurpnPzGZclKM2Xnmfvti68
DWVfOx7HmjuGajI0s3a7bu/KzC1W6o26uubQLwmibOA0O63acGjr49OPQ3hShDsJ
xUE+a9cF20Yz4maeAE9PY855p7XZMOnfdFW3yc7/2xPQbrEGblQLNwajlPkkvZjn
pfLAjiOLMSR2TGabEhT/AXwYuacoGeWrbb3vTbjKDrmcbd4YRN8udzSfS7bCxl9u
ssKd7kZya39WhbqYOe3NfkBMJPf8yGP4WwEEn+LY39TfbxUy/Sfq+E6Uz2hTY4Ru
5TR1honE35CQSThmBmBltkTzWYOn3s9Fm/tpPCGdrLDM40IFF09KGXCQrak3qUCD
6TdpRvrnmthN74fTsUqltLq29YDwgkNv7kVvDuIJozNJG1pjjegZDAlcngL7d6XL
uq/ylVEMzNW0PvDTDHuzN09ixNSPDzOwiX47EWV37OlN7y/GB6EbXHMG3w0flEme
pz5YMAnReO634pGVIaoJC/1K+zDXxQLk+KQnrqSKuNiO1M0bO0TbnFOSX81mkROS
jxWtB3JJC9VuskoR3j4unflOyhwwkozpzq9Y7Kl6Zf6up7Xz2aA=
=UArd
-END PGP SIGNATURE-

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



Re: CTR: requesting review of org.apache.catalina.startup.TestMultipartConfig

2020-04-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 4/28/20 14:03, Mark Thomas wrote:
> On 28/04/2020 15:22, Christopher Schultz wrote:
>> All,
>>
>> I'd like a review of the test-case I wrote for the multipart
>> config stuff.
>>
>> It *works*, but perhaps there are better ways to do the things
>> that I did.
>>
>> Someone who is more familiar with all the various ways of
>> testing Tomcat would probably be able to replace some of my hacks
>> with something a little more straightforward.
>
> I don't see anything that jumps out at me as needing to be
> changed.

Excellent, thanks. Using reflection to force my way into those private
methods seemed a little ugly. I'm not familiar enough with the rest of
the unit tests to know if that's an often-used technique or if there
was a better way of exposing the internals for a unit-test.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6psB0ACgkQHPApP6U8
pFi5NhAAsyYBPv2QefM2iIFZhr8/3GnIaoCGLsslx2WNUJStj9RMVEPoJ4pa9EZ0
zxgIUPY7t4RFQ993WzntrK43JNPqS5cQ2U+KhfL86VbHGhl5Ka3ypfZLLQkPT1ER
dwJI4bE8Lp8MyRR7GuxJbLmLUmWzTBEXpxwMcBrATKQQmIkaF30fwCiTVJdWpF78
LoKYd7yHuvH4EWUWGqMpaUoRzUW5dvXA66tzfOPic2/6hTk+cghQt1Hu5M+/jjjI
sRXlle2P1TfTKc96Wr4i+hMiK7KbHKgbkPX9UHhagdE109Ldxqspk0mR4E3mR2gs
yHB1KTbLO5sxQcDuP/uuyM+1u7pyIDTkNTlzvEQfQaPd91FzWOpXZNFxwxRozbXH
E3Ftfj9ESHf390YKT0EmlG2x96PDkLHglRy0ooZTMn32GziY2u0wFXhrRVswTnVk
WDjYxJi7MK+vFL5OzFOFLMK0UBWc13iLU3TGpsudlf0bt9eSALG/7RPdgXxtTOJl
K7SQu0BqzTakS6eT/CFMjyIZfxPhwHsKOau+Dni70ZHOTs6rEOvVsTok2eDTWvdD
F421+sIstucFJIKLfbaivMiIUumPZCs9bgkeTJ5DfwQUJsIXN+GgVjCkGaStL+MO
6SzQbhg6LkiHQm1MWL5hwKGN3Q5WOKXDOmXVlwGoYybbq8IOMNk=
=RIEq
-END PGP SIGNATURE-

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



Re: git-fu is (still) weak

2020-04-28 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Coty,

On 4/28/20 10:45, Coty Sutherland wrote:
>
>
> On Tue, Apr 28, 2020 at 10:21 AM Christopher Schultz
>  <mailto:ch...@christopherschultz.net>>
wrote:
>
> Rémy,
>
> On 4/27/20 18:41, Rémy Maucherat wrote:
>> On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz
>> > <mailto:ch...@christopherschultz.net>
>> <mailto:ch...@christopherschultz.net
> <mailto:ch...@christopherschultz.net>>> wrote:
>
>> All,
>
>> I tried again to commit to tc10 branch, got commit id
>> 8dddc11512fbd3b91ed9d737a42e4b8415458ddf.
>
>> Moving to tc9 branch:
>
>> $ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf
>> fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf
>
>> - From tc10:
>
>> $ git remote -v origin  https://github.com/apache/tomcat (fetch)
>> origin  https://github.com/apache/tomcat (push)
>
>> - From tc9.0.x:
>
>> $ git remote -v origin  https://github.com/apache/tomcat (fetch)
>> origin  https://github.com/apache/tomcat (push)
>
>> My 9.0.x local is all up-to-date with github, and github can see
>> the commit in tc10.
>
>> Other than manually handing the diffs myself, I have no idea
>> what to do, next. :(
>
>
>>> I tried and it looked "ok" to me.
>
> Okay, what did you do? When I try to cherry-pick from 10 -> 9 I
> still get the "bad object" error.
>
> When cherry-picking your commits from 9.0.x -> 8.5.x, I get a
> merge-conflict (of course) because you have already merged them.
>
> Did I do something weird with the first commit?
>
> Maybe I don't have my branches in order?
>
> - From my tomcat-trunk (10) directory:
>
> $ git branch -a 9.0.x * master remotes/origin/7.0.x
> remotes/origin/8.5.x remotes/origin/9.0.x
> remotes/origin/BZ-63636/tomcat-8.5.x
> remotes/origin/BZ-63636/tomcat-9.0.x remotes/origin/BZ-63681/8.5.x
> remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/8.5.x
> remotes/origin/BZ-63835/9.0.x remotes/origin/HEAD -> origin/master
> remotes/origin/master
>
> - From my tomcat-9.0.x directory:
>
> $ git branch -a * 9.0.x master remotes/origin/9.0.x
>
> - From my tomcat-8.5.x directory:
>
> $ git branch -a * 8.5.x remotes/origin/7.0.x remotes/origin/8.5.x
> remotes/origin/9.0.x remotes/origin/BZ-63681/8.5.x
> remotes/origin/BZ-63681/9.0.x remotes/origin/BZ-63835/9.0.x
> remotes/origin/HEAD -> origin/master remotes/origin/master
>
> My 9.0.x checkout seems "light".
>
>
>> Have you tried a `git fetch origin master` from your 9.0 dir?
>> That'll update the gitdb with new objects and refs from master,
>> which should include the one you're trying to pick. That's the
>> only thing I can think of given that you know your object ID is
>> correct and present in master on upstream :)

That got 'er goin'!

It definitely fetched a bunch of stuff, but no new files, etc.
(because becasue I was "up-to-date"). How can I be "up-to-date"
without being "up-to-date"? :(

Maybe now I can go back and merge the original commits from this
thread from February.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6oRIAACgkQHPApP6U8
pFhtsA/9HHIvXZSbOsJuiBSkc0mBLonbtnvu5SOGizvcHZwPymfQgv+SC4yxiam+
oAXEcBOfXnFG+bdBeD80F16xQOXDOT1ndSwMASA2LzdG2iDqSVVD2DvoqX3Sna3N
+5Rp40GpIpctVLaz6rp/xTey9pZhFGy+qAjV6lssykU2Dm0trh8JNsWW4qd5Dd14
RjLSVPN3fmxJ71hXJ3s5X8AufJmxi/TnMfC5h883WpyCM6Wsd1S7E4joXLPXt3LT
qt82OBCpG23TIAM3CWeBykuKtbpnQ7eSmvMUPiBf8mG/6YoiBoGwuswsZPpDnLj6
6j4ni9IjSbPbbt7n5DBFa+QDZ6huIWH5iKcrX27ytQxVDHgDK5J9evHaTK9DbdqW
xdFdpJ5q2swC+EhZmzz524jQWWcXsUIR0kABtT8MRlW33/5Q23m9ImBu9u58Ep+m
vGmg8wCezCXAybCYQ86yjVICIINCd4GErrqh5KPbzMfOmTrvi0CTiqiJl9bsLdXr
MpgbLlKzuaOswFVeI/KbfkKquWZedQVB9Ult2fDNtpRPuqxpjeyJAgu4gTtuwXy4
+Mr+YFO9zaS49wxBo92L7ZqVn2tYPiMdzxj+39xMKwt5lj+76gq9Iyn7leKxrEZM
skqHJql7EgIwZ+xTVPlAdtERvbq6FkBHAnJxqAYDydkTVSC7CKY=
=9c6q
-END PGP SIGNATURE-

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



Eclipse error despite attempted suppression

2020-04-28 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm running Eclipse 2020-03 (4.15.0) on MacOS and I'm getting a build
failure in
org.apache.catalina.mbeans.JmxRemoteLifecycleListener.JmxRegistry
because of the use of sun.rmi.registry.RegistryImpl.

There is an attempt to suppress this for the class:

@SuppressWarnings("restriction")
private static class JmxRegistry extends
sun.rmi.registry.RegistryImpl {


Is the problem that I have my workspace configured to make uses
internal-API into *errors* (instead of *warnings*, and you cannot
suppress an error (only a warning)?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6oPRwACgkQHPApP6U8
pFgDqhAAgUfihymgPxKG5giYFx/LtSycWYA9PBEOSSYvABWHKcgiHL1+zTZyH+7s
Z8pTB8zY6xdv3EaB7CWTaLJ1FTWMhUhP/YuuzC3RFajFZ8rd+KU5FkHTPr0uJYwc
0jpxOVGpzLRKrkq4n6NXS7E791SwXjwSPLO1E/TsFqQuxRFdJMLEmmNM7e8vj3PO
7o5vNd9iZQI7B/ocwArV+A+UZLHtRlUjWS4h4civyNv3xoIzcfgQOGGTcd7uBJno
t9x/tapx1oPhBKFzE/cRL48WMgMVOF/0/8NfsONLbqKnfGyc+6F5jN94YGLlnd2s
idYZIEMzbxAEYtpZ4Hb1bfTfCcXIrg2t+8MzCyyYLtsnnJnTzJfXACj6y+rLPYyc
7yNPep/ccx2Hllyt1zRIobpj4jajeEyQoly1YyuxLZVt8BXEj8ZF5OXNZja5g1tM
sKfRRY1oa2LXR1ZuznRoohmuVREWbhLsZavrBCgoUkwr0ScfMDw/CFtYVAgbI2Si
CpjthriMjBSBjC+ETR3dZoYak/Yb63XSAtmAk9yXmeA3lIJnL8QQkceyFrUF7lUk
SxAFlsGLiRDm9QkOk9NOyTyCe4c9W7JDvoQgYMAXv6aIl4yGcorGOMSfwXaROGgx
o+9bQ2Mwf1nhPHMcjl8vip0xj+Z/j4e+OBYFVgR2zYAoITcfSHM=
=AiMn
-END PGP SIGNATURE-

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



CTR: requesting review of org.apache.catalina.startup.TestMultipartConfig

2020-04-28 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'd like a review of the test-case I wrote for the multipart config stuf
f.

It *works*, but perhaps there are better ways to do the things that I di
d.

Someone who is more familiar with all the various ways of testing
Tomcat would probably be able to replace some of my hacks with
something a little more straightforward.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6oPA0ACgkQHPApP6U8
pFiFNg//fmJvxwcsm0YSiabo2lS3p/MTC80lW7ejvQhOUOdtYM6Nc/C8lSmbUK6x
BmSD1e7oXaH/GxQkFznGGi+n5FsSZd3hleRlQwxB6GKcQlAW5/IyCFnfFMPtXJH+
s5usaj/f52GIJb6ckf/RSMhL+QxC2jgMVSKuUlP7bi31NMxso6v8Q0p8V2FlCl8V
EPaLtH/vELBGHVa9Bc8KwlHqszhQpAs8mo/rejlm13fFitUEWdi4CR9Awo+0We0a
9l0WwyhGQH+NVAK5NZOTO4X6HtfrH9Bf77XcMiGBEB+3KUl5e35yulv4XmQHYKWX
miotPoC8K8yeuUuwZk3WanOLXOIQcutGLFiaomcQoVWKCybqbgwC3xfY72Uvcvkr
c01BOqwWs1QrgVVMLQi2UHNUWw3lM/0+IcPmiiYyAUA4AkeBZHUEGkP4L6dIU8XF
u1lcjgZe+yb0j+rEPzIq+kHnB0A/4M/a/VECIC3vtZV01gbgOnNwmwsuFplkdTcH
s2LJTy7VMyFEnyx8eAYbAjTvvVSuMieDMlsBqDauoLQkOqhr4cJ7ilT8LAA4c+BR
cvZKpqY6d8COky8hNjgj+ah8EqN3+nhcgHKHlJbcT0Thpe+8AnMHd21gRNBzetxs
dQ0/j0AHAOfcgptpUGL1NslgPR7f4jrRvQxKIlHXgKc56H6+p0w=
=7WVl
-END PGP SIGNATURE-

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



Re: git-fu is (still) weak

2020-04-28 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 4/27/20 18:41, Rémy Maucherat wrote:
> On Tue, Apr 28, 2020 at 12:21 AM Christopher Schultz
>  <mailto:ch...@christopherschultz.net>>
wrote:
>
> All,
>
> I tried again to commit to tc10 branch, got commit id
> 8dddc11512fbd3b91ed9d737a42e4b8415458ddf.
>
> Moving to tc9 branch:
>
> $ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf
> fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf
>
> - From tc10:
>
> $ git remote -v origin  https://github.com/apache/tomcat (fetch)
> origin  https://github.com/apache/tomcat (push)
>
> - From tc9.0.x:
>
> $ git remote -v origin  https://github.com/apache/tomcat (fetch)
> origin  https://github.com/apache/tomcat (push)
>
> My 9.0.x local is all up-to-date with github, and github can see
> the commit in tc10.
>
> Other than manually handing the diffs myself, I have no idea what
> to do, next. :(
>
>
>> I tried and it looked "ok" to me.

Okay, what did you do? When I try to cherry-pick from 10 -> 9 I still
get the "bad object" error.

When cherry-picking your commits from 9.0.x -> 8.5.x, I get a
merge-conflict (of course) because you have already merged them.

Did I do something weird with the first commit?

Maybe I don't have my branches in order?

- From my tomcat-trunk (10) directory:

$ git branch -a
  9.0.x
* master
  remotes/origin/7.0.x
  remotes/origin/8.5.x
  remotes/origin/9.0.x
  remotes/origin/BZ-63636/tomcat-8.5.x
  remotes/origin/BZ-63636/tomcat-9.0.x
  remotes/origin/BZ-63681/8.5.x
  remotes/origin/BZ-63681/9.0.x
  remotes/origin/BZ-63835/8.5.x
  remotes/origin/BZ-63835/9.0.x
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

- From my tomcat-9.0.x directory:

$ git branch -a
* 9.0.x
  master
  remotes/origin/9.0.x

- From my tomcat-8.5.x directory:

$ git branch -a
* 8.5.x
  remotes/origin/7.0.x
  remotes/origin/8.5.x
  remotes/origin/9.0.x
  remotes/origin/BZ-63681/8.5.x
  remotes/origin/BZ-63681/9.0.x
  remotes/origin/BZ-63835/9.0.x
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

My 9.0.x checkout seems "light".

Thanks,
- -chris

> On 2/24/20 11:33, Christopher Schultz wrote:
>> All,
>
>> I'm trying to cherry-pick a commit. The commit went through
>> github, merged a PR from a contributor into master. I'm trying
>> to cherry-pick it back into the 9.0.x branch:
>
>> $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f
>> error: commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge
>> but no -m option was given. fatal: cherry-pick failed
>
>> ??
>
>> My local copy is all up-to-date, no weird local changes or
>> anything like that. What is a "merge", here? Supplying "-m"
>> doesn't like the commit id.
>
>> Any ideas?
>
>> -chris
>
>
>
- -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> <mailto:dev-unsubscr...@tomcat.apache.org> For additional commands,
> e-mail: dev-h...@tomcat.apache.org
> <mailto:dev-h...@tomcat.apache.org>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6oO7kACgkQHPApP6U8
pFgZTg//WzVb7BJyj9EKcwMm/k+tlNyZqGCH8uTMhntjFkUb9aHHLT/9PhMdBizS
bu4dIB8MtqwxSFv+jrMypccHyRGSx8OFI8Ti0BIC42whhz8AW8BLJ2JSWZrGv+lL
cHPxoosd/dFA4Ft4Acj8GG2WFeG9IUrf+vBbYC2y3jp8oRIvWFSFZQzG0Slt9Rv4
J4NUIZHkuGGQP88cey1UOw/09T/4wtTm0mFcmyjnVrXDHjrXG3CkMiwU3fo/FOyj
GmpYDEZXgVgDtUgLMG3kSynqJ4XUbRCEJJQ2nEpphFRA+qa9julCRU/D+NdLw9Ya
7MOWDWFiE7oRsUyU0qgK/GhMw0mQpmXrJuAQLyM2LaaUJ1ZZ5mr/Xqw1cuWJOYCW
TZqNXhyki8XKJSxkNlBSIMouafeX3prX8A2m8erPy83RJx5d7/T1uZNHO86Vd7Qh
ijFbAdyuICcZUPjgF/TK3AHQCVZpqQZHd/oyEVpWwdM7okhVVjoMI+WXft16oQO/
B468o8llMLE7vTAxzB9dCSOw9wpqoaPTtkd9fH20xPGWTWii0Hkk4WrWDwoUtWbO
xdFgCLQAd2fgVnwuSpOD5c2GeJoKD/Fc4D/JkJo5+bWVKJ7es2kCnT3xBVbDQj0T
Tx2HJ+B0OmCKP5df6f7SYDVxtVJ15J+BgXK5msJpIZumkassfN0=
=bp2k
-END PGP SIGNATURE-

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



Re: git-fu is (still) weak

2020-04-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I tried again to commit to tc10 branch, got commit id
8dddc11512fbd3b91ed9d737a42e4b8415458ddf.

Moving to tc9 branch:

$ git cherry-pick -n 8dddc11512fbd3b91ed9d737a42e4b8415458ddf
fatal: bad object 8dddc11512fbd3b91ed9d737a42e4b8415458ddf

- From tc10:

$ git remote -v
origin  https://github.com/apache/tomcat (fetch)
origin  https://github.com/apache/tomcat (push)

- From tc9.0.x:

$ git remote -v
origin  https://github.com/apache/tomcat (fetch)
origin  https://github.com/apache/tomcat (push)

My 9.0.x local is all up-to-date with github, and github can see the
commit in tc10.

Other than manually handing the diffs myself, I have no idea what to
do, next. :(

- -chris

On 2/24/20 11:33, Christopher Schultz wrote:
> All,
>
> I'm trying to cherry-pick a commit. The commit went through
> github, merged a PR from a contributor into master. I'm trying to
> cherry-pick it back into the 9.0.x branch:
>
> $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f error:
> commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge but no
> -m option was given. fatal: cherry-pick failed
>
> ??
>
> My local copy is all up-to-date, no weird local changes or
> anything like that. What is a "merge", here? Supplying "-m" doesn't
> like the commit id.
>
> Any ideas?
>
> -chris
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6nWssACgkQHPApP6U8
pFgE0RAAkCCN0ai+byJh3TGyQRWGP1WTUc92UO7kbVCFiJTe/1s6XtUOwPguiJ87
rbIAZRsKDefVJVZguad6mXQEkQEnAXQF3w5TvLt8abGbOKi1z4UG+ONwHdptwQfZ
83vIexa4mV2yw45mpTPqYIZ16eke41x+YV1cZea0iEqp7eQ12HN71je7E0HzEGFN
lDCf+sBHGjBeJ63LSsZ/hIU+LoWgmGBmc0j9GK1UlsL0LhpH6Cz/dXoyqsCxIXl4
3BIP5FmSK+3d+f5ciVUrAQJCH6SF0yYEx4+JtUVIUl1lJN5OwvZsyhnHHX4OqiHg
Qp0Zx7h8+mj83MAwZDDyyNcABoF4hyrEMoS9w/I2+zCNrs7RGZGKqvZRIwR2IhCR
rdhfTisc9nkmwZhg+Yt485l0m/IOO/XNqijZ8O4oxUz14BmDHrUoIYlnT3BEKe4q
7roZpz78JmcCDlFDkEcvaZKJ68vww0CFZsoWXTGDCZuckJQaAOz6Jf9470g2Y79/
WHtxmBtLNimexrbLN4COYsVoPQbk1X1xGhi2fYqyMNjVGV2cqdOo2I+VAurfRhnh
wpoLzN2mNh0qi23pdyrRsSyRB/KdAszVa2fjIR7WD74AamNy/CzMrydx0b2OpB8k
UbQ/uRuFR7q7jm5N2d0fELMWRPV03RcQ9iIFxtvPE0kGLLvyjm4=
=LDJJ
-END PGP SIGNATURE-

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



[tomcat] branch master updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=64384

2020-04-27 Thread schultz
This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/master by this push:
 new 8dddc11  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=64384
8dddc11 is described below

commit 8dddc11512fbd3b91ed9d737a42e4b8415458ddf
Author: Christopher Schultz 
AuthorDate: Mon Apr 27 18:01:00 2020 -0400

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

Respect partial multipart-config elements.
---
 .../org/apache/catalina/startup/ContextConfig.java |  30 ++--
 .../catalina/startup/TestMultipartConfig.java  | 171 +
 2 files changed, 189 insertions(+), 12 deletions(-)

diff --git a/java/org/apache/catalina/startup/ContextConfig.java 
b/java/org/apache/catalina/startup/ContextConfig.java
index 2f3ebd0..18517e2 100644
--- a/java/org/apache/catalina/startup/ContextConfig.java
+++ b/java/org/apache/catalina/startup/ContextConfig.java
@@ -1362,19 +1362,25 @@ public class ContextConfig implements LifecycleListener 
{
 wrapper.setServletClass(servlet.getServletClass());
 MultipartDef multipartdef = servlet.getMultipartDef();
 if (multipartdef != null) {
-if (multipartdef.getMaxFileSize() != null &&
-multipartdef.getMaxRequestSize()!= null &&
-multipartdef.getFileSizeThreshold() != null) {
-wrapper.setMultipartConfigElement(new 
MultipartConfigElement(
-multipartdef.getLocation(),
-Long.parseLong(multipartdef.getMaxFileSize()),
-Long.parseLong(multipartdef.getMaxRequestSize()),
-Integer.parseInt(
-multipartdef.getFileSizeThreshold(;
-} else {
-wrapper.setMultipartConfigElement(new 
MultipartConfigElement(
-multipartdef.getLocation()));
+long maxFileSize = -1;
+long maxRequestSize = -1;
+int fileSizeThreshold = 0;
+
+if(null != multipartdef.getMaxFileSize()) {
+maxFileSize = 
Long.parseLong(multipartdef.getMaxFileSize());
+}
+if(null != multipartdef.getMaxRequestSize()) {
+maxRequestSize = 
Long.parseLong(multipartdef.getMaxRequestSize());
 }
+if(null != multipartdef.getFileSizeThreshold()) {
+fileSizeThreshold = 
Integer.parseInt(multipartdef.getFileSizeThreshold());
+}
+
+wrapper.setMultipartConfigElement(new MultipartConfigElement(
+multipartdef.getLocation(),
+maxFileSize,
+maxRequestSize,
+fileSizeThreshold));
 }
 if (servlet.getAsyncSupported() != null) {
 wrapper.setAsyncSupported(
diff --git a/test/org/apache/catalina/startup/TestMultipartConfig.java 
b/test/org/apache/catalina/startup/TestMultipartConfig.java
new file mode 100644
index 000..d0ca905
--- /dev/null
+++ b/test/org/apache/catalina/startup/TestMultipartConfig.java
@@ -0,0 +1,171 @@
+package org.apache.catalina.startup;
+
+import java.lang.reflect.Method;
+
+import jakarta.servlet.MultipartConfigElement;
+
+import org.apache.catalina.Container;
+import org.apache.catalina.Context;
+import org.apache.catalina.LifecycleState;
+import org.apache.catalina.connector.Connector;
+import org.apache.catalina.core.StandardContext;
+import org.apache.catalina.core.StandardEngine;
+import org.apache.catalina.core.StandardHost;
+import org.apache.catalina.core.StandardService;
+import org.apache.catalina.core.StandardWrapper;
+import org.apache.tomcat.util.descriptor.web.MultipartDef;
+import org.apache.tomcat.util.descriptor.web.ServletDef;
+import org.apache.tomcat.util.descriptor.web.WebXml;
+import org.junit.Assert;
+import org.junit.Test;
+
+public class TestMultipartConfig {
+@Test
+public void testNoMultipartConfig() throws Exception {
+StandardWrapper servlet =  config(null);
+
+MultipartConfigElement mce = servlet.getMultipartConfigElement();
+
+Assert.assertNull(mce);
+}
+
+@Test
+public void testDefaultMultipartConfig() throws Exception {
+MultipartDef multipartDef = new MultipartDef();
+// Do not set any attributes on multipartDef: expect defaults
+
+StandardWrapper servlet =  config(multipartDef);
+MultipartConfigElement mce = servlet.getMultipartConfigElement();
+
+Assert.assertNotNull(mce);
+Assert.assertEquals("", mce.getLocation());
+Assert.assertEquals(-1, mce.getMaxFileSize());
+Assert.assertEquals

Re: Position on failing tests with vendor-modified OpenSSL packages

2020-04-24 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark and Michael,

On 4/24/20 07:24, Michael Osipov wrote:
> Am 2020-04-24 um 08:57 schrieb Mark Thomas:
>> On 24/04/2020 00:45, Michael Osipov wrote:
>>> Folks,
>>>
>>> I run test from Tomcat master and libtcnative master on
>>> FreeBSD, RHEL 7 and HP-UX 11.31 on a regular basis and noticed
>>> that the OpenSSL 1.0.2 packages provided by Red Hat and HPE are
>>> modified which make several tests fail. See an excerpt here
>>> [1]. To verify this I have compiled OpenSSL from
>>> OpenSSL_1_0_2-stable on FreeBSD w/o any modification and all
>>> tests pass, so other must have modified OpenSSL.
>>>
>>> What is our position in terms of support/testing for modified
>>> OpenSSL packages from OS vendors? Should we add a big fat
>>> warning somewhere? Add this to tcnative README that we
>>> test/recommend upstream only?
>>
>> The good news is that the tests that are failing are the ones I
>> would expect to fail.
>>
>> When we added the code that lets us use OpenSSL syntax to define
>> ciphers for JSSE (and JSSE syntax to define ciphers for OpenSSL)
>> we added a these tests to ensure that we correctly tracked things
>> like "ALL", "DEFAULT" as well as "ECDHE" etc. These are a moving
>> target as support for new ciphers is added and ciphers viewed as
>> less secure are removed.
>>
>> Our unit tests aim to work with the current version of all
>> publicly supported OpenSSL branches. Currently, master (3.0.x)
>> and 1.1.1.
>>
>> I expect the vendor supported 1.0.2 packages are close to current
>> 1.1.1 but I wouldn't be surprised to see some minor differences.
>>
>> I think we have several options: - document the expectation more
>> clearly so folks can more easily assess these failures - support
>> using the vendor supported versions with the unit tests - provide
>> a configuration option to skip these tests - detect vendor
>> supplied OpenSSL and automatically skip the tests
>
> We need to do at least the documentation. As for detectection and
> support: I consider this to be hardly solvable because there is no
> identifier in "openssl version -a" which says I have been modified
> by X. See:
>
>> $ openssl version -a OpenSSL 1.0.2r  26 Feb 2019 built on:
>> reproducible build, date unspecified platform: hpux-ia64-cc
>> options:  bn(64,64) rc4(idx,int) des(idx,risc1,16,long)
>> blowfish(idx) compiler: cc -I. -I.. -I../include
>> -I/ssh_ssl_build/ssl-build/OpenSSL_1_0_FIPS_205/build/zlib +Z
>> -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS  -DDSO_DLFCN
>> -DHAVE_DLFCN_H -D_REENTRANT -Ae +DD32 +O2 +Olit=all -z -DB_ENDIAN
>> -D_REENTRANT -DOPENSSL_BN_ASM_MONT -DRC4_ASM -DSHA1_ASM
>> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM
>> OPENSSLDIR: "/opt/openssl"
>
> and
>
>> $ openssl version -a OpenSSL 1.0.2k-fips  26 Jan 2017 built on:
>> reproducible build, date unspecified platform: linux-x86_64
>> options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int)
>> idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include
>> -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2
>> -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>> -fstack-protector-strong --param=ssp-buffer-size=4
>> -grecord-gcc-switches   -m64 -mtune=generic -Wa,--noexecstack
>> -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
>> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM
>> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
>> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
>> OPENSSLDIR: "/etc/pki/tls" engines:  rdrand dynamic
>
> The only option I see is to check for OS name/LSB release, call
> with depdency graph with ldd and check for libssl/libcrypto in
> default locations, but this is really really ugly.
>
> Compared to OpenSSL 1.1.1 from FreeBSD base and OpenSSL 1.0.2
> compiled myself:
>> $ openssl version -a OpenSSL 1.1.1e-freebsd  17 Mar 2020 built
>> on: reproducible build, date unspecified platform: FreeBSD-amd64
>> options:  bn(64,64) rc4(16x,int) des(int) idea(int)
>> blowfish(ptr) compiler: clang OPENSSLDIR: "/etc/ssl" ENGINESDIR:
>> "/usr/lib/engines" Seeding source: os-specific
>
> Granted, this one says in the version string it is from FreeBSD.
>
>> $ /tmp/openssl-1.0.2/bin/openssl version -a OpenSSL 1.0.2v-dev
>> xx XXX  built on: reproducible build, date unspecified
>> platform: BSD-x86_64 options:  bn(64,64) rc4(16x,int)
>> des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: cc -I.
>> -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread
>> -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN
>> -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
>> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM
>> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
>> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
>> OPENSSLDIR: "/tmp/openssl-1.0.2/ssl"
>
>> There are probably a few options I've missed.
>>
>> I 

Re: [tomcat-native] branch master updated: Introduce tcn_get_thread_id(void) to reduce code duplication

2020-04-24 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 4/23/20 18:42, micha...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git
> repository.
>
> michaelo pushed a commit to branch master in repository
> https://gitbox.apache.org/repos/asf/tomcat-native.git
>
>
> The following commit(s) were added to refs/heads/master by this
> push: new f95f531  Introduce tcn_get_thread_id(void) to reduce code
> duplication f95f531 is described below
>
> commit f95f531e98278cc7555367084b967e3550734559 Author: Michael
> Osipov  AuthorDate: Thu Apr 23 18:52:44 2020
> +0200
>
> Introduce tcn_get_thread_id(void) to reduce code duplication
>
> At two spots (ssl.c and thread.c) we need to obtain the native
> thread id. This has been done with two different approaches. Move
> out to tcn_get_thread(void) which uses the previous
> ssl_thread_id(void) implementation while the previous functions
> delegate to the new one. apr_os_thread_current(void) is not used
> anymore which does internally the same thing as
> ssl_thread_id(void) was doing.
>
> Also add properly #ifdefs for Windows and macOS for function
> prototype includes. --- native/include/tcn.h  |  1 +
> native/src/jnilib.c   | 45
> +++ native/src/ssl.c
> | 33 +--- native/src/thread.c
> |  3 ++- xdocs/miscellaneous/changelog.xml |  5 - 5 files
> changed, 53 insertions(+), 34 deletions(-)
>
> diff --git a/native/include/tcn.h b/native/include/tcn.h index
> 2b2ae59..d2f316b 100644 --- a/native/include/tcn.h +++
> b/native/include/tcn.h @@ -175,6 +175,7 @@ char
> *tcn_strdup(JNIEnv *, jstring); char   *tcn_pstrdup(JNIEnv
> *, jstring, apr_pool_t *); apr_status_t
> tcn_load_finfo_class(JNIEnv *, jclass); apr_status_t
> tcn_load_ainfo_class(JNIEnv *, jclass); +unsigned long
> tcn_get_thread_id(void);
>
> #define J2S(V)  c##V #define J2L(V)  p##V diff --git
> a/native/src/jnilib.c b/native/src/jnilib.c index dae3ade..e88d4d5
> 100644 --- a/native/src/jnilib.c +++ b/native/src/jnilib.c @@ -23,6
> +23,22 @@
>
> #include "tcn_version.h"
>
> +#ifdef WIN32 +#include  +#endif + +#ifdef DARWIN
> +#include  +#endif + +#ifdef __FreeBSD__ +#include
>  +#endif + +#ifdef __linux__ +#include
>  +#endif + #ifdef TCN_DO_STATISTICS extern void
> sp_poll_dump_statistics(); extern void
> sp_network_dump_statistics(); @@ -481,3 +497,32 @@ jint
> tcn_get_java_env(JNIEnv **env) } return JNI_OK; } + +unsigned long
> tcn_get_thread_id(void)

Why not simple call apr_os_thread_current() instead of writing a new
function? Or is the intention to get away from using APR?

> +{ +/* OpenSSL needs this to return an unsigned long.  On
> OS/390, the pthread + * id is a structure twice that big.  Use
> the TCB pointer instead as a + * unique unsigned long. +
> */ +#ifdef __MVS__ +struct PSA { +char unmapped[540]; +
> unsigned long PSATOLD; +} *psaptr = 0; + +return
> psaptr->PSATOLD;

I think we might want to put the above #ifdef as the LAST one in the
list. I think if we can call pthread_self, we should, even if this
other technique will work.

> +#elif defined(WIN32) +return (unsigned
> long)GetCurrentThreadId(); +#elif defined(DARWIN) +uint64_t
> tid; +pthread_threadid_np(NULL, ); +return (unsigned
> long)tid; +#elif defined(__FreeBSD__) +return (unsigned
> long)pthread_getthreadid_np(); +#elif defined(__linux__) +
> return (unsigned long)syscall(SYS_gettid); +#else +return
> (unsigned long)pthread_self(); +#endif

Can we guarantee that pthread_self() will be available "by default"
since it's predicate-less, here? I wasn't able to quickly find a
reference for how to check for pthreads. Maybe #ifdef(_PTHREAD_H)?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6jEmQACgkQHPApP6U8
pFjvjw/+NcylTnzG4+0N3NulBBv/2dhZPKJJjeH5vkw519CDXUikcy6ObTKZ58XZ
6PFnG6t7KCWAU87IODWV+qPR1sg4sUyhqWi2eC1djN97KpZFkE0lMhyV+gKelMFM
wOmRHB6tow1hI6hHkmssX5udGsPWZvKjJYBCiNCaKto7VwQS8tiSy3S8za2RMFnz
UJNmi5iirMNRncuIzUhrpK0n49xNWqSLBYjnk9d1jcVKwSydA0oVz3SgKumscnH+
Exakdk/XvDtwTXQLKaIA9S0OvRbj44bCkiuM4Yrc8s0uF3H3tcRAmpv5ADX4IRjn
dU0imx8jEZK/SOHP95TeejNcjAocWUPMvQZ0LTTVhn4Ld4qA+TtD8h0IODMdkt4E
E+fb1HfYySlRAgASUNEBUKl57t3uRTyQcC2fmjjvWvc4ZqY8QKFVdnFNWIiSylE+
3xA1ORoNNU35F4RMnqZFSLkkRvulNew8hl/YBNyxPcANhWBe8BTK5amfdGqsdOed
KTwpp6o58FzCKs6GSowkWSRClaqqITmtE8kQOo0+ecqKZclW6OLqExTNcS4a9At3
uaYpT2Tt89Ul9WZ4XdE6X1d1hFN4Mg8vsCaO86rTvOlnJaLs9CKsKX4uRuOmgMGY
h9qlkKIM1PRPuzGLLkxs+jWnyPRQX2jTO1N5wcUPjqsbEdoH074=
=LLLb
-END PGP SIGNATURE-

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



  1   2   3   4   5   6   7   8   9   10   >