[CONF] Apache Tomcat > Servlet TCK 5.0

2020-06-19 Thread Mark Thomas (Confluence)
Title: Message Title



 
 
 
There's 1 new edit on this page 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Servlet TCK 5.0 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
Mark Thomas edited this page 
 
 
  
 
 

 
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Here's what changed: 
 
 
 
 
 
 
 
 
 
 
 ...  Enable TLS on port 8443                truststoreFile="conf/cacerts.jks">                 certificateKeystorePassword                     certificateKeystorePassword="changeit"   type                     type="RSA" />                  Note: Set protocols="TLSv1.2" to disable TLSv1.3 since the TCK requires post-handshake authentication and the Java 11 client does not support that.  tomcat-users.xml Make the following changes: ... A default 10.0.x build (as of 2020-06-1819) with the above configuration and the TCK built from source (as of 2020-06-1819) triggers 23 21 test failures 1 Expected failures ... 
 
 PR 338 
 
Incorrect major version (1 failure), 
Using LF rather an CRLF (15 failures) 
Strange /j_security_check test (2 failures)Error page attributes assumed to be unset when spec requires them to be set (3 failures) 
Missing annotation marker in Java 8 signature tests (1 failure) 
Re-do Java 11 signature test based on Java 8 
 Fix regression in error page tests (1 failure)  
 Java 11 issues with HTTP/2 client  
  
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Go to page history 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
View page 
 
 
  
 
 
  
 
 
  
 
 
  
 
 
 
 
 
 
 
 
 
 
Stop watching space
• 
 
 
 
 
 
 
Manage notifications 
 
 
 
 
 
 
 
 
 
 
  
 
 
This message was sent by Atlassian Confluence 7.5.0  
 
 
  
 
 
 
 
 
 
 
 
 




[Bug 64541] Parsing of mbeans-descriptor.xml files throw errors on server startup

2020-06-19 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64541

--- Comment #1 from Christopher Schultz  ---
Interesting.

How are you setting the limit for the JAXP entity expansion... via the system
property "jdk.xml.entityExpansionLimit"?

What's the security justification for the setting of "1" and not, say, 3 or 5
or 63999?

Do you happen to know if the system property will override explicitly-setting
the JAXP feature
"http://www.oracle.com/xml/jaxp/properties/entityExpansionLimit;? I don't have
a test-case handy and if you happen to know the answer it might get us to a
solution more quickly.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 64541] New: Parsing of mbeans-descriptor.xml files throw errors on server startup

2020-06-19 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64541

Bug ID: 64541
   Summary: Parsing of mbeans-descriptor.xml files throw errors on
server startup
   Product: Tomcat 7
   Version: 7.0.104
  Hardware: PC
OS: Linux
Status: NEW
  Severity: regression
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: vdimit...@axway.com
  Target Milestone: ---

Created attachment 37319
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=37319=edit
The tomcat startup server log

I'm using tomcat version 7.0.104 on a linux system. 
The JVM used is Adopt's OpenJDK 11. 

When starting the server, the logs are full of errors regarding all the
mbeans-descriptor.xml files in the catalina.jar and jasper.jar archives. The
errors are regarding the entity expansion limit for jaxp, which in our case is
1 (for security reasons). This error is a regression from version 7.0.104(since
we don't have this problem with 7.0.103) and is probably caused from adding of
this verification against mbeans-descriptor.dtd:
https://github.com/apache/tomcat/commit/1f1877c3d888f519f0544386cebc3c3f0ca16786
.
I'm attaching a part of the tomcat logs, which contains the stacktrace of the
error.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
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-19 Thread Emmanuel Bourg
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



[Bug 64540] switch from bndwrap task to bnd task

2020-06-19 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64540

--- Comment #1 from rotty3000  ---
While making this change we also have to do an initial pass over the metadata
to make sure it's all still minimally correct.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
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 Mark Thomas
On 19/06/2020 14:38, Christopher Schultz wrote:
> 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?

Looks good.

I'm just wondering how far we need to go in making this generic /
customisable.

Mark

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



Re: New home for EncryptInterceptor.BaseEncryptionManager and friends

2020-06-19 Thread Mark Thomas
On 19/06/2020 15:02, Christopher Schultz wrote:
> 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.

Packages under org.apache.catalina are only visible to other packages
under org.apache.catalina.

Packages under org.apache.tomcat.util are visible to most/all Tomcat
packages.

So, it depends which code is going to be using it or if you think other
components might need it over time.

It is actually a little tricker than that. I usually recommend looking
at the POM files to see what the dependencies are meant to be.

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

Tribes is a special case. It currently only depends on JULI. It has
copies of several utility classes to keep that dependency to a minimum.

Those two classes are so small, I'd be tempted to go with the copying
option.

Mark

-
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/N1ysKKWtwFPhPXVCy2dAqD5Bst/e9B8Kb5JZ8DFC
6ImoD05rlQRDRlxYzDD3oUxxLoEshM6O5PqiWWAZbosqYJENE+3cNL2VlBFTTByQ
rGQb4Bsw+t58u6hoJ9RV1sDazRN/ZC0FHLXlYxxcMxgARlE3NkDOSpvPtrqMY0xc

[Bug 64540] New: switch from bndwrap task to bnd task

2020-06-19 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=64540

Bug ID: 64540
   Summary: switch from bndwrap task to bnd task
   Product: Tomcat 10
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Packaging
  Assignee: dev@tomcat.apache.org
  Reporter: raymond.a...@liferay.com
  Target Milestone: --

Bnd task is more targeted and offers more control w.r.t. building OSGi
metadata. We also need it later to leverage access to classpath references for
producing more accurate metadata.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[GitHub] [tomcat] rotty3000 commented on pull request #303: Fix BZ 64532 - update to bnd 5.1.1

2020-06-19 Thread GitBox


rotty3000 commented on pull request #303:
URL: https://github.com/apache/tomcat/pull/303#issuecomment-646637527


   @markt-asf did I miss any other changes you wanted to see?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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