Re: MappedByteBuffer, Windows and locked files

2022-06-21 Thread Rémy Maucherat
On Tue, Jun 21, 2022 at 8:47 PM Mark Thomas  wrote:
>
> On 21/06/2022 13:25, Rémy Maucherat wrote:
> > kOn Tue, Jun 21, 2022 at 12:41 PM Mark Thomas  wrote:
> >>
> >> On 21/06/2022 08:53, Rémy Maucherat wrote:
> >>> On Tue, Jun 21, 2022 at 9:13 AM Mark Thomas  wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> See [1] for further background.
> >>>>
> >>>> The current sendfile implementation for async HTTP/2 uses a
> >>>> MappedByteBuffer as the source.
> >>>>
> >>>> Unfortunately, MappedByteBuffer has some problematic side effects on
> >>>> Windows. The underlying file is locked until the MappedByteBuffer is
> >>>> GC'd. This causes problems with some usage patterns such as:
> >>>>
> >>>> - GET file to review it
> >>>> - file delivered by sendfile
> >>>> - DELETE file as it is unwanted
> >>>> - delete fails because file is locked
> >>>>
> >>>> We have multiple options to address this. These include:
> >>>>
> >>>> 1. Switch to using FileChannel like NioEndpoint
> >>>>
> >>>> 2. Switch to using FileChannel like NioEndpoint when running on Windows
> >>>>
> >>>> 3. Disable HTTP/2 sendfile when running on Windows
> >>>>
> >>>> 4. On Windows with Java 12 onwards, use jdk.internal.misc.Unsafe to
> >>>> clear the references held by the MappedByteBuffer once the file has been
> >>>> sent.
> >>>>
> >>>> 5. Disable HTTP/2 sendfile when running on Windows unless Java 12
> >>>> onwards is used in which case use jdk.internal.misc.Unsafe
> >>>>
> >>>> 6. Document the issue when running on Windows so users can disable
> >>>> sendfile if their usage pattern is going to be problematic.
> >>>
> >>> I would choose this one, also since it's only until GC occurs.
> >>> Memory mapping seems more efficient than other techniques (less
> >>> copying, also it's a direct buffer).
> >>
> >> You don't think it is worth trying to fix this if running on Java 12 or
> >> later?
> >
> > Not really. I don't understand what's the process for selecting
> > Windows when you're designing a R/W webapp. Sure it might work.
> > Sometimes.
>
> :)
>
> ACK.
>
> >> My expectation is that it should be relatively low risk since we know
> >> when the completion handler has finished and we could clear the
> >> references then.
> >
> > You say you're going to use Unsafe, in which case it could cause
> > problems eventually. Cleaning up native stuff in completion handlers
> > or cleaners works well, indeed.
>
> Fair enough. I'll put the warning in place for now. If this becomes a
> larger issue over time, we can always look again at using Unsafe.

+1, that's a good compromise.

Rémy

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



Re: MappedByteBuffer, Windows and locked files

2022-06-21 Thread Rémy Maucherat
kOn Tue, Jun 21, 2022 at 12:41 PM Mark Thomas  wrote:
>
> On 21/06/2022 08:53, Rémy Maucherat wrote:
> > On Tue, Jun 21, 2022 at 9:13 AM Mark Thomas  wrote:
> >>
> >> Hi all,
> >>
> >> See [1] for further background.
> >>
> >> The current sendfile implementation for async HTTP/2 uses a
> >> MappedByteBuffer as the source.
> >>
> >> Unfortunately, MappedByteBuffer has some problematic side effects on
> >> Windows. The underlying file is locked until the MappedByteBuffer is
> >> GC'd. This causes problems with some usage patterns such as:
> >>
> >> - GET file to review it
> >> - file delivered by sendfile
> >> - DELETE file as it is unwanted
> >> - delete fails because file is locked
> >>
> >> We have multiple options to address this. These include:
> >>
> >> 1. Switch to using FileChannel like NioEndpoint
> >>
> >> 2. Switch to using FileChannel like NioEndpoint when running on Windows
> >>
> >> 3. Disable HTTP/2 sendfile when running on Windows
> >>
> >> 4. On Windows with Java 12 onwards, use jdk.internal.misc.Unsafe to
> >> clear the references held by the MappedByteBuffer once the file has been
> >> sent.
> >>
> >> 5. Disable HTTP/2 sendfile when running on Windows unless Java 12
> >> onwards is used in which case use jdk.internal.misc.Unsafe
> >>
> >> 6. Document the issue when running on Windows so users can disable
> >> sendfile if their usage pattern is going to be problematic.
> >
> > I would choose this one, also since it's only until GC occurs.
> > Memory mapping seems more efficient than other techniques (less
> > copying, also it's a direct buffer).
>
> You don't think it is worth trying to fix this if running on Java 12 or
> later?

Not really. I don't understand what's the process for selecting
Windows when you're designing a R/W webapp. Sure it might work.
Sometimes.

> My expectation is that it should be relatively low risk since we know
> when the completion handler has finished and we could clear the
> references then.

You say you're going to use Unsafe, in which case it could cause
problems eventually. Cleaning up native stuff in completion handlers
or cleaners works well, indeed.

Rémy

>
> 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: MappedByteBuffer, Windows and locked files

2022-06-21 Thread Rémy Maucherat
On Tue, Jun 21, 2022 at 9:13 AM Mark Thomas  wrote:
>
> Hi all,
>
> See [1] for further background.
>
> The current sendfile implementation for async HTTP/2 uses a
> MappedByteBuffer as the source.
>
> Unfortunately, MappedByteBuffer has some problematic side effects on
> Windows. The underlying file is locked until the MappedByteBuffer is
> GC'd. This causes problems with some usage patterns such as:
>
> - GET file to review it
> - file delivered by sendfile
> - DELETE file as it is unwanted
> - delete fails because file is locked
>
> We have multiple options to address this. These include:
>
> 1. Switch to using FileChannel like NioEndpoint
>
> 2. Switch to using FileChannel like NioEndpoint when running on Windows
>
> 3. Disable HTTP/2 sendfile when running on Windows
>
> 4. On Windows with Java 12 onwards, use jdk.internal.misc.Unsafe to
> clear the references held by the MappedByteBuffer once the file has been
> sent.
>
> 5. Disable HTTP/2 sendfile when running on Windows unless Java 12
> onwards is used in which case use jdk.internal.misc.Unsafe
>
> 6. Document the issue when running on Windows so users can disable
> sendfile if their usage pattern is going to be problematic.

I would choose this one, also since it's only until GC occurs.
Memory mapping seems more efficient than other techniques (less
copying, also it's a direct buffer).

Rémy

> 7. Something else...
>
> Thoughts?
>
> Mark
>
>
> [1]
> https://tomcat.markmail.org/thread/se75bjn2dskrfpls#query:+page:1+mid:vjrhogrpyhzobenj+state:results
>
> -
> 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



[ANN] Apache Tomcat 9.0.64 available

2022-06-09 Thread Rémy Maucherat
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.64.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.64 is a bugfix and feature release. The notable
changes compared to 9.0.63 include:

- Correct a regression in the support added for encrypted PKCS#1
   formatted private keys in the previous release that broke support
   for unencrypted PKCS#1 formatted private keys.

- Increase the default buffer size for cluster messages from 43800
   to 65536 bytes. This is expected to improve performance for large
   messages when running on Linux based systems.

- When using TLS with non-blocking writes and the NIO connector,
   ensure that flushing the buffers attempts to empty all of the
   output buffers.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



[VOTE][RESULT] Release Apache Tomcat 9.0.64

2022-06-09 Thread Rémy Maucherat
The following votes were cast:

Binding:
+1: remm, markt, jfclere

Non-Binding
+1: Han Li

No other votes were cast. The vote therefore passes.

Thanks to everyone who contributed to this release.

Rémy

On Thu, Jun 2, 2022 at 9:46 PM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.64 release is now available for voting.
>
> The notable changes compared to 9.0.63 are:
>
> - Correct a regression in the support added for encrypted PKCS#1
>formatted private keys in the previous release that broke support
>for unencrypted PKCS#1 formatted private keys.
>
> - Increase the default buffer size for cluster messages from 43800
>to 65536 bytes. This is expected to improve performance for large
>messages when running on Linux based systems.
>
> - When using TLS with non-blocking writes and the NIO connector,
>ensure that flushing the buffers attempts to empty all of the
>output buffers.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.64/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1378
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.64
> 1419d61f200be876baddb0997919fb82c230a857
>
> The proposed 9.0.64 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.64 (stable)
>
> Rémy

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

2022-06-09 Thread Rémy Maucherat
On Thu, Jun 9, 2022 at 12:03 AM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 8.5.81 release is now available for voting.
>
> The notable change compared to 8.5.80 (not released) is:
>
>   - Fix regression that broke or unexpectedly modified some TLS
> configurations when running on a Java 8 JDK.
>
> The notable changes compared to 8.5.79 are:
>
> - Ensure that changes made to a request by the RemoteIPValve persist
>after the request is put into asynchronous mode.
>
> - Correct a regression in the support added for encrypted PKCS#1
>formatted private keys in the previous release that broke support
>for unencrypted PKCS#1 formatted private keys.
>
> - Increase the default buffer size for cluster messages from 43800
>to 65536 bytes. This is expected to improve performance for large
>messages when running on Linux based systems.
>
> - When using TLS with non-blocking writes and the NIO connector,
>ensure that flushing the buffers attempts to empty all of the
>output buffers.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.81/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1380
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.81/
> 2f283f89f49be662efa45af2c6a876d897159ddf
>
> The proposed 8.5.81 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.81 (stable)

Rémy

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

2022-06-08 Thread Rémy Maucherat
On Tue, Jun 7, 2022 at 5:26 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 8.5.80 release is now available for voting.
>
> The notable changes compared to 8.5.79 are:
>
> - Ensure that changes made to a request by the RemoteIPValve persist
>after the request is put into asynchronous mode.
>
> - Correct a regression in the support added for encrypted PKCS#1
>formatted private keys in the previous release that broke support
>for unencrypted PKCS#1 formatted private keys.
>
> - Increase the default buffer size for cluster messages from 43800
>to 65536 bytes. This is expected to improve performance for large
>messages when running on Linux based systems.
>
> - When using TLS with non-blocking writes and the NIO connector,
>ensure that flushing the buffers attempts to empty all of the
>output buffers.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.80/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1379
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.78/
> f732d3aa5ca55eb07cb73d9ec2b585330f80f00b
>
> The proposed 8.5.80 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.79 (stable)

Rémy

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

2022-06-07 Thread Rémy Maucherat
On Tue, Jun 7, 2022 at 12:12 PM Mark Thomas  wrote:
>
> Version 1.2.34 includes the following changes compared to 1.2.33
>
> - Refactor the initialization of the native code so it is compatible
>with Tomcat 10.1.x where deprecated Java classes will be removed
>
> - Map the OpenSSL 3.0.x FIPS behaviour to the 1.1.1 API to allow clients
>to determine if the FIPS provider is being used when Tomcat Native is
>compiled against OpenSSL 3.0.x
>
> The proposed release artefacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 1.2.34 release is
>   [X] Stable, go ahead and release
>   [ ] Broken because of ...

Rémy

> Thanks,
>
> Mark
>
>
> [1]
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.34
> [2]
> https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=a0dd83ddac6dcd4fd315f083adaab3fd24a9f0b4
>
> -
> 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: [VOTE] Release Apache Tomcat 9.0.64

2022-06-03 Thread Rémy Maucherat
On Thu, Jun 2, 2022 at 9:46 PM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.64 release is now available for voting.
>
> The notable changes compared to 9.0.63 are:
>
> - Correct a regression in the support added for encrypted PKCS#1
>formatted private keys in the previous release that broke support
>for unencrypted PKCS#1 formatted private keys.
>
> - Increase the default buffer size for cluster messages from 43800
>to 65536 bytes. This is expected to improve performance for large
>messages when running on Linux based systems.
>
> - When using TLS with non-blocking writes and the NIO connector,
>ensure that flushing the buffers attempts to empty all of the
>output buffers.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.64/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1378
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.64
> 1419d61f200be876baddb0997919fb82c230a857
>
> The proposed 9.0.64 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.64 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.0.22

2022-06-03 Thread Rémy Maucherat
On Thu, Jun 2, 2022 at 7:11 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.0.22 release is now available for
> voting.
>
> Apache Tomcat 10.0.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to jakarta.*
>
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes. Java EE applications designed for Tomcat 9 and earlier may be
> placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will
> automatically convert them to Jakarta EE and copy them to the webapps
> directory
>
> The notable changes compared to 10.0.21 are:
>
> - Correct a regression in the support added for encrypted PKCS#1
>formatted private keys in the previous release that broke support
>for unencrypted PKCS#1 formatted private keys.
>
> - Increase the default buffer size for cluster messages from 43800
>to 65536 bytes. This is expected to improve performance for large
>messages when running on Linux based systems.
>
> - When using TLS with non-blocking writes and the NIO connector,
>ensure that flushing the buffers attempts to empty all of the
>output buffers.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.22/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1377
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.22
> babca1854c6f7068069d501e7f6b9cca13943056
>
> The proposed 10.0.22 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.0.21 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M16

2022-06-03 Thread Rémy Maucherat
On Thu, Jun 2, 2022 at 3:22 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.1.0-M16 release is now available for
> voting.
>
> I am proposing this as a beta release since the Jakarta EE APIs are now
> finalised and Tomcat's implementation of the API changes is complete.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M15 are:
>
> - Refactor synchronization blocks locking on SocketWrapper to use
>ReentrantLock to support users wishing to experiment with project
>Loom.
>
> - Correct a regression in the support added for encrypted PKCS#1
>formatted private keys in the previous release that broke support
>for unencrypted PKCS#1 formatted private keys.
>
> - Increase the default buffer size for cluster messages from 43800
>to 65536 bytes. This is expected to improve performance for large
>messages when running on Linux based systems.
>
> For full details, see the change log:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M16/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1376
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M16
> 02c4004b52be88a04a7372577d56da0f9ed3a7fe
>
>
> The proposed 10.1.0-M16 release is:
> [ ] Broken - do not release
> [X] Beta - go ahead and release as 10.1.0-M16 (beta)

Let's start the beta cycle then !

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M16

2022-06-03 Thread Rémy Maucherat
On Thu, Jun 2, 2022 at 3:22 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.1.0-M16 release is now available for
> voting.

For all previous branches, the "M" was dropped as soon as the spec was
final (and its implementation was complete too ;) ). Maybe this is
better though, all regular numbered releases would be either stable or
skipped, while the "M" would be alpha or beta.

Rémy

> I am proposing this as a beta release since the Jakarta EE APIs are now
> finalised and Tomcat's implementation of the API changes is complete.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M15 are:
>
> - Refactor synchronization blocks locking on SocketWrapper to use
>ReentrantLock to support users wishing to experiment with project
>Loom.
>
> - Correct a regression in the support added for encrypted PKCS#1
>formatted private keys in the previous release that broke support
>for unencrypted PKCS#1 formatted private keys.
>
> - Increase the default buffer size for cluster messages from 43800
>to 65536 bytes. This is expected to improve performance for large
>messages when running on Linux based systems.
>
> For full details, see the change log:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M16/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1376
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M16
> 02c4004b52be88a04a7372577d56da0f9ed3a7fe
>
>
> The proposed 10.1.0-M16 release is:
> [ ] Broken - do not release
> [ ] Beta - go ahead and release as 10.1.0-M16 (beta)
>
> -
> 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



[VOTE] Release Apache Tomcat 9.0.64

2022-06-02 Thread Rémy Maucherat
The proposed Apache Tomcat 9.0.64 release is now available for voting.

The notable changes compared to 9.0.63 are:

- Correct a regression in the support added for encrypted PKCS#1
   formatted private keys in the previous release that broke support
   for unencrypted PKCS#1 formatted private keys.

- Increase the default buffer size for cluster messages from 43800
   to 65536 bytes. This is expected to improve performance for large
   messages when running on Linux based systems.

- When using TLS with non-blocking writes and the NIO connector,
   ensure that flushing the buffers attempts to empty all of the
   output buffers.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.64/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1378
The tag is:
https://github.com/apache/tomcat/tree/9.0.64
1419d61f200be876baddb0997919fb82c230a857

The proposed 9.0.64 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.64 (stable)

Rémy

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



Re: [tomcat] branch main updated: Jakarta Servlet 6.0 specification is final

2022-06-01 Thread Rémy Maucherat
On Wed, Jun 1, 2022 at 9:04 PM Mark Thomas  wrote:
>
> On 01/06/2022 19:59, ma...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > markt pushed a commit to branch main
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> >
> > The following commit(s) were added to refs/heads/main by this push:
> >   new a704da4e05 Jakarta Servlet 6.0 specification is final
> > a704da4e05 is described below
> >
> > commit a704da4e05b057bcdb30c75cb65781a4fde821bf
> > Author: Mark Thomas 
> > AuthorDate: Wed Jun 1 19:59:48 2022 +0100
> >
> >  Jakarta Servlet 6.0 specification is final
>
> This is the last of the Jakarta specifications that Tomcat implements to
> go final.
>
> Tomcat's implementation of all these specifications is also complete.
>
> The next 10.1.x release vote will therefore be for a beta release rather
> than an alpha release.

Congratulations on the milestone :)

Rémy

> 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: [tomcat-native] 01/02: Minimum OpenSSl version is 3.0.0 is keylog callback is always available

2022-06-01 Thread Rémy Maucherat
On Tue, May 31, 2022 at 8:02 PM Mark Thomas  wrote:
>
> On 31/05/2022 17:59, Rémy Maucherat wrote:
> > On Tue, May 31, 2022 at 6:48 PM Mark Thomas  wrote:
>
> 
>
> >> On that topic, I originally made the decision to keep LibreSSL support
> >> when I thought that 10.1.x would required Tomcat Native 2.0.x. The plan
> >> has since shifted and 10.1.x will ship with Tomcat Native 2.0.x but will
> >> still be able to use (a sufficiently recent) Tomcat Native 1.2.x. With
> >> that in mind, do we want to keep LibreSSL support in Tomcat Native 2.0.x?
> >
> > If tomcat-native 2.0 is fully aligned with what the Panama code does
> > (so no LibreSSL), it would be better for a future transition to it.
> > OTOH, it would force supporting 1.2 for (much) longer.
>
> Hmm. Tricky.
>
> If we assume that we need to support Tomcat Native 1.x until EOL of
> 9.0.x (due to the o.a.t.u.jni package) the we will be supporting 1.x for
> (best guess) until 2028 or so.
>
> OpenSSL 1.1.1 is EOL 2023-09-11 so there is a 4/5 year gap there.
> However, various distributions are committed to supporting OpenSSL 1.1.1
> for much longer.
>
> Looking at the various timescales, I think we should be helpful to the
> downstream distributions where we can but they are going to have to take
> on some of the maintenance work for their LTS distributions once OpenSSL
> 1.1.1 reaches EOL.
>
> So that starts to look like 1.3.x (built with OpenSSL 3.0.x) around the
> middle of next year. That should be good to Sept 2026. Not sure what
> we'd for the last few years of 9.0.x. 1.4.x built on whatever the new
> OpenSSL LTS is?
>
> Then what do we do with LibreSSL? Maintain support in the 1.x branch?
>
> Given the direction of travel (towards Panama and using OpenSSL
> directly) how much effort do we want to put into LibreSSL support?
>
> Do we want to announce an early EOL for the deprecated parts of the
> o.a.t.u.jni package with a view to removing them during the lifetime of
> 8.5.x and 9.0.x? That would simplify planning (Tomcat Native 1.2.x would
> EOL at the same time). But it would be highly unusual for us to do that
> and could cause breakage with a point release.
>
> What about LibreSSL? Are we looking towards a panama module for LibreSSL
> and then some glue code so you can swap between panama modules for
> different TLS native libraries?
>
> Lots of questions there. Nothing jumps out at me as the "obvious" plan.
> Thoughts?

Technically right now, the Panama code works with OpenSSL 1.1.1 (but
not 1.1.0), since that's what I was using on my Fedora 35 (Fedora 36
now uses OpenSSL 3.0). OTOH, by the time this code is supported, 3.0
(or more) seems like a more realistic target as we're not going to say
that it supports EOLed versions.

I believe it is possible to support 1.1.1 in tomcat-native 2.0, since
all the useful new init and TLS 1.3 capabilities are in place. I'm not
sure LibreSSL has these init changes which is why it's a problem to
support it with Panama (it's pretty verbose and error prone, also the
calls might well go away in OpenSSL eventually since they are not used
anymore).

Rémy

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



Re: [tomcat-native] 01/02: Minimum OpenSSl version is 3.0.0 is keylog callback is always available

2022-05-31 Thread Rémy Maucherat
On Tue, May 31, 2022 at 6:48 PM Mark Thomas  wrote:
>
> On 31/05/2022 17:34, Christopher Schultz wrote:
> > Mark,
> >
> > On 5/31/22 11:30, ma...@apache.org wrote:
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> markt pushed a commit to branch main
> >> in repository https://gitbox.apache.org/repos/asf/tomcat-native.git
> >>
> >> commit b6952740dd64fa8ea7edd1764d4b14661527a0eb
> >> Author: Mark Thomas 
> >> AuthorDate: Wed May 25 16:15:02 2022 +0100
> >>
> >>  Minimum OpenSSl version is 3.0.0 is keylog callback is always
> >> available
> >
> > If the minimum version of OpenSSL is 3.0.0, then probably MANY MANY
> > #ifdefs can be removed.
> >
> > Removing the would, of course, cause lots of merge conflicts when
> > back-ports are done so it's probably not worth it. Given that (chaos),
> > I'm curious: why did you remove this one in particular?
>
> A lot look like they might need to stay - at least in some form - if we
> want to continue to support LibreSSL in Tomcat Native 2.0.x.
>
> I do have a large commit that removes a lot of unused code. I need to
> wait until Tomcat Native 1.2.34 is released before I merge that commit
> else Tomcat 10.1.x won't be able to use Tomcat Native unless you build
> Tomcat native from source.
>
> I'm generally removing stuff as I spot that it is no longer required. My
> intention is to remove everything I can. The merge conflicts might not
> be too bad...
>
> On that topic, I originally made the decision to keep LibreSSL support
> when I thought that 10.1.x would required Tomcat Native 2.0.x. The plan
> has since shifted and 10.1.x will ship with Tomcat Native 2.0.x but will
> still be able to use (a sufficiently recent) Tomcat Native 1.2.x. With
> that in mind, do we want to keep LibreSSL support in Tomcat Native 2.0.x?

If tomcat-native 2.0 is fully aligned with what the Panama code does
(so no LibreSSL), it would be better for a future transition to it.
OTOH, it would force supporting 1.2 for (much) longer.

Rémy

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



Re: Tomcat Native 2.0 Update

2022-05-31 Thread Rémy Maucherat
On Tue, May 31, 2022 at 9:46 AM Mark Thomas  wrote:
>
> On 30/05/2022 20:05, Rémy Maucherat wrote:
> > On Mon, May 30, 2022 at 6:49 PM Mark Thomas  wrote:
> >>
> >> Hi all,
> >>
> >> I have made some progress. I have a trimmed down Tomcat Native 2.0 built
> >> with OpenSSL 3.0 working locally with Tomcat 10.1.x. I also have it
> >> working with the OpenSSL 3 FIPS provider.
> >>
> >> I have also been thinking about Tomcat Native 1.2.x and 2.0.x
> >> interoperability.
> >>
> >> Since Native 2.0 is mostly (apart from one new FIPS method) a subset of
> >> Native 1.2 it should be relatively easy for 10.1.x to work with Native
> >> 2.0.x or 1.2.x.
> >>
> >> Allowing Native 1.2.x use with Tomcat 10.1.x should make it easier on
> >> downstream distributions as it removes the need for them to update to
> >> APR 1.7.x and OpenSSL 3.0.x
> >>
> >> Getting 10.0.x and earlier working with Native 2.0.x is a little
> >> trickier although it doable if the limits are:
> >> - No APR/Native connector
> >> - No application usage of o.a.t.u.jni (as most of the native code is
> >> removed)
> >>
> >> Enabling Native 2.0.x use with Tomcat 10.0.x and earlier opens up the
> >> possibility of OpenSSL FIPS that doesn't depend on an unsupported
> >> version of OpenSSL.
> >>
> >> I am currently thinking along the following lines:
> >>
> >> - release Tomcat Native 1.2.34 that includes:
> >> - refactoring the caching of the FileInfo and Sockaddr classes so
> >>   that are only cached if used
> >> - any additional refactoring to allow Native 1.2.x to be used in
> >>   Tomcat 10.1.x with all the deprecated code removed
> >>
> >> - make Tomcat Native 1.2.34 the minimum required Tomcat Native version
> >> for Tomcat 10.1.x
> >>
> >> - release Tomcat Native 2.0.0
> >>
> >> - make Tomcat Native 2.0.0 the minimum recommended Tomcat Native
> >> version for Tomcat 10.1.x
> >>
> >> - updates as required to Tomcat Native 1.2.x, 2.0.x and Tomcat
> >> <=10.0.x to allow Tomcat Native 2.0.x to be used (reasonably) safely
> >> with Tomcat <=10.0.x
> >>
> >> My plan is to do most of this work locally to make sure I haven't missed
> >> anything and then start committing and releasing in the order above.
> >
> > Sounds great. Any subtask for me or do you prefer doing it alone ?
>
> Thanks for the offer of help.
>
> I have a lot of the above ready locally already and everything is
> inter-related making it hard to extract independent sub-tasks. With all
> the inter-dependencies I might miss something so if you could keep that
> in mind when reviewing my commits that would be helpful.
>
> The tasks below, particularly the first and third, are largely
> independent. If you have time to look at either of those that would be
> great. I'll try and commit the bulk of the initial changes for Tomcat
> Native 2.0.x today.

Ok !

About the first item, I don't recall any deprecated call being used
for the OpenSSL 3.0 code path when I converted to Panama, but I will
review again.

About LibreSSL, it is not a good target for the Panama code. First
reason is without ifdef then it makes things more complex. Second
reason is possible use of extra APIs that would be only in OpenSSL
(for example if they ever add the promised high level API for QUIC
support).

Rémy

> Thanks,
>
> Mark
>
> >> Additional tasks that don't have the any ordering dependencies (that I
> >> can think of) include:
> >>
> >> - update the Tomcat Native 2.0.x code not to use any of the deprecated
> >> OpenSSL APIs
> >>
> >> - when in FIPS required mode, consider checking individually negotiated
> >> ciphers are from the FIPS provider in case the user has multiple
> >> providers configured
> >>
> >> - Get LibreSSL fully working (my understanding that may be wrong is that
> >> it isn't currently working)
> >
> > Rémy
> >
> >> 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
>

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



Re: Tomcat Native 2.0 Update

2022-05-30 Thread Rémy Maucherat
On Mon, May 30, 2022 at 6:49 PM Mark Thomas  wrote:
>
> Hi all,
>
> I have made some progress. I have a trimmed down Tomcat Native 2.0 built
> with OpenSSL 3.0 working locally with Tomcat 10.1.x. I also have it
> working with the OpenSSL 3 FIPS provider.
>
> I have also been thinking about Tomcat Native 1.2.x and 2.0.x
> interoperability.
>
> Since Native 2.0 is mostly (apart from one new FIPS method) a subset of
> Native 1.2 it should be relatively easy for 10.1.x to work with Native
> 2.0.x or 1.2.x.
>
> Allowing Native 1.2.x use with Tomcat 10.1.x should make it easier on
> downstream distributions as it removes the need for them to update to
> APR 1.7.x and OpenSSL 3.0.x
>
> Getting 10.0.x and earlier working with Native 2.0.x is a little
> trickier although it doable if the limits are:
> - No APR/Native connector
> - No application usage of o.a.t.u.jni (as most of the native code is
>removed)
>
> Enabling Native 2.0.x use with Tomcat 10.0.x and earlier opens up the
> possibility of OpenSSL FIPS that doesn't depend on an unsupported
> version of OpenSSL.
>
> I am currently thinking along the following lines:
>
> - release Tomcat Native 1.2.34 that includes:
>- refactoring the caching of the FileInfo and Sockaddr classes so
>  that are only cached if used
>- any additional refactoring to allow Native 1.2.x to be used in
>  Tomcat 10.1.x with all the deprecated code removed
>
> - make Tomcat Native 1.2.34 the minimum required Tomcat Native version
>for Tomcat 10.1.x
>
> - release Tomcat Native 2.0.0
>
> - make Tomcat Native 2.0.0 the minimum recommended Tomcat Native
>version for Tomcat 10.1.x
>
> - updates as required to Tomcat Native 1.2.x, 2.0.x and Tomcat
><=10.0.x to allow Tomcat Native 2.0.x to be used (reasonably) safely
>with Tomcat <=10.0.x
>
> My plan is to do most of this work locally to make sure I haven't missed
> anything and then start committing and releasing in the order above.

Sounds great. Any subtask for me or do you prefer doing it alone ?

> Additional tasks that don't have the any ordering dependencies (that I
> can think of) include:
>
> - update the Tomcat Native 2.0.x code not to use any of the deprecated
>OpenSSL APIs
>
> - when in FIPS required mode, consider checking individually negotiated
>ciphers are from the FIPS provider in case the user has multiple
>providers configured
>
> - Get LibreSSL fully working (my understanding that may be wrong is that
>it isn't currently working)

Rémy

> 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: [tomcat] branch 9.0.x updated: Additional fixes for 66076

2022-05-25 Thread Rémy Maucherat
On Tue, May 24, 2022 at 6:46 PM  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> markt 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 680db4448d Additional fixes for 66076
> 680db4448d is described below
>
> commit 680db4448d392752fb57b91639e7ab34a3f58105
> Author: Mark Thomas 
> AuthorDate: Tue May 24 17:46:20 2022 +0100
>
> Additional fixes for 66076
>
> The vectored IO version of the fix.
> ---
>  java/org/apache/tomcat/util/net/AprEndpoint.java  |  7 +++
>  java/org/apache/tomcat/util/net/Nio2Endpoint.java |  7 +++
>  java/org/apache/tomcat/util/net/NioEndpoint.java  | 19 
> ---
>  .../org/apache/tomcat/util/net/SocketWrapperBase.java |  4 +++-
>  4 files changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/java/org/apache/tomcat/util/net/AprEndpoint.java 
> b/java/org/apache/tomcat/util/net/AprEndpoint.java
> index c02e90fc09..20d10efa11 100644
> --- a/java/org/apache/tomcat/util/net/AprEndpoint.java
> +++ b/java/org/apache/tomcat/util/net/AprEndpoint.java
> @@ -2813,6 +2813,13 @@ public class AprEndpoint extends 
> AbstractEndpoint implements SNICallB
>  return inline;
>  }
>
> +@Override
> +protected boolean hasOutboundRemaining() {
> +// NIO2 never has remaining outbound data when the completion
> +// handler is called
> +return false;
> +}
> +
>  @Override
>  public void run() {
>  // Perform the IO operation
> diff --git a/java/org/apache/tomcat/util/net/Nio2Endpoint.java 
> b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
> index 49ee411016..c5b9a395f5 100644
> --- a/java/org/apache/tomcat/util/net/Nio2Endpoint.java
> +++ b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
> @@ -1021,6 +1021,13 @@ public class Nio2Endpoint extends 
> AbstractJsseEndpoint  return Nio2Endpoint.isInline();
>  }
>
> +@Override
> +protected boolean hasOutboundRemaining() {
> +// NIO2 never has remaining outbound data when the completion
> +// handler is called
> +return false;
> +}
> +
>  @Override
>  protected void start() {
>  if (read) {
> diff --git a/java/org/apache/tomcat/util/net/NioEndpoint.java 
> b/java/org/apache/tomcat/util/net/NioEndpoint.java
> index b8b6d4339d..ea65dd6600 100644
> --- a/java/org/apache/tomcat/util/net/NioEndpoint.java
> +++ b/java/org/apache/tomcat/util/net/NioEndpoint.java
> @@ -1622,6 +1622,11 @@ public class NioEndpoint extends 
> AbstractJsseEndpoint
>  return inline;
>  }
>
> +@Override
> +protected boolean hasOutboundRemaining() {
> +return getSocket().getOutboundRemaining() > 0;
> +}
> +
>  @Override
>  public void run() {
>  // Perform the IO operation
> @@ -1654,13 +1659,13 @@ public class NioEndpoint extends 
> AbstractJsseEndpoint
>  } else {
>  boolean doWrite = true;
>  // Write from main buffer first
> -if 
> (!socketBufferHandler.isWriteBufferEmpty()) {
> +if (socketOrNetworkBufferHasDataLeft()) {
>  // There is still data inside the main 
> write buffer, it needs to be written first
>  
> socketBufferHandler.configureWriteBufferForRead();
>  do {
>  nBytes = 
> getSocket().write(socketBufferHandler.getWriteBuffer());
> -} while 
> (!socketBufferHandler.isWriteBufferEmpty() && nBytes > 0);
> -if 
> (!socketBufferHandler.isWriteBufferEmpty()) {
> +} while 
> (socketOrNetworkBufferHasDataLeft() && nBytes > 0);
> +if (socketOrNetworkBufferHasDataLeft()) {
>  doWrite = false;
>  }
>  // Preserve a negative value since it is 
> an error
> @@ -1681,7 +1686,8 @@ public class NioEndpoint extends 
> AbstractJsseEndpoint
>  updateLastWrite();
>  }
>  }
> -if (nBytes != 0 || 
> !buffersArrayHasRemaining(buffers, offset, length)) {
> +if (nBytes != 0 || 
> (!buffersArrayHasRemaining(buffers, offset, length) &&
> +

Re: Plans for Tomcat Native

2022-05-24 Thread Rémy Maucherat
On Tue, May 24, 2022 at 3:42 PM Christopher Schultz
 wrote:
>
> Mark,
>
> On 5/23/22 14:58, Mark Thomas wrote:
> > Hi all,
> >
> > I've started to look at this and I think we need a slightly broader
> > plan. Hence this post to discuss it before I do to much work on it.
> >
> > It looks like we are going to need to support OpenSSL 1.1.1 in some form
> > for quite some time. We are also going to need to support OpenSSL 3.0.x.
> >
> > Then there is LibreSSL. That appears to have been forked from OpenSSL
> > 1.0.2 and hasn't kept completely in sync with subsequent API changes.
> >
> > I really don't want to have to support what are essentially three
> > different APIs to the native SSL library. But I'd like to try and keep
> > support for LibreSSL.
> >
> > Then there is the long term plan to reduce the Native library to the
> > minimum required for NIO(2)+OpenSSL.
> >
> > It appears that LibreSSL does include most/all (TBC) of the API required
> > for NIO(2)+OpenSSL.
> >
> > Given the above I am now thinking about the following plan.
> >
> > Tomcat Native main becomes 2.0.x where:
> > - requires OpenSSL 3.0.x
> > - requires APR 1.7.0 (or not at all)
> > - can be built with LibreSSL (TBC)
> > - drops all the native code apart from that required for NIO(2)+OpenSSL
> > - is the minimum Tomcat Native version required by 10.1.x
> > - provides FIPS support for 3.0.x
> >
> > Tomcat Native 1.2.x continues in a (low) maintenance mode
> > - No changes to minimum versions
> > - Security fixes
> > - Releases to pick up newer OpenSSL versions for Windows binaries
> >
> > My aim would be for it to be possible to use Tomcat Native 2.0.x with
> > Tomcat 9.0.x and earlier, provided it was only used for NIO(2)+OpenSSL.
> > Trying to use APR or any of the other native code would result in an error.
> >
> > Optionally, at some point in the future, 1.2.x gets replaced by 1.3.x
> > that increases minimum versions to OpenSSL 1.1.1 and APR 1.6.3. I'm not
> > sure about this and what it means for OpenSSL 1.x and FIPS support. That
> > said, that code is no longer supported by OpenSSL so it may not be a
> > concern.
> >
> > Thoughts on the updated plan. Suggestions for a different approach?
>
> I like what you have above, especially the decision to go to 2.0 because
> it will be such a big API change. I don't want people complaining that
> we removed some obscure file-manipulation call we've had in there since
> the beginning in a .1 release or something like that.
>
> I also agree with Rémy about Panama: being able to ditch tcnative would
> be really great. It's a source of headaches and just "more code" most of
> which is glue.

Also if OpenSSL does QUIC (they promised a high level API ...), then
it will be possible to use it through Panama.

> I'd be interested to know what has happened with the new, rapid pace of
> JVM releases in terms of the TLS stack. Specifically, Jean-Frederic
> determined a few years ago that the JDK wasn't using hardware
> acceleration for the AES block cipher which was killing the performance
> of a lot of the TLS stack, and so OpenSSL-based TLS would continue to be
> a requirement for high-performance TLS with Tomcat.

>From what I can tell OpenSSL is still significantly faster on the same
commonly used cipher. There's more difference for the (more complex)
handshake process (it's really much faster there).

> I think that was around Java 8 or Java 9, but we have 10 more versions
> to consider these days. If Java itself is out of that rut, I thin it
> makes tcnative even *less* useful. I thikn it may be required in
> environments where exotic components are used like HSMs, but for most
> people I hope tcnative+OpenSSL won't be required for very much longer.

Maybe we should only count LTS releases though (11, 17, 21). So
basically, we should be able to drop tomcat-native as soon as we're
willing to tell people they need Java 21 to use OpenSSL. So if that
new tomcat-native 2.0 branch happens, then it gives a nice functional
bridge for a few years towards what the Panama version will provide.

Rémy

> Jean-Frederic, are you able to re-test a modern JVM to see if hardware
> acceleration is actually being used these days?
>
> -chris
>
> > On 23/05/2022 11:52, Mark Thomas wrote:
> >> Hi all,
> >>
> >> A question on the users list about Tomcat Native, OpenSSL 3.0 FIPs
> >> caused me to take a look at the current state of supported versions.
> >>
> >> The detail is here:
> >> https://github.com/apache/tomcat-native/blob/main/native/srclib/VERSIONS
> >>
> >> The planned transition to Tomcat Native 1.3 never happened in April
> >> 2021 so I'd like to propose the following:
> >>
> >> - Create a 1.2.x branch from current main
> >> - main becomes 1.3.x
> >> - 1.3.x is updated to require at least OpenSSL 1.1.1
> >> - 1.3.x is updated to require at least APR 1.6.3
> >> - Update 1.3.x to support OpenSSL 3.x in FIPS mode
> >> - Update 10.1.x to require at least Tomcat Native 1.3.x
> >>
> >> 1.2.x releases will continue 

Re: Plans for Tomcat Native

2022-05-24 Thread Rémy Maucherat
On Mon, May 23, 2022 at 8:59 PM Mark Thomas  wrote:
>
> Hi all,
>
> I've started to look at this and I think we need a slightly broader
> plan. Hence this post to discuss it before I do to much work on it.
>
> It looks like we are going to need to support OpenSSL 1.1.1 in some form
> for quite some time. We are also going to need to support OpenSSL 3.0.x.
>
> Then there is LibreSSL. That appears to have been forked from OpenSSL
> 1.0.2 and hasn't kept completely in sync with subsequent API changes.
>
> I really don't want to have to support what are essentially three
> different APIs to the native SSL library. But I'd like to try and keep
> support for LibreSSL.
>
> Then there is the long term plan to reduce the Native library to the
> minimum required for NIO(2)+OpenSSL.
>
> It appears that LibreSSL does include most/all (TBC) of the API required
> for NIO(2)+OpenSSL.
>
> Given the above I am now thinking about the following plan.
>
> Tomcat Native main becomes 2.0.x where:
> - requires OpenSSL 3.0.x
> - requires APR 1.7.0 (or not at all)
> - can be built with LibreSSL (TBC)
> - drops all the native code apart from that required for NIO(2)+OpenSSL
> - is the minimum Tomcat Native version required by 10.1.x
> - provides FIPS support for 3.0.x
>
> Tomcat Native 1.2.x continues in a (low) maintenance mode
> - No changes to minimum versions
> - Security fixes
> - Releases to pick up newer OpenSSL versions for Windows binaries
>
> My aim would be for it to be possible to use Tomcat Native 2.0.x with
> Tomcat 9.0.x and earlier, provided it was only used for NIO(2)+OpenSSL.
> Trying to use APR or any of the other native code would result in an error.
>
> Optionally, at some point in the future, 1.2.x gets replaced by 1.3.x
> that increases minimum versions to OpenSSL 1.1.1 and APR 1.6.3. I'm not
> sure about this and what it means for OpenSSL 1.x and FIPS support. That
> said, that code is no longer supported by OpenSSL so it may not be a
> concern.
>
> Thoughts on the updated plan. Suggestions for a different approach?

Given what Panama does and the results, I think we should be planning
an end plan for tomcat-native. That 2.0 branch as you describe it
would be a good transition and could be a good "final" branch.

Rémy



> Mark
>
>
> On 23/05/2022 11:52, Mark Thomas wrote:
> > Hi all,
> >
> > A question on the users list about Tomcat Native, OpenSSL 3.0 FIPs
> > caused me to take a look at the current state of supported versions.
> >
> > The detail is here:
> > https://github.com/apache/tomcat-native/blob/main/native/srclib/VERSIONS
> >
> > The planned transition to Tomcat Native 1.3 never happened in April 2021
> > so I'd like to propose the following:
> >
> > - Create a 1.2.x branch from current main
> > - main becomes 1.3.x
> > - 1.3.x is updated to require at least OpenSSL 1.1.1
> > - 1.3.x is updated to require at least APR 1.6.3
> > - Update 1.3.x to support OpenSSL 3.x in FIPS mode
> > - Update 10.1.x to require at least Tomcat Native 1.3.x
> >
> > 1.2.x releases will continue until we have a stable 1.3x release.
> >
> > 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: [tomcat] branch main updated: Refactor to remove syncs on SocketWrapper to support Loom experiments

2022-05-23 Thread Rémy Maucherat
On Mon, May 23, 2022 at 6:29 PM Mark Thomas  wrote:
>
> On 23/05/2022 17:27, ma...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > markt pushed a commit to branch main
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> >
> > The following commit(s) were added to refs/heads/main by this push:
> >   new 0a94801588 Refactor to remove syncs on SocketWrapper to support 
> > Loom experiments
> > 0a94801588 is described below
> >
> > commit 0a9480158874ea910a4d629d24f31d69d6cc5f96
> > Author: Mark Thomas 
> > AuthorDate: Mon May 23 17:27:24 2022 +0100
> >
> >  Refactor to remove syncs on SocketWrapper to support Loom experiments
>
>  From what has been posted on dev@, I think this should be sufficient
> for folks that want to explore loom to get started. I strongly suspect
> further changes will be required as those experimenting with loom expand
> the range of Tomcat features they want to use. My thinking is we address
> any additional refactoring as the need for it is identified.

I read the instructions for Loom and researched, and it doesn't seem
to me like a good fit for an app server, to be honest. At this point
at least. Thread locals apparently don't work as well, so there's a
large amount of the functionality that cannot be implemented (AFAIK).
>From the IO side, it would mean going (back) to java.io if we're
really serious about it, since it's the most efficient (it's basically
java.io > NIO > NIO2). Also native code is kind of a problem it seems.

Rémy

> 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: Plans for Tomcat Native

2022-05-23 Thread Rémy Maucherat
On Mon, May 23, 2022 at 12:52 PM Mark Thomas  wrote:
>
> Hi all,
>
> A question on the users list about Tomcat Native, OpenSSL 3.0 FIPs
> caused me to take a look at the current state of supported versions.
>
> The detail is here:
> https://github.com/apache/tomcat-native/blob/main/native/srclib/VERSIONS
>
> The planned transition to Tomcat Native 1.3 never happened in April 2021
> so I'd like to propose the following:
>
> - Create a 1.2.x branch from current main
> - main becomes 1.3.x
> - 1.3.x is updated to require at least OpenSSL 1.1.1
> - 1.3.x is updated to require at least APR 1.6.3
> - Update 1.3.x to support OpenSSL 3.x in FIPS mode
> - Update 10.1.x to require at least Tomcat Native 1.3.x
>
> 1.2.x releases will continue until we have a stable 1.3x release.
>
> Thoughts?

+1

Rémy

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



Re: JDK 19 - Virtual Threads Testing!

2022-05-20 Thread Rémy Maucherat
On Fri, May 20, 2022 at 9:35 AM Martin Grigorov  wrote:
>
> On Tue, May 17, 2022 at 4:23 PM Rémy Maucherat  wrote:
>
> > On Tue, May 17, 2022 at 12:27 PM Mark Thomas  wrote:
> > >
> > > On 16/05/2022 14:14, Martin Grigorov wrote:
> > > > Hello Tomcat devs,
> > > >
> > > > Some tests fail with JDK 19-ea+22-1598:
> > >
> > > 
> > >
> > > >[concat] Testsuites with failed tests:
> > > > [concat] TEST-jakarta.el.TestImportHandlerStandardPackages.NIO.txt
> > > > [concat] TEST-jakarta.el.TestImportHandlerStandardPackages.NIO2.txt
> > >
> > > 
> > >
> > > > Here are the error types:
> > > >
> > > >
> > > > 1. Testsuite: jakarta.el.TestImportHandlerStandardPackages
> > > > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.463
> > sec
> > > >
> > > > Testcase: testClassListsAreComplete took 0.444 sec
> > > >  FAILED
> > > > java.lang.Thread.Builder.OfPlatform
> > > > junit.framework.AssertionFailedError:
> > java.lang.Thread.Builder.OfPlatform
> > > >  at
> > > >
> > jakarta.el.TestImportHandlerStandardPackages.lambda$checkPackageClassList$12(TestImportHandlerStandardPackages.java:77)
> > > >  at
> > > >
> > java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> > > >  at
> > > >
> > java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> > > >  at
> > > >
> > java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> > >
> > > I've fixed this one. Looking at the others.
> >
> > Ok, so since we're now adding support for Java 19 and the current
> > trunk has the Panama preview API, I'll add a new "openssl-foreign"
> > module that targets it.
> >
>
> According to
> https://github.com/openjdk/jdk/commit/2c5d136260fa717afa374db8b923b7c886d069b7
> the FF & Memory API is added in b23.
> Above we were using b22.
>
> https://jdk.java.net/19/ has been just updated to b23.
>
> Do you want me to update JDK 19 at Buildbot (& Jenkins) to b23 ?

That's good news if you want to test the OpenSSL support with a more
final version. I don't really know what kind of API changes can be
expected following the preview, so we'll see how that goes. The API
itself is a lot cleaner than the one from Java 17.

One feature remaining that could be interesting depending on how it's
done is: https://bugs.openjdk.java.net/browse/JDK-8254693
Allowing to pass heap byte buffers (as long as this capability remains
flexible enough, if there's a surprise like "you can never deallocate
it" then it's not going to be useful ...) would be very significant
for Tomcat allowing to get rid of ugly memory copies and direct BB
allocations.

The full foreign task list is:
https://bugs.openjdk.java.net/Dashboard.jspa?selectPageId=18412

Rémy

>
>
> >
> > Rémy
> >
> > > 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: [tomcat] branch main updated: The ObjectStreamClass memory leak has been fixed in newer JREs

2022-05-18 Thread Rémy Maucherat
On Wed, May 18, 2022 at 8:52 PM  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
>  new 93108de112 The ObjectStreamClass memory leak has been fixed in newer 
> JREs
> 93108de112 is described below
>
> commit 93108de1127fb228e343a3f3304554bfe7177583
> Author: Mark Thomas 
> AuthorDate: Wed May 18 19:52:00 2022 +0100
>
> The ObjectStreamClass memory leak has been fixed in newer JREs
>
> https://bugs.openjdk.java.net/browse/JDK-8277072
> Disable the clean-up code when running on a JRE that includes the fix.

This is great because accessing the structures to clean them up looked
hard to me (I couldn't understand how this cache worked today ;) ).

Rémy

> ---
>  .../catalina/loader/WebappClassLoaderBase.java | 27 
> +++---
>  webapps/docs/changelog.xml |  5 
>  webapps/docs/config/context.xml|  4 
>  3 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/java/org/apache/catalina/loader/WebappClassLoaderBase.java 
> b/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> index b87cc72abe..6ba682b610 100644
> --- a/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> +++ b/java/org/apache/catalina/loader/WebappClassLoaderBase.java
> @@ -2289,6 +2289,12 @@ public abstract class WebappClassLoaderBase extends 
> URLClassLoader
>
>
>  private void clearReferencesObjectStreamClassCaches() {
> +if (JreCompat.isJre19Available()) {
> +// The memory leak this fixes has been fixed in Java 19 onwards,
> +// 17.0.4 onwards and 11.0.16 onwards
> +// See https://bugs.openjdk.java.net/browse/JDK-8277072
> +return;
> +}
>  try {
>  Class clazz = 
> Class.forName("java.io.ObjectStreamClass$Caches");
>  clearCache(clazz, "localDescs");
> @@ -2316,14 +2322,19 @@ public abstract class WebappClassLoaderBase extends 
> URLClassLoader
>  throws ReflectiveOperationException, SecurityException, 
> ClassCastException {
>  Field f = target.getDeclaredField(mapName);
>  f.setAccessible(true);
> -Map map = (Map) f.get(null);
> -Iterator keys = map.keySet().iterator();
> -while (keys.hasNext()) {
> -Object key = keys.next();
> -if (key instanceof Reference) {
> -Object clazz = ((Reference) key).get();
> -if (loadedByThisOrChild(clazz)) {
> -keys.remove();
> +Object map = f.get(null);
> +// Avoid trying to clear references if Tomcat is running on a JRE 
> that
> +// includes the fix for this memory leak
> +// See https://bugs.openjdk.java.net/browse/JDK-8277072
> +if (map instanceof Map) {
> +Iterator keys = ((Map) map).keySet().iterator();
> +while (keys.hasNext()) {
> +Object key = keys.next();
> +if (key instanceof Reference) {
> +Object clazz = ((Reference) key).get();
> +if (loadedByThisOrChild(clazz)) {
> +keys.remove();
> +}
>  }
>  }
>  }
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index 2b22817b79..c1a182402b 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -115,6 +115,11 @@
>  Improve the error message if a required --add-opens 
> option
>  is missing. (markt)
>
> +  
> +Disable the memory leak correction code enabled by the Context 
> attribute
> +clearReferencesObjectStreamClassCaches when running on a
> +JRE that includes a fix for the underlying memory leak. (markt)
> +  
>  
>
>
> diff --git a/webapps/docs/config/context.xml b/webapps/docs/config/context.xml
> index 78e75b20d8..0fa30a07f2 100644
> --- a/webapps/docs/config/context.xml
> +++ b/webapps/docs/config/context.xml
> @@ -799,6 +799,10 @@
>  therefore requires that the command line option
>  -XaddExports:java.base/java.io=ALL-UNNAMED is set. If 
> not
>  specified, the default value of true will be used.
> +The memory leak associated with ObjectStreamClass has
> +been fixed in Java 19 onwards, Java 17.0.4 onwards and Java 11.0.16
> +onwards. The check will be disabled when running on a version
> +of Java that contains the fix.
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, 

Re: JDK 19 - Virtual Threads Testing!

2022-05-17 Thread Rémy Maucherat
On Tue, May 17, 2022 at 12:27 PM Mark Thomas  wrote:
>
> On 16/05/2022 14:14, Martin Grigorov wrote:
> > Hello Tomcat devs,
> >
> > Some tests fail with JDK 19-ea+22-1598:
>
> 
>
> >[concat] Testsuites with failed tests:
> > [concat] TEST-jakarta.el.TestImportHandlerStandardPackages.NIO.txt
> > [concat] TEST-jakarta.el.TestImportHandlerStandardPackages.NIO2.txt
>
> 
>
> > Here are the error types:
> >
> >
> > 1. Testsuite: jakarta.el.TestImportHandlerStandardPackages
> > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.463 sec
> >
> > Testcase: testClassListsAreComplete took 0.444 sec
> >  FAILED
> > java.lang.Thread.Builder.OfPlatform
> > junit.framework.AssertionFailedError: java.lang.Thread.Builder.OfPlatform
> >  at
> > jakarta.el.TestImportHandlerStandardPackages.lambda$checkPackageClassList$12(TestImportHandlerStandardPackages.java:77)
> >  at
> > java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> >  at
> > java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> >  at
> > java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>
> I've fixed this one. Looking at the others.

Ok, so since we're now adding support for Java 19 and the current
trunk has the Panama preview API, I'll add a new "openssl-foreign"
module that targets it.

Rémy

> 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: [VOTE] Release Apache Tomcat 8.5.79

2022-05-16 Thread Rémy Maucherat
On Mon, May 16, 2022 at 6:13 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 8.5.79 release is now available for voting.
>
> The notable changes compared to 8.5.78 are:
>
> - Provide a property source that sources values from Kubernetes service
> bindings. Provided by Sumit Kulhadia and Gareth Evans.
>
> - The root cause of the Linux kernel duplicate accept bug has been
> identified along with the version of the kernel that includes the fix.
> The error message displayed when this bug occurs has been updated to
> reflect this new information and to advise users to update to a
> version of the OS that uses kernel 5.10 or later. Thanks to
> Christopher Gual for the research into this issue.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.33 to
> pick up Windows binaries built with OpenSSL 1.1.1o.
>
> - Add support for encrypted PKCS#1 formatted private keys when
> configuring the internal, in memory key store.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.79/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1375
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.79
> 1af5f227ae591e601a9426d3788bf6a60a1b75a3
>
> The proposed 8.5.79 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.79 (stable)

Rémy

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



[ANN] Apache Tomcat 9.0.63 available

2022-05-16 Thread Rémy Maucherat
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.63.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.63 is a bugfix and feature release. The notable
changes compared to 9.0.62 include:

- Provide a property source that sources values from Kubernetes service
   bindings. Provided by Sumit Kulhadia and Gareth Evans.

- The root cause of the Linux kernel duplicate accept bug has been
   identified along with the version of the kernel that includes the fix.
   The error message displayed when this bug occurs has been updated to
   reflect this new information and to advise users to update to a
   version of the OS that uses kernel 5.10 or later. Thanks to
   Christopher Gual for the research into this issue.

- Update the packaged version of the Tomcat Native Library to 1.2.33 to
   pick up Windows binaries built with OpenSSL 1.1.1o.

- Add support for encrypted PKCS#1 formatted private keys when configuring
   the internal, in memory key store.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



[VOTE][RESULT] Release Apache Tomcat 9.0.63

2022-05-16 Thread Rémy Maucherat
The following votes were cast:

Binding:
+1: remm, markt, isapir

Non-Binding
+1: rotyy3000

No other votes were cast. The vote therefore passes.

Thanks to everyone who contributed to this release.

Rémy

On Wed, May 11, 2022 at 10:26 AM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.63 release is now available for voting.
>
> The notable changes compared to 9.0.62 are:
>
> - Provide a property source that sources values from Kubernetes service
>bindings. Provided by Sumit Kulhadia and Gareth Evans.
>
> - The root cause of the Linux kernel duplicate accept bug has been
>identified along with the version of the kernel that includes the fix.
>The error message displayed when this bug occurs has been updated to
>reflect this new information and to advise users to update to a
>version of the OS that uses kernel 5.10 or later. Thanks to
>Christopher Gual for the research into this issue.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.33 to
>pick up Windows binaries built with OpenSSL 1.1.1o.
>
> - Add support for encrypted PKCS#1 formatted private keys when configuring
>the internal, in memory key store.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.63/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1374
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.63
> 538ed3896852b3608561ba6f3d0bc8890ae15de1
>
> The proposed 9.0.63 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.63 (stable)
>
> Rémy

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



Re: New test in TestPEMFile fails ...

2022-05-12 Thread Rémy Maucherat
On Thu, May 12, 2022 at 9:14 PM Rainer Jung  wrote:
>
> ... for me with Java 1.8.0 332 (various OpenJDK builds) on TC 9.0.63 and
> 10.0.21, platform various Linuxes and also Solaris Sparc. It does not
> fail for Java 11 and also not for Oracle Java 1.8.0 331.

The funny thing is it is the support that was already there in PEMFile
that is failing, and that code is apparently completely unchanged.

So I don't quite understand or maybe it simply never worked (I don't
know the reason why obviously) as the test was not there before.

Rémy

> Testsuite: org.apache.tomcat.util.net.jsse.TestPEMFile
> Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.947 sec
>
> Testcase: testKeyEncryptedPkcs1DesEde3Cbc took 0.59 sec
> Testcase: testKeyEncryptedPkcs8 took 0.196 sec
>  Caused an ERROR
> Cannot retrieve the PKCS8EncodedKeySpec
> java.security.spec.InvalidKeySpecException: Cannot retrieve the
> PKCS8EncodedKeySpec
>  at
> javax.crypto.EncryptedPrivateKeyInfo.getKeySpec(EncryptedPrivateKeyInfo.java:258)
>  at
> org.apache.tomcat.util.net.jsse.PEMFile$Part.toPrivateKey(PEMFile.java:212)
>  at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:143)
>  at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:98)
>  at
> org.apache.tomcat.util.net.jsse.TestPEMFile.testKey(TestPEMFile.java:74)
>  at
> org.apache.tomcat.util.net.jsse.TestPEMFile.testKeyEncrypted(TestPEMFile.java:69)
>  at
> org.apache.tomcat.util.net.jsse.TestPEMFile.testKeyEncryptedPkcs8(TestPEMFile.java:64)
> Caused by: javax.crypto.BadPaddingException: Given final block not
> properly padded. Such issues can arise if a bad key is used during
> decryption.
>  at com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:975)
>  at
> com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1056)
>  at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853)
>  at
> com.sun.crypto.provider.PBES2Core.engineDoFinal(PBES2Core.java:323)
>  at javax.crypto.Cipher.doFinal(Cipher.java:2168)
>  at
> javax.crypto.EncryptedPrivateKeyInfo.getKeySpec(EncryptedPrivateKeyInfo.java:253)
>
> Testcase: testKeyPkcs1 took 0.004 sec
> Testcase: testKeyEncryptedPkcs1Aes256 took 0.035 sec
> Testcase: testKeyEncryptedPkcs1DesCbc took 0.023 sec
>
> Best regards,
>
> Rainer
>
> -
> 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: [VOTE] Release Apache Tomcat 9.0.63

2022-05-11 Thread Rémy Maucherat
On Wed, May 11, 2022 at 10:26 AM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.63 release is now available for voting.
>
> The notable changes compared to 9.0.62 are:
>
> - Provide a property source that sources values from Kubernetes service
>bindings. Provided by Sumit Kulhadia and Gareth Evans.
>
> - The root cause of the Linux kernel duplicate accept bug has been
>identified along with the version of the kernel that includes the fix.
>The error message displayed when this bug occurs has been updated to
>reflect this new information and to advise users to update to a
>version of the OS that uses kernel 5.10 or later. Thanks to
>Christopher Gual for the research into this issue.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.33 to
>pick up Windows binaries built with OpenSSL 1.1.1o.
>
> - Add support for encrypted PKCS#1 formatted private keys when configuring
>the internal, in memory key store.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.63/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1374
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.63
> 538ed3896852b3608561ba6f3d0bc8890ae15de1
>
> The proposed 9.0.63 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.63 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.0.21

2022-05-11 Thread Rémy Maucherat
On Wed, May 11, 2022 at 12:39 AM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.0.21 release is now available for
> voting.
>
> Apache Tomcat 10.0.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to jakarta.*
>
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes. Java EE applications designed for Tomcat 9 and earlier may be
> placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will
> automatically convert them to Jakarta EE and copy them to the webapps
> directory
>
> The notable changes compared to 10.0.20 are:
>
> - Provide a property source that sources values from Kubernetes service
>bindings. Provided by Sumit Kulhadia and Gareth Evans.
>
> - The root cause of the Linux kernel duplicate accept bug has been
>identified along with the version of the kernel that includes the fix.
>The error message displayed when this bug occurs has been updated to
>reflect this new information and to advise users to update to a
>version of the OS that uses kernel 5.10 or later. Thanks to
>Christopher Gual for the research into this issue.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.33 to
>pick up Windows binaries built with OpenSSL 1.1.1o.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.21/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1373
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.21
> feb577944dee2ac7cc9839638e9388d90067f1cb
>
> The proposed 10.0.21 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.0.21 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M15

2022-05-11 Thread Rémy Maucherat
On Tue, May 10, 2022 at 10:25 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.1.0-M15 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M14 are:
>
> - Provide a property source that sources values from Kubernetes service
>bindings. Provided by Sumit Kulhadia and Gareth Evans.
>
> - The root cause of the Linux kernel duplicate accept bug has been
>identified along with the version of the kernel that includes the fix.
>The error message displayed when this bug occurs has been updated to
>reflect this new information and to advise users to update to a
>version of the OS that uses kernel 5.10 or later. Thanks to
>Christopher Gual for the research into this issue.
>
> - Update the packaged version of the Tomcat Native Library to 1.2.33 to
>pick up Windows binaries built with OpenSSL 1.1.1o.
>
> For full details, see the change log:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M15/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1371
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M15
> dcf3e81b2e709574971c7a9592614d70c1b55bf7
>
>
> The proposed 10.1.0-M15 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 10.1.0-M15 (alpha)

Rémy

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



[VOTE] Release Apache Tomcat 9.0.63

2022-05-11 Thread Rémy Maucherat
The proposed Apache Tomcat 9.0.63 release is now available for voting.

The notable changes compared to 9.0.62 are:

- Provide a property source that sources values from Kubernetes service
   bindings. Provided by Sumit Kulhadia and Gareth Evans.

- The root cause of the Linux kernel duplicate accept bug has been
   identified along with the version of the kernel that includes the fix.
   The error message displayed when this bug occurs has been updated to
   reflect this new information and to advise users to update to a
   version of the OS that uses kernel 5.10 or later. Thanks to
   Christopher Gual for the research into this issue.

- Update the packaged version of the Tomcat Native Library to 1.2.33 to
   pick up Windows binaries built with OpenSSL 1.1.1o.

- Add support for encrypted PKCS#1 formatted private keys when configuring
   the internal, in memory key store.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.63/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1374
The tag is:
https://github.com/apache/tomcat/tree/9.0.63
538ed3896852b3608561ba6f3d0bc8890ae15de1

The proposed 9.0.63 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.63 (stable)

Rémy

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



Re: Trying to use Loom virtual threads with Tomcat

2022-05-02 Thread Rémy Maucherat
On Tue, May 3, 2022 at 6:24 AM Cay Horstmann  wrote:
>
> Hi, I am trying to experiment with Loom
> (https://openjdk.java.net/jeps/425) virtual threads in Tomcat 10. There
> is a nice extension point in server.xml where I can provide an Executor
> and use it in the default Connector. It works like a charm--all my
> requests run on a virtual thread, and AFAIK, nothing else does.
>
> There is just one issue. It takes forever for Tomcat to execute the
> virtual threads. I made a timestamp for each invocation of
>
> public void execute(Runnable command)
>
> called from org.apache.tomcat.util.net.AbstractEndpoint.processSocket
>
> When I fire 1000 simultaneous requests, I can see that method being
> invoked 1000 times, but it takes a while to work through the requests.
> The last invocation occurs two minutes (!) from the sending of the requests.
>
> When using the org.apache.catalina.core.StandardThreadExecutor, that
> many requests are handled in 3 seconds.
>
> Is there something that I am overlooking? I had hoped that execute would
> be called near-instantly 1000 times, and then the Loom virtual threads
> could show their mettle and execute concurrently.

I wanted to experiment with Loom, but most likely the current Tomcat
NIO(2) connector is not nice for that. I was thinking that
resurrecting the java.io code (actually: writing a new java.io
connector) could be a slightly better plan, but to be honest I don't
expect very good results. I wasn't planning to do it immediately since
Loom is so experimental right now.

Rémy

> Thanks,
>
> Cay
>
> --
>
> Cay S. Horstmann | http://horstmann.com | mailto:c...@horstmann.com
>
> -
> 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: Native Compilation, Continuation 2022

2022-04-12 Thread Rémy Maucherat
On Tue, Apr 12, 2022 at 9:14 AM Mark Thomas  wrote:
>
> On 11/04/2022 23:32, Filip Hanik wrote:
> > Hi folks,
> >
> > I'm jumping in on the bandwagon again. Specifically to talk some more about
> > native compilation. The graal compiler is making headway, and it's becoming
> > better and better at native compilation [1].
> >
> > I'll put some historical context at the bottom of this post for clarity. I
> > have a few suggestions that I'd like some input on
>
> Keep in mind I have not been as involved in these changes as other folks
> have so while I am expressing my current opinions below, I am likely to
> defer to the folks that have been more involved if their opinion differs
> from mine.
>
> 
>
> > Back to Proposal
> > 1. Remove tomcat-embed-programmatic
> > I believe this served its purpose.
>
> If there is consensus that it has served its purpose then removal makes
> sense. I have no view on whether tomcat-embed-programmatic has served
> its purpose or not.
>
> Would this be deprecation in 9.0.x/10.0.x and removal in 10.1.x?
>
> > 2. Refactor existing graal JSON files
> > This can allow us to create profiles with various memory footprints
> > depending on functionality desired.
>
> Seems reasonable to me.
>
> > 3. Potentially introduce tomcat-embed-graal
> > This can have various code substitutions that we find beneficial. [4]
>
> If this sits alongside the existing code in a separate package and JAR
> (or something along those lines) then that seems reasonable to me.
>
> > 4. Add in build feature flags to the code or code optimizations
> > graal can still do static analysis to optimize inclusion of code paths. as
> > demonstrated in this example [5]. As this seems to pollute our codebase
> > with graal specific stuff when it could have been done as a substitution,
> > I'm still presenting it to gather more opinions.
>
> This is the interesting one.
>
> I think there is a balance to strike here between making native
> compilation easier and making the existing code less clear. I think I'd
> want to look at each proposed refactoring on a case-by-case basis.
> Generally, I'm willing to consider a little more complexity but I
> suspect there will be some cases where substitution is the better option.

Yes, I agree with that opinion, it's all about good balance.

I'm not sure that the additional benefits that remain matter a lot (as
an example, embedded code generation does something, but it's really
little; generating the full web.xml processing was something I tried,
but it starts being very complex very quickly), so this better not do
anything that would look weird or convoluted to achieve something.
Overall Tomcat is still EE so it's never going to be fully optimal for
Graal, which IMO is not the end of the world (the container remains
small compared to the app, so any savings will be hard to notice; feel
free to prove me wrong ;) ). Last, there will be more AOT techs after
Graal.

Rémy

> 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



[ANN] Apache Tomcat 9.0.62 available

2022-04-01 Thread Rémy Maucherat
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.62.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.62 is a bugfix and feature release. The notable
changes compared to 9.0.60 include:

- Update the packaged version of the Tomcat Native Library to 1.2.32 to
   pick up Windows binaries built with OpenSSL 1.1.1n.

- Improve logging of unknown HTTP/2 settings frames. Pull request by
   Thomas Hoffmann.

- Add additional warnings if incompatible TLS configurations are used
   such as HTTP/2 with CLIENT-CERT authentication

- Harden the class loader to provide a mitigation for CVE-2022-22965
   a Spring Framework vulnerability

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



[VOTE][RESULT] Release Apache Tomcat 9.0.62

2022-04-01 Thread Rémy Maucherat
The following votes were cast:

Binding:
+1: remm, fschumacher, markt, csutherl, fhanik, funkman, jfclere

Non-binding:
+1: rotty3000

No other votes were cast. The vote therefore passes.

Thanks to everyone who contributed to this release.

Rémy

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



Re: [VOTE][RESULT] Release Apache Tomcat 10.1.0-M14

2022-04-01 Thread Rémy Maucherat
On Fri, Apr 1, 2022 at 10:27 AM Mark Thomas  wrote:
>
> Hi all,
>
> I am calling the result of this release vote earlier than usual to make
> the alternative mitigation for the Spring vulnerability CVE-2022-22965
> available sooner rather than later.
>
> The following votes were cast:
>
> Binding:
> +1: markt, remm, fschumacher
>
> Non-binding:
> +1: rotty3000

Raymond Augé is a committer.
https://tomcat.apache.org/whoweare.html

Rémy


> The vote therefore passes.
>
> Thanks to everyone who has 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: [VOTE][CANCELLED] Release Apache Tomcat 9.0.61

2022-04-01 Thread Rémy Maucherat
On Wed, Mar 30, 2022 at 10:21 AM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.61 release is now available for voting.
>
> The notable changes compared to 9.0.60 are:
>
> - Fix a potential thread-safety issue that could cause HTTP/1.1 request
>processing to pause, and potentially timeout, waiting for additional
>data when the full request has been received.
>
> - Fix a regression introduced with 65757 bugfix which better identified
>non request threads but which introduced a similar problem when user
>code was doing sequential operations in a single thread.
>
> - When resolving methods in EL expressions that use beans and/or static
>fields, ensure that any custom type conversion is considered when
>identifying the method to call.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.61/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1366
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.61
> 6c6432ac1416ed369f892b9ce76e10c7eb10b91c
>
> The proposed 9.0.61 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.61 (stable)

The vote in cancelled in favor of the 9.0.62 release.

Rémy

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

2022-03-31 Thread Rémy Maucherat
On Thu, Mar 31, 2022 at 11:14 PM Christopher Schultz
 wrote:
>
> Mark,
>
> Thanks for RMing. I hope I didn't break your 8.5.78 git tag. I was 2.5
> hours later than you, and didn't realize you had already rolled the release.

It looks fine: https://github.com/apache/tomcat/tree/8.5.78

Rémy

> Mark, there are two signature files missing from the release artifacts,
> detailed below. Can you check on those?
>
> On 3/31/22 12:54, Mark Thomas wrote:
> > The proposed Apache Tomcat 8.5.78 release is now available for voting.
> >
> > The notable changes compared to 8.5.77 are:
> >
> > - Update the packaged version of the Tomcat Native Library to 1.2.32 to
> > pick up Windows binaries built with OpenSSL 1.1.1n.
> >
> > - Improve logging of unknown HTTP/2 settings frames. Pull request by
> > Thomas Hoffmann.
> >
> > - Add additional warnings if incompatible TLS configurations are used
> > such as HTTP/2 with CLIENT-CERT authentication
> >
> > - Harden the class loader to provide a mitigation for CVE-2022-22965
> > a Spring Framework vulnerability
> >
> > Along with lots of other bug fixes and improvements.
> >
> > This is the third release of Tomcat 8.5 that has been built with Java 11
> > (in Java 7 mode) instead of Java 7. Please report any strangeness you
> > may observe especially if you are running Tomcat 8.5 in an environment
> > using Java < 11. We don't expect any issues, but understand that we
> > cannot test all possible environmental configurations.
> >
> > For full details, see the changelog:
> > https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
> >
> > It can be obtained from:
> > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.78/
> > The Maven staging repo is:
> > https://repository.apache.org/content/repositories/orgapachetomcat-1370
> > The tag is:
> > https://github.com/apache/tomcat/tree/8.5.78
> > f732d3aa5ca55eb07cb73d9ec2b585330f80f00b
> >
> > The proposed 8.5.78 release is:
> > [ ] Broken - do not release
> > [X] Stable - go ahead and release as 8.5.78 (stable)
>
> Works on a vanilla servlet-based web application in a testing environment.
>
> Unit tests pass on Debian Linux and MacOS Big Sur.
>
> Note: the files apache-tomcat-8.5.78.zip.asc and
> apache-tomcat-8.5.78.tar.gz.asc were expected but missing.
>
> Details:
> * Environment
> *  Java (build): openjdk version "1.8.0_292" OpenJDK Runtime
> Environment (build 1.8.0_292-8u292-b10-0+deb9u1-b10) OpenJDK 64-Bit
> Server VM (build 25.292-b10, mixed mode)
> *  Java (test): openjdk version "1.8.0_292" OpenJDK Runtime
> Environment (build 1.8.0_292-8u292-b10-0+deb9u1-b10) OpenJDK 64-Bit
> Server VM (build 25.292-b10, mixed mode)
> *  OS:   Linux 4.19.0-18-amd64 x86_64
> *  cc:   cc (Debian 8.3.0-6) 8.3.0
> *  make: GNU Make 4.2.1
> *  OpenSSL:  OpenSSL 1.1.1 11 Sep 2018
> *  APR:  1.6.5
> *
> * Valid SHA-512 signature for apache-tomcat-8.5.78.zip
> * !! Invalid GPG signature for apache-tomcat-8.5.78.zip
> * Valid SHA-512 signature for apache-tomcat-8.5.78.tar.gz
> * !! Invalid GPG signature for apache-tomcat-8.5.78.tar.gz
> * Valid SHA-512 signature for apache-tomcat-8.5.78.exe
> * Valid GPG signature for apache-tomcat-8.5.78.exe
> * Valid Windows Digital Signature for apache-tomcat-8.5.78.exe
> * Valid SHA512 signature for apache-tomcat-8.5.78-src.zip
> * Valid GPG signature for apache-tomcat-8.5.78-src.zip
> * Valid SHA512 signature for apache-tomcat-8.5.78-src.tar.gz
> * Valid GPG signature for apache-tomcat-8.5.78-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: PASSED
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

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



Re: [VOTE] Release Apache Tomcat 8.5.78

2022-03-31 Thread Rémy Maucherat
On Thu, Mar 31, 2022 at 6:55 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 8.5.78 release is now available for voting.
>
> The notable changes compared to 8.5.77 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.32 to
> pick up Windows binaries built with OpenSSL 1.1.1n.
>
> - Improve logging of unknown HTTP/2 settings frames. Pull request by
> Thomas Hoffmann.
>
> - Add additional warnings if incompatible TLS configurations are used
> such as HTTP/2 with CLIENT-CERT authentication
>
> - Harden the class loader to provide a mitigation for CVE-2022-22965
> a Spring Framework vulnerability
>
> Along with lots of other bug fixes and improvements.
>
> This is the third release of Tomcat 8.5 that has been built with Java 11
> (in Java 7 mode) instead of Java 7. Please report any strangeness you
> may observe especially if you are running Tomcat 8.5 in an environment
> using Java < 11. We don't expect any issues, but understand that we
> cannot test all possible environmental configurations.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.78/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1370
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.78
> f732d3aa5ca55eb07cb73d9ec2b585330f80f00b
>
> The proposed 8.5.78 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.78 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 9.0.62

2022-03-31 Thread Rémy Maucherat
On Thu, Mar 31, 2022 at 4:56 PM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.62 release is now available for voting.
>
> The notable changes compared to 9.0.60 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.32 to
>pick up Windows binaries built with OpenSSL 1.1.1n.
>
> - Improve logging of unknown HTTP/2 settings frames. Pull request by
>Thomas Hoffmann.
>
> - Add additional warnings if incompatible TLS configurations are used
>such as HTTP/2 with CLIENT-CERT authentication
>
> - Harden the class loader to provide a mitigation for CVE-2022-22965
>a Spring Framework vulnerability
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.62/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1368
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.62
> 85113741042dcce9e9792bdbc3d498172bc31291
>
> The proposed 9.0.62 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.62 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.0.20

2022-03-31 Thread Rémy Maucherat
On Thu, Mar 31, 2022 at 5:20 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.0.20 release is now available for
> voting.
>
> Apache Tomcat 10.0.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to jakarta.*
>
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes. Java EE applications designed for Tomcat 9 and earlier may be
> placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will
> automatically convert them to Jakarta EE and copy them to the webapps
> directory
>
> The notable changes compared to 10.0.18 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.32 to
>pick up Windows binaries built with OpenSSL 1.1.1n.
>
> - Improve logging of unknown HTTP/2 settings frames. Pull request by
>Thomas Hoffmann.
>
> - Add additional warnings if incompatible TLS configurations are used
>such as HTTP/2 with CLIENT-CERT authentication
>
> - Harden the class loader to provide a mitigation for CVE-2022-22965
>a Spring Framework vulnerability
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.20/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1369
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.20
> 2a46c651529a9d237b4d6beb1ef846922d949342
>
> The proposed 10.0.20 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.0.20 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 9.0.61

2022-03-31 Thread Rémy Maucherat
On Thu, Mar 31, 2022 at 4:58 PM  wrote:
>
> Rémy,
>
> Will the Spring Framework Zero Day result in moving to release 9.0.62, 
> surpassing 9.0.61 currently in vote?

Same as for 10.1, the most likely is that the 9.0.61 is cancelled.

Rémy

> Thanks,
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Infrastructure Engineer
> Asst Vice President
> He/His
>
> Middleware Product Engineering
> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
> This message may contain confidential and/or privileged information. If you 
> are not the addressee or authorized to receive this for the addressee, you 
> must not use, copy, disclose, or take any action based on this message or any 
> information herein. If you have received this message in error, please advise 
> the sender immediately by reply e-mail and delete this message. Thank you for 
> your cooperation.
>
>
> > -Original Message-
> > From: Rémy Maucherat 
> > Sent: Wednesday, March 30, 2022 3:22 AM
> > To: Tomcat Developers List 
> > Subject: [VOTE] Release Apache Tomcat 9.0.61
> >
> > The proposed Apache Tomcat 9.0.61 release is now available for voting.
> >
> > The notable changes compared to 9.0.60 are:
> >
> > - Fix a potential thread-safety issue that could cause HTTP/1.1 request
> >processing to pause, and potentially timeout, waiting for additional
> >data when the full request has been received.
> >
> > - Fix a regression introduced with 65757 bugfix which better identified
> >non request threads but which introduced a similar problem when user
> >code was doing sequential operations in a single thread.
> >
> > - When resolving methods in EL expressions that use beans and/or static
> >fields, ensure that any custom type conversion is considered when
> >identifying the method to call.
> >
> > Along with lots of other bug fixes and improvements.
> >
> > For full details, see the changelog:
> > https://urldefense.com/v3/__https://nightlies.apache.org/tomcat/tomcat-
> > 9.0.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!7XK-DbVirPj3r-
> > F7wfi6sKyGhYbedykficURS6hxf41RBWPgm_J3aM8LgZ-NVP4f6n0DAak$
> >
> > It can be obtained from:
> > https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/tomc
> > at/tomcat-9/v9.0.61/__;!!F9svGWnIaVPGSwU!7XK-DbVirPj3r-
> > F7wfi6sKyGhYbedykficURS6hxf41RBWPgm_J3aM8LgZ-NVP4fLrXOhN4$
> > The Maven staging repo is:
> > https://urldefense.com/v3/__https://repository.apache.org/content/reposi
> > tories/orgapachetomcat-1366__;!!F9svGWnIaVPGSwU!7XK-DbVirPj3r-
> > F7wfi6sKyGhYbedykficURS6hxf41RBWPgm_J3aM8LgZ-NVP4fYUTTyiA$
> > The tag is:
> > https://urldefense.com/v3/__https://github.com/apache/tomcat/tree/9.0.6
> > 1__;!!F9svGWnIaVPGSwU!7XK-DbVirPj3r-
> > F7wfi6sKyGhYbedykficURS6hxf41RBWPgm_J3aM8LgZ-NVP4fVDyFgoI$
> > 6c6432ac1416ed369f892b9ce76e10c7eb10b91c
> >
> > The proposed 9.0.61 release is:
> > [ ] Broken - do not release
> > [ ] Stable - go ahead and release as 9.0.61 (stable)
> >
> > Rémy
> >
> > -
> > 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



[VOTE] Release Apache Tomcat 9.0.62

2022-03-31 Thread Rémy Maucherat
The proposed Apache Tomcat 9.0.62 release is now available for voting.

The notable changes compared to 9.0.60 are:

- Update the packaged version of the Tomcat Native Library to 1.2.32 to
   pick up Windows binaries built with OpenSSL 1.1.1n.

- Improve logging of unknown HTTP/2 settings frames. Pull request by
   Thomas Hoffmann.

- Add additional warnings if incompatible TLS configurations are used
   such as HTTP/2 with CLIENT-CERT authentication

- Harden the class loader to provide a mitigation for CVE-2022-22965
   a Spring Framework vulnerability

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.62/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1368
The tag is:
https://github.com/apache/tomcat/tree/9.0.62
85113741042dcce9e9792bdbc3d498172bc31291

The proposed 9.0.62 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.62 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M14

2022-03-31 Thread Rémy Maucherat
On Thu, Mar 31, 2022 at 3:58 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.1.0-M14 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M12 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.32 to
>pick up Windows binaries built with OpenSSL 1.1.1n.
>
> - Improve logging of unknown HTTP/2 settings frames. Pull request by
>Thomas Hoffmann.
>
> - Update the JASPIC 2.0 API to Jakarta Authentication 3.0 (JASPIC was
>renamed for Jakarta EE 10)
>
> - Harden the class loader to provide a mitigation for CVE-2022-22965
>a Spring Framework vulnerability
>
> For full details, see the change log:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M14/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1367
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M14
> 02e84c839def0228475fad85d0b19abc2f70b03f
>
>
> The proposed 10.1.0-M14 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 10.1.0-M14 (alpha)

Rémy

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



Re: Re-rolling releases to pick up class loader hardening

2022-03-31 Thread Rémy Maucherat
On Thu, Mar 31, 2022 at 1:16 PM Mark Thomas  wrote:
>
> On 31/03/2022 11:48, Rémy Maucherat wrote:
> > On Thu, Mar 31, 2022 at 11:52 AM Mark Thomas  wrote:
> >>
> >> Hi all,
> >>
> >> My recent hardening fix to the class loader [1] provides mitigation for
> >> a current Spring vulnerability [2].
> >>
> >> While this is a Spring vulnerability, it may be the case for some users
> >> that updating Tomcat is an easier mitigation path that updating Spring.
> >> What are the community thoughts on cancelling the current releases,
> >> re-tagging and releasing reasonably quickly?
> >
> > Possibly ok but only if the new tag is "immediately" rather than "quickly".
>
> I could start 10.1.x and 10.0.x in the next couple of hours. I can also
> cover 8.5.x if Chris isn't available.

+1 then. If it is delayed, I will be in trouble ;)

Rémy

> Mark
>
>
> >
> > Rémy
> >
> >
> >> Mark
> >>
> >>
> >> [1]
> >> https://github.com/apache/tomcat/commit/1abcf3f4d741c824ae490009fe32ce300f10eddc
> >>
> >> [2]
> >> https://github.com/apache/tomcat/commit/1abcf3f4d741c824ae490009fe32ce300f10eddc
> >>
> >> -
> >> 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
>

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



Re: Re-rolling releases to pick up class loader hardening

2022-03-31 Thread Rémy Maucherat
On Thu, Mar 31, 2022 at 11:52 AM Mark Thomas  wrote:
>
> Hi all,
>
> My recent hardening fix to the class loader [1] provides mitigation for
> a current Spring vulnerability [2].
>
> While this is a Spring vulnerability, it may be the case for some users
> that updating Tomcat is an easier mitigation path that updating Spring.
> What are the community thoughts on cancelling the current releases,
> re-tagging and releasing reasonably quickly?

Possibly ok but only if the new tag is "immediately" rather than "quickly".

Rémy


> Mark
>
>
> [1]
> https://github.com/apache/tomcat/commit/1abcf3f4d741c824ae490009fe32ce300f10eddc
>
> [2]
> https://github.com/apache/tomcat/commit/1abcf3f4d741c824ae490009fe32ce300f10eddc
>
> -
> 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: [VOTE] Release Apache Tomcat 10.0.19

2022-03-31 Thread Rémy Maucherat
On Wed, Mar 30, 2022 at 1:50 AM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.0.19 release is now available for
> voting.
>
> Apache Tomcat 10.0.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to jakarta.*
>
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes. Java EE applications designed for Tomcat 9 and earlier may be
> placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will
> automatically convert them to Jakarta EE and copy them to the webapps
> directory
>
> The notable changes compared to 10.0.18 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.32 to
>pick up Windows binaries built with OpenSSL 1.1.1n.
>
> - Improve logging of unknown HTTP/2 settings frames. Pull request by
>Thomas Hoffmann.
>
> - Add additional warnings if incompatible TLS configurations are used
>such as HTTP/2 with CLIENT-CERT authentication
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.19/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1365
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.19
> 0b4fe866e5a4e06481e5019be9468e10790647ba
>
> The proposed 10.0.19 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.0.19 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M13

2022-03-31 Thread Rémy Maucherat
On Wed, Mar 30, 2022 at 1:06 AM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.1.0-M13 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M12 are:
>
> - Update the packaged version of the Tomcat Native Library to 1.2.32 to
>pick up Windows binaries built with OpenSSL 1.1.1n.
>
> - Improve logging of unknown HTTP/2 settings frames. Pull request by
>Thomas Hoffmann.
>
> - Update the JASPIC 2.0 API to Jakarta Authentication 3.0 (JASPIC was
>renamed for Jakarta EE 10)
>
> For full details, see the change log:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M13/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1364
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M13
> faa2582152d9dcbcb444700df340e10a85fc375f
>
>
> The proposed 10.1.0-M13 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 10.1.0-M13 (alpha)

Rémy

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



[VOTE] Release Apache Tomcat 9.0.61

2022-03-30 Thread Rémy Maucherat
The proposed Apache Tomcat 9.0.61 release is now available for voting.

The notable changes compared to 9.0.60 are:

- Fix a potential thread-safety issue that could cause HTTP/1.1 request
   processing to pause, and potentially timeout, waiting for additional
   data when the full request has been received.

- Fix a regression introduced with 65757 bugfix which better identified
   non request threads but which introduced a similar problem when user
   code was doing sequential operations in a single thread.

- When resolving methods in EL expressions that use beans and/or static
   fields, ensure that any custom type conversion is considered when
   identifying the method to call.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.61/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1366
The tag is:
https://github.com/apache/tomcat/tree/9.0.61
6c6432ac1416ed369f892b9ce76e10c7eb10b91c

The proposed 9.0.61 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.61 (stable)

Rémy

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



Re: [tomcat] 01/02: PR #487: Improve logging of unknown settings frames

2022-03-23 Thread Rémy Maucherat
On Wed, Mar 23, 2022 at 10:01 PM Christopher Schultz
 wrote:
>
> Rémy,
>
> On 3/23/22 16:10, r...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > remm pushed a commit to branch 10.0.x
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> > commit a82ddf0fc42c960f224e7d23eaa90df272de3559
> > Author: remm 
> > AuthorDate: Wed Mar 23 21:00:41 2022 +0100
> >
> >  PR #487: Improve logging of unknown settings frames
> >
> >  Pull request by Thomas Hoffmann.
> > ---
> >   java/org/apache/coyote/http2/ConnectionSettingsBase.java | 2 --
> >   java/org/apache/coyote/http2/Http2Parser.java| 7 ++-
> >   java/org/apache/coyote/http2/Http2UpgradeHandler.java| 7 ++-
> >   webapps/docs/changelog.xml   | 4 
> >   4 files changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/java/org/apache/coyote/http2/ConnectionSettingsBase.java 
> > b/java/org/apache/coyote/http2/ConnectionSettingsBase.java
> > index 042fb0c..ef4a200 100644
> > --- a/java/org/apache/coyote/http2/ConnectionSettingsBase.java
> > +++ b/java/org/apache/coyote/http2/ConnectionSettingsBase.java
> > @@ -88,8 +88,6 @@ abstract class ConnectionSettingsBase > Throwable> {
> >   break;
> >   case UNKNOWN:
> >   // Unrecognised. Ignore it.
> > -log.warn(sm.getString("connectionSettings.unknown",
> > -connectionId, setting, Long.toString(value)));
> >   return;
> >   }
>
>
> Was it intended to remove this log completely?

Yes, there is not enough information to do the logging there.

Rémy

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

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



Re: [tomcat] branch main updated: PR #487: Improve logging of unknown settings frames

2022-03-23 Thread Rémy Maucherat
On Wed, Mar 23, 2022 at 9:04 PM Mark Thomas  wrote:
>
> On 23/03/2022 20:01, r...@apache.org wrote:
>
> 
>
> > diff --git a/java/org/apache/coyote/http2/Http2Parser.java 
> > b/java/org/apache/coyote/http2/Http2Parser.java
> > index 5875e28..8c67d84 100644
> > --- a/java/org/apache/coyote/http2/Http2Parser.java
> > +++ b/java/org/apache/coyote/http2/Http2Parser.java
> > @@ -337,7 +337,12 @@ class Http2Parser {
> >   }
> >   int id = ByteUtil.getTwoBytes(setting, 0);
> >   long value = ByteUtil.getFourBytes(setting, 2);
> > -output.setting(Setting.valueOf(id), value);
> > +Setting key = Setting.valueOf(id);
> > +if (log.isDebugEnabled() && key == Setting.UNKNOWN) {
> > +log.warn(sm.getString("connectionSettings.unknown",
>
> The above two lines are inconsistent. The message is at WARN level so
> the isDebugEnabled() test is not appropriate.

Yes, I already spotted it and changed it back.

That was likely intentional and a bit sneaky ...

Rémy

> 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: Tomcat 8.5.78 (and other branches as well)

2022-03-22 Thread Rémy Maucherat
On Tue, Mar 22, 2022 at 5:11 PM Mark Thomas  wrote:
>
> FYI I'm aiming to tag 10.1.x and 10.0.x late Tuesday next week with a
> view to completing the VOTE on Saturday as I have other things on the
> first full week of April and finding time to do a release could be tricky.

+1

Rémy



Rémy

> Mark
>
>
> On 22/03/2022 13:56, Christopher Schultz wrote:
> > All,
> >
> > Given the fact that tcnative 1.2.32 was released to include a
> > freshly-patched, statically-linked openssl binary, I plan on rolling
> > 8.5.78 next Thursday, March 31st. (I would have done Friday but I don't
> > want any confusion over the use of April 1st as a day to announce
> > anything.) This will give Windows admins a chance to have a package they
> > can install without having to juggle a Tomcat release separately from a
> > tcnative release.
> >
> > I would like to take this opportunity to remind any Windows admins out
> > there that there is also a new binary release of Apache httpd available
> > from Apache Lounge[1] which includes all the latest CVEs reported
> > against httpd itself as well as OpenSSL. I would make that a priority if
> > I were you.
> >
> > -chris
> >
> > [1] https://www.apachelounge.com/download/
> >
> > -
> > 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: [tomcat] branch 10.0.x updated: Use a constant for the cipher suite

2022-03-17 Thread Rémy Maucherat
On Thu, Mar 17, 2022 at 3:01 PM  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> remm pushed a commit to branch 10.0.x
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/10.0.x by this push:
>  new 73bf00c  Use a constant for the cipher suite
> 73bf00c is described below
>
> commit 73bf00ca008b53dae8e95f75a8cdc0dd36c1fe2e
> Author: remm 
> AuthorDate: Thu Mar 17 14:56:44 2022 +0100
>
> Use a constant for the cipher suite
>
> This will allow skipping setting it when it is known to be useless
> (example: OpenSSL TLS 1.3, where it is best to leave the impl defaults).

Oops, cherry picking this and pushing gives:
remote: Internal Server Error
To github.com:apache/tomcat.git
 ! [remote rejected]   9.0.x -> 9.0.x (Internal Server Error)
error: failed to push some refs to 'github.com:apache/tomcat.git'

Sounds scary ...

Rémy

> ---
>  java/org/apache/tomcat/util/net/SSLHostConfig.java | 3 ++-
>  webapps/docs/changelog.xml | 9 +
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/java/org/apache/tomcat/util/net/SSLHostConfig.java 
> b/java/org/apache/tomcat/util/net/SSLHostConfig.java
> index 2c1c0c3..af60ecc 100644
> --- a/java/org/apache/tomcat/util/net/SSLHostConfig.java
> +++ b/java/org/apache/tomcat/util/net/SSLHostConfig.java
> @@ -54,6 +54,7 @@ public class SSLHostConfig implements Serializable {
>  // keys in Maps.
>  protected static final String DEFAULT_SSL_HOST_NAME = "_default_";
>  protected static final Set SSL_PROTO_ALL_SET = new HashSet<>();
> +public static final String DEFAULT_TLS_CIPHERS = 
> "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA";
>
>  static {
>  /* Default used if protocols are not configured, also used if
> @@ -95,7 +96,7 @@ public class SSLHostConfig implements Serializable {
>  private int certificateVerificationDepth = 10;
>  // Used to track if certificateVerificationDepth has been explicitly set
>  private boolean certificateVerificationDepthConfigured = false;
> -private String ciphers = 
> "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA";
> +private String ciphers = DEFAULT_TLS_CIPHERS;
>  private LinkedHashSet cipherList = null;
>  private List jsseCipherNames = null;
>  private boolean honorCipherOrder = false;
> diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
> index 34f2c8f..67f8bcb 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -131,6 +131,15 @@
>
>  
>
> +  
> +
> +  
> +Use a constant for the default TLS cipher suite. This will allow
> +skipping setting it in some cases (for example, it does not make
> +sense for OpenSSL TLS 1.3). (remm)
> +  
> +
> +  
>
>  
>
>
> -
> 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: [VOTE] Release Apache Tomcat Native 1.2.32

2022-03-17 Thread Rémy Maucherat
On Thu, Mar 17, 2022 at 9:48 AM Mark Thomas  wrote:
>
> Version 1.2.32 includes the following changes compared to 1.2.31
>
> - Updated recommended minimum OpenSSL to 1.1.1n and build windows
>binaries using that version
>
> - Fix release script so it works with the current git layout
>
> The proposed release artefacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 1.2.32 release is
>   [X] Stable, go ahead and release
>   [ ] Broken because of ...

Rémy

> Thanks,
>
> Mark
>
>
> [1]
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.32
> [2]
> https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=ee11afcb5bc3426b85525985461484222f609406
>
> -
> 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: svn propchange: r53085 - svn:log

2022-03-14 Thread Rémy Maucherat
On Mon, Mar 14, 2022 at 10:18 PM  wrote:
>
> Author: kkolinko
> Revision: 53085
> Modified property: svn:log
>
> Modified: svn:log at Mon Mar 14 21:17:54 2022
> --
> --- svn:log (original)
> +++ svn:log Mon Mar 14 21:17:54 2022
> @@ -0,0 +1 @@
> +Release Apache Tomcat 9.0.60

Thanks.

Rémy

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



[ANN] Apache Tomcat 9.0.60 available

2022-03-14 Thread Rémy Maucherat
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.60.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.60 is a bugfix and feature release. The notable
changes compared to 9.0.59 include:

- Fix a potential thread-safety issue that could cause HTTP/1.1 request
   processing to pause, and potentially timeout, waiting for additional
   data when the full request has been received.

- Fix a regression introduced with 65757 bugfix which better identified
   non request threads but which introduced a similar problem when user
   code was doing sequential operations in a single thread.

- When resolving methods in EL expressions that use beans and/or static
   fields, ensure that any custom type conversion is considered when
   identifying the method to call.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

2022-03-14 Thread Rémy Maucherat
On Sun, Mar 13, 2022 at 8:41 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 8.5.77 release is now available for voting.
>
> The notable changes compared to 8.5.76 are:
>
> - Fix a potential thread-safety issue that could cause HTTP/1.1 request
> processing to pause, and potentially timeout, waiting for additional
> data when the full request has been received.
>
> - Fix a regression introduced with 65757 bugfix which better identified
> non request threads but which introduced a similar problem when user
> code was doing sequential operations in a single thread.
>
> - When resolving methods in EL expressions that use beans and/or static
> fields, ensure that any custom type conversion is considered when
> identifying the method to call.
>
> Along with lots of other bug fixes and improvements.
>
> This is the second release of Tomcat 8.5 that has been built with Java
> 11 (in Java 7 mode) instead of Java 7. Please report any strangeness you
> may observe especially if you are running Tomcat 8.5 in an environment
> using Java < 11. We don't expect any issues, but understand that we
> cannot test all possible environmental configurations.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.77/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1363
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.77
> 3931695e564dd4dd1dbf029026e900b74992408c
>
> The proposed 8.5.77 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.76 (stable)

Rémy

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



[VOTE][RESULT] Release Apache Tomcat 9.0.60

2022-03-14 Thread Rémy Maucherat
The following votes were cast:

Binding:
+1: remm, markt, kkolinko, fschumacher

No other votes were cast. The vote therefore passes.

Thanks to everyone who contributed to this release.

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.0.18

2022-03-10 Thread Rémy Maucherat
On Wed, Mar 9, 2022 at 3:53 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.0.18 release is now available for
> voting.
>
> Apache Tomcat 10.0.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to jakarta.*
>
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes. Java EE applications designed for Tomcat 9 and earlier may be
> placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will
> automatically convert them to Jakarta EE and copy them to the webapps
> directory
>
> The notable changes compared to 10.0.17 are:
>
> - Fix a potential thread-safety issue that could cause HTTP/1.1 request
>processing to pause, and potentially timeout, waiting for additional
>data when the full request has been received.
>
> - Fix a regression introduced with 65757 bugfix which better identified
>non request threads but which introduced a similar problem when user
>code was doing sequential operations in a single thread.
>
> - When resolving methods in EL expressions that use beans and/or static
>fields, ensure that any custom type conversion is considered when
>identifying the method to call.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.18/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1361
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.18
> 70f59e8328621e58b9493c119f05a2e57f597a1c
>
> The proposed 10.0.18 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.0.18 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M12

2022-03-10 Thread Rémy Maucherat
On Wed, Mar 9, 2022 at 2:59 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.1.0-M12 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M11 are:
>
> - Fix a potential thread-safety issue that could cause HTTP/1.1 request
>processing to pause, and potentially timeout, waiting for additional
>data when the full request has been received.
>
> - Fix a regression introduced with 65757 bugfix which better identified
>non request threads but which introduced a similar problem when user
>code was doing sequential operations in a single thread.
>
> - When resolving methods in EL expressions that use beans and/or static
>fields, ensure that any custom type conversion is considered when
>identifying the method to call.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M12/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1360
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M12
> d08498a3cefa7206bad791acf019455794f865ea
>
>
> The proposed 10.1.0-M12 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 10.1.0-M12 (alpha)

Rémy

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



[VOTE] Release Apache Tomcat 9.0.60

2022-03-09 Thread Rémy Maucherat
The proposed Apache Tomcat 9.0.60 release is now available for voting.

The notable changes compared to 9.0.59 are:

- Fix a potential thread-safety issue that could cause HTTP/1.1 request
   processing to pause, and potentially timeout, waiting for additional
   data when the full request has been received.

- Fix a regression introduced with 65757 bugfix which better identified
   non request threads but which introduced a similar problem when user
   code was doing sequential operations in a single thread.

- When resolving methods in EL expressions that use beans and/or static
   fields, ensure that any custom type conversion is considered when
   identifying the method to call.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.60/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1362
The tag is:
https://github.com/apache/tomcat/tree/9.0.60
235730aed454e8d3619109f2c563587ff722e69d

The proposed 9.0.60 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.60 (stable)

Rémy

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



Re: March releases?

2022-03-08 Thread Rémy Maucherat
On Tue, Mar 8, 2022 at 10:25 PM Mark Thomas  wrote:
>
> Hi all,
>
> I know I suggested skipping the March releases but I'd like to revisit
> that in light of two things.
>
> 1. The concurrency issue I fixed earlier today. [1]
> It has been present for a long time and we haven't had any bug reports.
> However, it just looks like a random timeout so users might not report it.
> My main motivation is that a customer at $dayjob is affected by this so
> I'd like to get them onto a proper release rather than the snapshot they
> are currently using.
>
> 2. The fix for the regression caused by BZ 65757 [2]
> No hard evidence for this one, just a general uneasiness about
> regressions in general.
>
> So, thoughts on a set of releases for March?

No problem, doing a release to fix things is never a bad thing.

Rémy

> Mark
>
>
> [1]
> https://github.com/apache/tomcat/commit/a60528617e512330f91553e925d50a6c34016dd4
>
> [2]
> https://github.com/apache/tomcat/commit/2739565fa5286623e8bb31823770595de14b6370
>
> -
> 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



[ANN] Apache Tomcat 9.0.59 available

2022-02-28 Thread Rémy Maucherat
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.59.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.59 is a bugfix and feature release. The notable
changes compared to 9.0.58 include:

- Add support for additional user attributes to TomcatPrincipal and
   GenericPrincipal

- Correct a regression in the fix for 65454 that meant that
   minSpareThreads and maxThreads settings were ignored when the
   Connector used an internal executor

- Improve the detection of the Linux duplicate accept bug and reduce
   (hopefully avoid) instances of false positives.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



Re: Jakarta EE 10 update

2022-02-28 Thread Rémy Maucherat
On Wed, Feb 23, 2022 at 8:01 PM Mark Thomas  wrote:
>
> Just a quick update.
>
> Current planned release date is ~March 2022.
>
> Tomcat 10.1.x currently passes the latest builds of the Servlet, JSP, EL
> and WebSocket TCK with the exception of the one Servlet test we expected
> to fail.

Ok, so the next "monthly" release could be 10.1.0 then.

About that context path problem, do we still keep it as is or do we
try to add a bundled workaround ?

Rémy

> Overall, things are looking good.
>
> 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



[VOTE][RESULT] Release Apache Tomcat 9.0.59

2022-02-28 Thread Rémy Maucherat
The following votes were cast:

Binding:
+1: remm, mturk, csutherl, jclere

No other votes were cast. The vote therefore passes.

Thanks to everyone who contributed to this release.

Rémy

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

2022-02-24 Thread Rémy Maucherat
On Wed, Feb 23, 2022 at 7:57 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 8.5.76 release is now available for voting.
>
> The notable changes compared to 8.5.75 are:
>
> - Correct a regression in the fix for 65454 that meant that
> minSpareThreads and maxThreads settings were ignored when the
> Connector used an internal executor
>
> - Improve the detection of the Linux duplicate accept bug and reduce
> (hopefully avoid) instances of false positives.
>
> - Back-port fixes for BZ 65408 to refactor socket-close operations
>to improve resilience when objects are re-used by applications.
>
> Along with lots of other bug fixes and improvements.
>
> This is the first release of Tomcat 8.5 that has been built with Java 11
> (in Java 7 mode) instead of Java 7. Please report any strangeness you
> may observe especially if you are running Tomcat 8.5 in an environment
> using Java < 11. We don't expect any issues, but understand that we
> cannot test all possible environmental configurations.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.76/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1359
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.76
> 67928399251771271d95a1805001ba00e650adce
>
> The proposed 8.5.76 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.76 (stable)

Tested with Java 11.

Rémy

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



Re: Tagging 8.5.x

2022-02-23 Thread Rémy Maucherat
On Wed, Feb 23, 2022 at 4:07 PM Mark Thomas  wrote:
>
> Hi all,
>
> The February release round is running rather late. Therefore, I'd like
> to get 8.5.x tagged and the RC uploaded today. Unless there are
> objections I'm intending to start this in ~3 hours time.

+1

> On a related topic, DigiCert have confirmed that they broke the REST API
> that JSign depends on. They did provide a workaround so I'll try and
> look at a patch for JSign once the 8.5.x RC is done.

Rémy

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



Re: [VOTE] Release Apache Tomcat 9.0.59

2022-02-22 Thread Rémy Maucherat
On Mon, Feb 21, 2022 at 10:20 PM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.59 release is now available for voting.
>
> The notable changes compared to 9.0.58 are:
>
> - Add support for additional user attributes to TomcatPrincipal and
>GenericPrincipal
>
> - Correct a regression in the fix for 65454 that meant that
>minSpareThreads and maxThreads settings were ignored when the
>Connector used an internal executor
>
> - Improve the detection of the Linux duplicate accept bug and reduce
>(hopefully avoid) instances of false positives.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.59/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1358
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.59
> 020f955044c1f9b512ee3da477eaa018da87e71a
>
> The proposed 9.0.59 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.59 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.0.17

2022-02-22 Thread Rémy Maucherat
On Mon, Feb 21, 2022 at 8:58 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.0.17 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to jakarta.*
>
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes. Java EE applications designed for Tomcat 9 and earlier may be
> placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will
> automatically convert them to Jakarta EE and copy them to the webapps
> directory
>
> The notable changes compared to 10.0.16 are:
>
> - Add support for additional user attributes to TomcatPrincipal and
>GenericPrincipal
>
> - Correct a regression in the fix for 65454 that meant that
>minSpareThreads and maxThreads settings were ignored when the
>Connector used an internal executor
>
> - Improve the detection of the Linux duplicate accept bug and reduce
>(hopefully avoid) instances of false positives.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.17/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1357
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.17
> 138879e330cd7133dacfe4a319e2fc822b1e9257
>
> The proposed 10.0.17 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.0.17 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M11

2022-02-22 Thread Rémy Maucherat
On Mon, Feb 21, 2022 at 7:42 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.1.0-M11 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M10 are:
>
> - Add support for additional user attributes to TomcatPrincipal and
>GenericPrincipal
>
> - Correct a regression in the fix for 65454 that meant that
>minSpareThreads and maxThreads settings were ignored when the
>Connector used an internal executor
>
> - Improve the detection of the Linux duplicate accept bug and reduce
>(hopefully avoid) instances of false positives.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M11/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1356
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M11
> 049799677ba307378a256621bb1a7b03f597571c
>
>
> The proposed 10.1.0-M11 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 10.1.0-M11 (alpha)

Any Jakarta news these days ?

Rémy

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



[VOTE] Release Apache Tomcat 9.0.59

2022-02-21 Thread Rémy Maucherat
The proposed Apache Tomcat 9.0.59 release is now available for voting.

The notable changes compared to 9.0.58 are:

- Add support for additional user attributes to TomcatPrincipal and
   GenericPrincipal

- Correct a regression in the fix for 65454 that meant that
   minSpareThreads and maxThreads settings were ignored when the
   Connector used an internal executor

- Improve the detection of the Linux duplicate accept bug and reduce
   (hopefully avoid) instances of false positives.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.59/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1358
The tag is:
https://github.com/apache/tomcat/tree/9.0.59
020f955044c1f9b512ee3da477eaa018da87e71a

The proposed 9.0.59 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.59 (stable)

Rémy

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



Re: ULRStreamHandlerFactory proposal

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

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

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

Rémy

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

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



Re: [tomcat] branch main updated: Add support for additional user attributes in TomcatPrincipal

2022-02-13 Thread Rémy Maucherat
On Thu, Feb 10, 2022 at 1:01 PM Rémy Maucherat  wrote:
>
> On Tue, Feb 8, 2022 at 2:13 PM  wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > michaelo pushed a commit to branch main
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> >
> > The following commit(s) were added to refs/heads/main by this push:
> >  new c3edf43  Add support for additional user attributes in 
> > TomcatPrincipal
> > c3edf43 is described below
> >
> > commit c3edf437da20af0f11edc0ad6d893399b01e6287
> > Author: Carsten Klein 
> > AuthorDate: Wed Jan 12 15:06:42 2022 +0100
> >
> > Add support for additional user attributes in TomcatPrincipal
> >
> > This closes #463
>
> -1 (veto)

The javadoc that has been agreed upon has been added (the wording can
be refined later), so the veto regarding this commit is addressed and
thus dropped.

Rémy

> Unfortunately, the more I think about this, the more it seems wrong to me.
>
> This makes the realm an object store, which is not a good idea at all,
> as it will:
> - Encourage all sorts of bad hacks and practices for users
> - Force us to gradually add more and more features to this generic
> object store feature
> - Have massive discrepancies between realms, with the users trying to
> figure out pros and cons between realms
> - Is a proprietary feature which ties up users to Tomcat
>
> More importantly: application data storage should remain the
> prerogative of the application, Tomcat should not attempt to do that.
> The only thing Tomcat should provide is a principal name, which is
> then the primary key for the third party object store. There is zero
> reason to integrate this within the realm or principal API. It also
> feels like it can never be complete or appropriate.
>
> I apologize for having to do this, after initially helping out with
> this PR, but this is one of those situations where the more I look
> about it, the worse I feel about it.
>
> Rémy
>
> > ---
> >  java/org/apache/catalina/TomcatPrincipal.java  | 28 +
> >  .../apache/catalina/realm/GenericPrincipal.java| 46 
> > ++
> >  java/org/apache/catalina/realm/JNDIRealm.java  |  2 +-
> >  webapps/docs/changelog.xml |  5 +++
> >  webapps/examples/jsp/security/protected/index.jsp  | 44 
> > +
> >  5 files changed, 117 insertions(+), 8 deletions(-)
> >
> > diff --git a/java/org/apache/catalina/TomcatPrincipal.java 
> > b/java/org/apache/catalina/TomcatPrincipal.java
> > index 83f9035..1e3d9f6 100644
> > --- a/java/org/apache/catalina/TomcatPrincipal.java
> > +++ b/java/org/apache/catalina/TomcatPrincipal.java
> > @@ -17,6 +17,8 @@
> >  package org.apache.catalina;
> >
> >  import java.security.Principal;
> > +import java.util.Collections;
> > +import java.util.Enumeration;
> >
> >  import org.ietf.jgss.GSSCredential;
> >
> > @@ -47,4 +49,30 @@ public interface TomcatPrincipal extends Principal {
> >   *   exception to LoginContext
> >   */
> >  void logout() throws Exception;
> > +
> > +/**
> > + * Returns the value of the named attribute as an Object, 
> > or
> > + * null if no attribute of the given name exists, or if
> > + * null has been specified as the attribute's name.
> > + * 
> > + * Only the servlet container may set attributes to make available 
> > custom
> > + * information about a Principal or the user it represents.
> > + *
> > + * @param name a String specifying the name of the 
> > attribute
> > + * @return an Object containing the value of the 
> > attribute, or
> > + * null if the attribute does not exist, or if
> > + * null has been specified as the attribute's name
> > + */
> > +Object getAttribute(String name);
> > +
> > +/**
> > + * Returns an Enumeration containing the names of the
> > + * attributes available to this Principal. This method returns an empty
> > + * Enumeration if the Principal has no attributes 
> > available to
> > + * it.
> > + *
> > + * @return an Enumeration of strings containing the names 
> > of
> > + * the Principal's attributes
> > + */
> > +Enumeration getAttributeNames();
> >  }
> > diff --git a/java/org/apache/catalina/realm/GenericPrincipal.java 
> > b/java/org/apache/catalina/realm/GenericPrincip

Re: Add support for additional user attributes in TomcatPrincipal

2022-02-11 Thread Rémy Maucherat
On Fri, Feb 11, 2022 at 11:17 AM Carsten Klein  wrote:
>
>
>
>
> On Fri, Feb 11, 2022 at 10:10 AM Rémy Maucherat wrote
> >
> > If we get there, it could include mail addresses, ssn, payment info,
> > user profile pictures (binary), etc etc.
> > Also one thing I don't get now is how this became Object
> > getAttribute(String name) instead of String getAttribute(String name)
> > ? The legitimate examples you gave are text, not binary objects.
> >
> > Ultimately, all of this is still application data ... Moving it in the
> > Tomcat realm creates a proprietary behavior, the application is no
> > longer portable while at the same time the benefit is minimal (saving
> > a query ?). When logging in, the app should pull all the metadata it
> > needs, store it in the session.
> >
> Yes, it could be that much metadata, so what? And yes, it's all
> application data. But that must not be something negative. You may say,
> this is up to the application but, isn't it convenient if the realm does
> it for you? Tomcat's Request (e.g. HTTPServletRequest) returns all data
> POSTed from a client; all that data may be application specific data as
> well. Nobody cares...
>
> Again, it's not about saving one query while logging in a user. It's
> primarily about
>
> 1. not needing to configure an extra connection to the user database
> 2. not needing much custom code an knowledge/skills of the user database
> (SQL, LDAP etc.)
> 3. getting extra attributes from Tomcat "for free" with 'any' Realm
> simply by configuring a list of fields uniformly

Maybe you should consider some bespoke technology like for example
using JPA instead ? Or any other object persistence framework or
object database obviously.

> As you are correctly saying, point 1. is not that complicated for
> DataSourceRealm, as there is a JDBC pool around. Nevertheless, the
> application still needs to know the name of the connection (e. g.
> "jdbc/userdatabase") and the name of the user table, the column
> containing the logon name (what Principal.getName() returns) and the
> extra columns to query.
>
> With my solution, all that configuration is "hidden" in the Realm's
> configuration. The only new thing is the "userAttributes" config
> attribute. No duplicated configuration is required.
>
> What do you mean with 'proprietary behavior'? Why shouldn't the
> application be no longer portable? The Realm's configuration always
> contains any access data (JNDI resource names, URLs and passwords in
> case of JNDIRealm), so it wasn't ever portable at all. If you think
> about moving the application between different servers on the same site
> (targeting the same user database), the new "userAttributes" should work
> from any Tomcat server you use.

Tomcat is a Servlet container implementing the EE specifications. You
are supposed to be able to take your webapp and be able to run it
unchanged on, for example, Wildfly (with just configuration for the
DataSource resource in the JNDI environment). This, however, is a
proprietary feature that makes the webapp non portable as other
containers don't have TomcatPrincipal with attributes pulled from some
location. So how would the same app retrieve the data on Wildfly ?

> Moving between different user databases is also much simpler, since the
> whole configuration is centralized at the Realm.
>
> Why do I store Object and not String attributes? Because I can... When
> querying a JDBC database or a LDAP server dynamically, you must expect
> various different types being returned. We could add a rule, that all
> must be Strings or we call the toString() method on each value. But why?

Because not having that limitation opens the possibility of having to
implement automatic type mapping. Coincidentally, Michael stated he
wanted List to be handled. A String is better from the Tomcat
perspective because the implementation provided can be simple (then,
let's say it's really a binary, it has to be encoded maybe with base64
- extended custom realm here - and then handled by the application).

>
> >
> > Yes, well, unfortunately, due to more background thinking ...
> > The purpose of the UserDatabase is to be able to write, so given the
> > API it is an object database at this point.
> >
>
> In my recent implementation, the AbstractUser got a
>
> /**
>   * Additional attributes of this user.
>   */
> protected Map attributes = new HashMap<>();
>
> so, the UserDatabase does not store Object typed attributes, but only
> Strings (since XML attributes are strings only). So, I don't understand
> why you consider it an object database.

So it's fine to replace Object with String then. More seriously, this
means

Re: Re: [tomcat] branch main updated: Add support for additional user, attributes in TomcatPrincipal

2022-02-11 Thread Rémy Maucherat
On Fri, Feb 11, 2022 at 10:47 AM Michael Osipov  wrote:
>
> Rémy,
>
> really, I don't understand your work attitude. Carsten contacted us on
> the mailing list before providing the PR. Then he provided the PR. It
> was open for EIGHT months. We discussed this in and out, with you and
> Mark. Everyone expressed the conditions he is willing to accept the PR.
> I have even asked Carsten to break up the PR to please you. The purpose
> of RTC/PR is to express your opinion BEFORE it gets merged to avoid
> post-mortem discussions like this. You expressed your conditions and now
> you object? This is absolutely not fair and unprofessional.

I apologized for this already. I am really sorry about this but
background thinking led to different conclusions over time.

> I cannot share your further explanations as well. The Realm *is* already
> an object store. Principal name and roles are attributes on that object,
> so is password. Without this possibility you have the following problems:

That statement is just weird. The realm stores credentials associated
with a principal name, as well as a list of roles (other names)
associated with that name. That's it. An object store can store
objects (like if there is a get/setAttribute that deals with Object -
and that's my problem now, as it turns out ...).

> * You cannot abstract from the persistence layer in your application
> code, at worst you need to double code for retrieval
> * You double access time since you need to query the principal store
> again. A performance penalty in a stateless application, e.g. APIs
> * You maybe even not have access to the realm. Consider the identity
> provider gives you some form of token containing the attributes which
> you CANNOT retreive yourself. How to solve? You can't.

I don't believe the penalty exists for a DataSource backend. Most
likely for LDAP. Either way, the application is now non portable.
Given that the benefit for DataSource does not seem large, this simply
sounds bad in that case. For LDAP, it sounds like a tradeoff.

> No one is aiming here for an ORM layer.

One of my points is that this is really far from obvious in the API,
so it needs a round of javadoc tightening up.

Rémy

>
>
> Mark,
>
> you have even assisted on how to backport to previous versions and
> object somewhat as well? I don't understand that.
>
>
>  From my PoV Carsten did everything we requested over a very long period
> of time.
>
> M

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



Re: Add support for additional user attributes in TomcatPrincipal

2022-02-11 Thread Rémy Maucherat
On Fri, Feb 11, 2022 at 8:10 AM Carsten Klein  wrote:
>
> Hello Rémy, Mark and Michael,
>
> I'm new to the dev list and did not get your recent mails and didn't
> figure out how to get them in order to answer. So, I decided to start a
> new thread (sorry for that).
>
> I guess, having those attributes with the Principal (aka Principal
> metadata) does not make the Principal a data storage. For my mind, even
> the Principal's getName() returns kind of metadata, since an application
> typically does not really need the logged on user's name in order to
> function properly. Much more important are the user's roles, for example.
>
> So, the new read-only(!) attributes map is just a way of dynamically
> adding more of such metadata fields. Another way would be to add a
> getUserDisplayName() and a new Realm config attribute
> 'userDisplayNameCol' (e.g. for the DataSourceRealm), and maybe a
> getUserMailAddress() method later. However, that's not flexible at all
> and many requests from people to extend this scheme may be the result.

If we get there, it could include mail addresses, ssn, payment info,
user profile pictures (binary), etc etc.
Also one thing I don't get now is how this became Object
getAttribute(String name) instead of String getAttribute(String name)
? The legitimate examples you gave are text, not binary objects.

Ultimately, all of this is still application data ... Moving it in the
Tomcat realm creates a proprietary behavior, the application is no
longer portable while at the same time the benefit is minimal (saving
a query ?). When logging in, the app should pull all the metadata it
needs, store it in the session.

> So, the dynamic attributes map is the better choice, right? As long as
> it remains read-only, also no one can abuse the Principal as data
> storage. Also, there is really no need to ever request that, since an
> application already has a fully featured data storage around: the
> Session's attributes list. It is primarily intended for exactly that:
> storing the application's data. So, you could always deny any upcoming
> PRs adding write support to the Principal's attributes by referring to
> the Session's attributes map.
>
> Providing such metadata through the Principal is new and was not done
> before. However, since, more or less, it's just an extension to the
> already available getName() method, I guess, it's a quite good idea.
>
> In the Javadoc, of course, we could emphasize more, that this attributes
> map is intentionally read-only and will never be writable.
>
> Michael-o and I agreed on having individual PRs for the three parts of
> the initial enhancement (TomcatPrincipal/GenericPrincipal,
> DataSourceRealm, JNDIRealm). So, I will provide a third PR for the
> JNDIRealm after the DataSourceRealm has been merged.
>
> @Rémy: That was the deal/agreement. We do not touch UserDatabaseRealm
> and you do not vote against DataSourceRealm and JNDIRealm.

Yes, well, unfortunately, due to more background thinking ...
The purpose of the UserDatabase is to be able to write, so given the
API it is an object database at this point.

> @Remy: Maybe you would feel better about this, if we use a completely
> different approach?
>
> We could use the Realm for technically querying those attributes, but
> provide them to the application through the Session's attributes map?
>
> We could either put each single attribute directly into the Session's
> attributes using a prefixed name like "userAttribute.user_display_name",
> or we could add a UserAttributesStore instance (would be a new Tomcat
> specific class) under a "userAttributes" name, which has
> getAttribute(String name) and getAttributeNames() methods.
>
> However, I guess, implementing this approach is a bit more complicated
> than the current one.

Ok, but ... Your actual use case is the DataSourceRealm, which uses a
DataSource. That DataSource is a JNDI resource which is also available
to the application. Getting a connection from the pool is not
expensive at all, and running an extra query from a prepared statement
is just that. If more state is needed (I believe that will always be
the case), then the difference becomes minimal. Also, the whole data
layout is in the hands of the developer, who then chooses to abuse the
realm backend. So overall in that case, all that you mention is still
best done in the application, replacing the API with something
different (like storing in the session) does not change that and this
is simply about moving a small piece of code from the application to
the container.

Although I heavily changed my mind on the rest, JNDI/LDAP always
looked to me like the legitimate use case. There's indeed metadata in
there. It could be more difficult to get to it from the app. Maybe
it's less scalable than a DB, and there's no shared connection pool
with the app. So it's always going to be significantly less efficient
to get them from the application.

Ok that there's an agreement on javadoc clarifications 

Re: Running unit tests with JVMs < 11

2022-02-10 Thread Rémy Maucherat
On Thu, Feb 10, 2022 at 4:25 PM Rainer Jung  wrote:
>
> Am 10.02.2022 um 14:41 schrieb Rémy Maucherat:
> > On Thu, Feb 10, 2022 at 2:11 PM Mark Thomas  wrote:
> >>
> >> On 09/02/2022 14:04, Rainer Jung wrote:
> >>> Hi all,
> >>>
> >>> I wonder how important it is to be able to run the unit tests for TC
> >>> 8.5-10.0 with JVM versions 8 or even 7 (TC 8.5).
> >>>
> >>> The unconditional addition of unit test jvmargs "--add-opens=..." in
> >>> 2b6e19e971a980e38bcd30f05c554d9b798666c0 (TC 10, backported) means, we
> >>> can no longer run the tests with Java 8 or even 7.
> >>>
> >>> If I remove those jvmargs from build.xml, I run into a second problem
> >>> when testing TC 8.5 with Java 7. In
> >>> 014f4746176c7f27cda7c04b2c6036a539c385ff EasyMock was updated from 3.x
> >>> to 4.x, which needs Java 8 to run. Several tests fail with
> >>> UnsupportedClassVersionError in a few EasyMock classes.
> >>>
> >>> I can work around all of these myself for running the tests here, but I
> >>> wonder, what kind of setup for testing we want to support out-of-the box.
> >>>
> >>> Note that by reintroducing the previous compatibility trick for jvmargs
> >>> (TC 8.5, 9 and 10) and using the old EasyMock branch for TC 8.5 we could
> >>> still build and test with Java 11, but would also allow testing on the
> >>> other target Java versions we support.
> >>>
> >>> WDYT?
> >>
> >> I've been thinking about this since I read this yesterday.
> >>
> >> I like that the move to Java 11 allowed us to reduce the differences
> >> between the build scripts.
> >
> > +1
> >
> >> So the decision is: Is the benefit of being able to test with older Java
> >> versions worth the differences this would re-introduce?
> >>
> >> We don't test the JreCompat code so there aren't any Java version
> >> specific tests. So what do we gain by testing on Java 7 / Java 8? I can
> >> think of a few things:
> >> - that we really have coded to the correct Java version
> >> - that the code runs as expected on that Java version
>
> For example TLS behavior. There are functionalities that have the same
> API in different Java versions, but implementations provide different
> behavior.
>
> >> Both of those things are more testing Java than testing Tomcat but I can
> >> see that there is some benefit - especially if one is concerned about
> >> the possibility of the code behaving differently on Java 7/8 compared to
> >> Java 11.
> >
> > It is a good point that this is about testing Java (the bytecode
> > produced should target Java 8 exclusively - talking about Tomcat 9,
> > for example -, and the behavior of the API should be the same; if
> > either becomes false, then this is actually a Java bug).
>
> Concerning the same API behavior, wouldn't changes in TLS support
> qualify as such a change which is not a bug? Of course, most of the time
> Tomcat would be agnostic in itself to such changes, but I wouldn't be so
> sure that we would not every now and then find a relevant difference via
> the unit tests.
>
> > To be honest, I only partially trust that "release" feature right now.
> > Although it seems to work, it might simply need time to get used to
> > the concept ! I did point out the testsuite problem when this was
> > initially discussed. And I understand the lack of trust if Tomcat is
> > simply not tested on Java 8 (or 7, cough; let's pretend it is really
> > tested ;) ) before release.
> >
> > Instead of completely reverting to the previous properties hack and
> > reintroducing differences between branches, I would simply advocate
> > moving the offending values to hardcoded property values in build.xml
> > (which can then be replaced by Java 8 compatible placeholder values in
> > your own build.properties - same idea than for the dependencies which
> > can be replaced by Java 8 compatible ones).
>
> Sounds like a reasonable compromise. If we would find over time more
> reasons to actually run the tests, would it be easy to define JVM
> version specific build.properties lines on CI nodes? No idea, whether we
> already overwrite build properties on CI.

I added the workaround, in build.properties, you can add:
opens.javalang=-Dtest10=1
opens.javaio=-Dtest11=1
opens.sunrmi=-Dtest12=1
opens.javautil=-Dtest13=1
opens.javautilconcurrent=-Dte

Re: Running unit tests with JVMs < 11

2022-02-10 Thread Rémy Maucherat
On Thu, Feb 10, 2022 at 4:25 PM Rainer Jung  wrote:
>
> Am 10.02.2022 um 14:41 schrieb Rémy Maucherat:
> > On Thu, Feb 10, 2022 at 2:11 PM Mark Thomas  wrote:
> >>
> >> On 09/02/2022 14:04, Rainer Jung wrote:
> >>> Hi all,
> >>>
> >>> I wonder how important it is to be able to run the unit tests for TC
> >>> 8.5-10.0 with JVM versions 8 or even 7 (TC 8.5).
> >>>
> >>> The unconditional addition of unit test jvmargs "--add-opens=..." in
> >>> 2b6e19e971a980e38bcd30f05c554d9b798666c0 (TC 10, backported) means, we
> >>> can no longer run the tests with Java 8 or even 7.
> >>>
> >>> If I remove those jvmargs from build.xml, I run into a second problem
> >>> when testing TC 8.5 with Java 7. In
> >>> 014f4746176c7f27cda7c04b2c6036a539c385ff EasyMock was updated from 3.x
> >>> to 4.x, which needs Java 8 to run. Several tests fail with
> >>> UnsupportedClassVersionError in a few EasyMock classes.
> >>>
> >>> I can work around all of these myself for running the tests here, but I
> >>> wonder, what kind of setup for testing we want to support out-of-the box.
> >>>
> >>> Note that by reintroducing the previous compatibility trick for jvmargs
> >>> (TC 8.5, 9 and 10) and using the old EasyMock branch for TC 8.5 we could
> >>> still build and test with Java 11, but would also allow testing on the
> >>> other target Java versions we support.
> >>>
> >>> WDYT?
> >>
> >> I've been thinking about this since I read this yesterday.
> >>
> >> I like that the move to Java 11 allowed us to reduce the differences
> >> between the build scripts.
> >
> > +1
> >
> >> So the decision is: Is the benefit of being able to test with older Java
> >> versions worth the differences this would re-introduce?
> >>
> >> We don't test the JreCompat code so there aren't any Java version
> >> specific tests. So what do we gain by testing on Java 7 / Java 8? I can
> >> think of a few things:
> >> - that we really have coded to the correct Java version
> >> - that the code runs as expected on that Java version
>
> For example TLS behavior. There are functionalities that have the same
> API in different Java versions, but implementations provide different
> behavior.
>
> >> Both of those things are more testing Java than testing Tomcat but I can
> >> see that there is some benefit - especially if one is concerned about
> >> the possibility of the code behaving differently on Java 7/8 compared to
> >> Java 11.
> >
> > It is a good point that this is about testing Java (the bytecode
> > produced should target Java 8 exclusively - talking about Tomcat 9,
> > for example -, and the behavior of the API should be the same; if
> > either becomes false, then this is actually a Java bug).
>
> Concerning the same API behavior, wouldn't changes in TLS support
> qualify as such a change which is not a bug? Of course, most of the time
> Tomcat would be agnostic in itself to such changes, but I wouldn't be so
> sure that we would not every now and then find a relevant difference via
> the unit tests.

I believe the TLS impl in Java 8 has to remain compatible *and*
functional, or it's a bug. If suddenly no clients can connect to it,
then Oracle will have to fix it.
For Java 7, it will be EOL in 6 months, so it's not looking very good.
If/when it becomes less functional, we cannot do anything about it.

> > To be honest, I only partially trust that "release" feature right now.
> > Although it seems to work, it might simply need time to get used to
> > the concept ! I did point out the testsuite problem when this was
> > initially discussed. And I understand the lack of trust if Tomcat is
> > simply not tested on Java 8 (or 7, cough; let's pretend it is really
> > tested ;) ) before release.
> >
> > Instead of completely reverting to the previous properties hack and
> > reintroducing differences between branches, I would simply advocate
> > moving the offending values to hardcoded property values in build.xml
> > (which can then be replaced by Java 8 compatible placeholder values in
> > your own build.properties - same idea than for the dependencies which
> > can be replaced by Java 8 compatible ones).
>
> Sounds like a reasonable compromise. If we would find over time more
> reasons to actually run the tests, would it be easy to define JVM
> version specific build.properties lines on CI nodes? No i

Re: [tomcat] branch main updated: Add support for additional user attributes in TomcatPrincipal

2022-02-10 Thread Rémy Maucherat
On Thu, Feb 10, 2022 at 2:48 PM Mark Thomas  wrote:
>
> On 10/02/2022 12:01, Rémy Maucherat wrote:
> > On Tue, Feb 8, 2022 at 2:13 PM  wrote:
> >>
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> michaelo pushed a commit to branch main
> >> in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >>
> >>
> >> The following commit(s) were added to refs/heads/main by this push:
> >>   new c3edf43  Add support for additional user attributes in 
> >> TomcatPrincipal
> >> c3edf43 is described below
> >>
> >> commit c3edf437da20af0f11edc0ad6d893399b01e6287
> >> Author: Carsten Klein 
> >> AuthorDate: Wed Jan 12 15:06:42 2022 +0100
> >>
> >>  Add support for additional user attributes in TomcatPrincipal
> >>
> >>  This closes #463
> >
> > -1 (veto)
> >
> > Unfortunately, the more I think about this, the more it seems wrong to me.
>
> ACK. I won't tag until this has been reverted or you retract the veto.
>
> I will note that if I get to the point where I am ready to tag and this
> is the only issue remaining to resolve I will revert the change prior to
> the tag - although I'd prefer that michaelo did that before then.
>
> > This makes the realm an object store, which is not a good idea at all,
> > as it will:
> > - Encourage all sorts of bad hacks and practices for users
> > - Force us to gradually add more and more features to this generic
> > object store feature
> > - Have massive discrepancies between realms, with the users trying to
> > figure out pros and cons between realms
> > - Is a proprietary feature which ties up users to Tomcat
>
> Just trying to understand the concern at this point.
>
> You think the risk is that developers will push data in the Realm and
> then access from the authenticated principal?

This will seem convenient. If building an e-commerce thingie, you
could imagine storing payment info, all misc info, shopping cart. The
only thing preventing this is that there is no setAttribute(String
name, Object value), but what if someone comes along with a PR later ?
Is that a "no" then ? Why would this be more a "no" than for this one
?
This is clearly my concern now [following lingering thoughts about how
this could be (ab)used]. Again I would like to apologize for taking so
long until reaching this position, I know this wastes a lot of time
... My wider concerns were initially triggered when there was suddenly
some intent to add the feature to the UserDatabase (which is a R/W
database for users, so there the feature clearly becomes general
object storage - even though the PR only contained a mock impl).

> > More importantly: application data storage should remain the
> > prerogative of the application, Tomcat should not attempt to do that.
> > The only thing Tomcat should provide is a principal name, which is
> > then the primary key for the third party object store. There is zero
> > reason to integrate this within the realm or principal API. It also
> > feels like it can never be complete or appropriate.
>
> Looking at the proposed change for the DataSourceRealm I can see it has
> clearly defined limits. I can see how we might get requests to push back
> those limits in the future.
>
> I have a general concern / unease that doing this in an application
> specific manner would be relatively easy but doing it generically could
> get complex.
>
> > I apologize for having to do this, after initially helping out with
> > this PR, but this is one of those situations where the more I look
> > about it, the worse I feel about it.
>
> I do recognise the use case of wanting to expose data that is already in
> the Realm to the application.

Yes, that was what I was thinking about too. But then it still
encourages putting more stuff in the realm backend (since now you can,
you probably know how it works by now).
The use case in the PR is the DataSourceRealm (not the LDAP one), so
let's assume it is a JDBC thing. Retrieving the data from another data
source connecting to the same backend in the application might
(supposedly) be less efficient (but if you pull a lot of data from the
DB, it will suddenly be impossible to tell the difference), but is
portable and you could store things properly (and more importantly
avoid asking us to add code to automagically map to Java collections
... that's just for starters obviously).

> I wonder whether this is a case where we can just provide some hooks
> and, if the developer chooses to (ab)use them, that is up to them.
>
> I'm thinking something like a getUserAttributes() method on Realm that
> re

Re: Running unit tests with JVMs < 11

2022-02-10 Thread Rémy Maucherat
On Thu, Feb 10, 2022 at 2:11 PM Mark Thomas  wrote:
>
> On 09/02/2022 14:04, Rainer Jung wrote:
> > Hi all,
> >
> > I wonder how important it is to be able to run the unit tests for TC
> > 8.5-10.0 with JVM versions 8 or even 7 (TC 8.5).
> >
> > The unconditional addition of unit test jvmargs "--add-opens=..." in
> > 2b6e19e971a980e38bcd30f05c554d9b798666c0 (TC 10, backported) means, we
> > can no longer run the tests with Java 8 or even 7.
> >
> > If I remove those jvmargs from build.xml, I run into a second problem
> > when testing TC 8.5 with Java 7. In
> > 014f4746176c7f27cda7c04b2c6036a539c385ff EasyMock was updated from 3.x
> > to 4.x, which needs Java 8 to run. Several tests fail with
> > UnsupportedClassVersionError in a few EasyMock classes.
> >
> > I can work around all of these myself for running the tests here, but I
> > wonder, what kind of setup for testing we want to support out-of-the box.
> >
> > Note that by reintroducing the previous compatibility trick for jvmargs
> > (TC 8.5, 9 and 10) and using the old EasyMock branch for TC 8.5 we could
> > still build and test with Java 11, but would also allow testing on the
> > other target Java versions we support.
> >
> > WDYT?
>
> I've been thinking about this since I read this yesterday.
>
> I like that the move to Java 11 allowed us to reduce the differences
> between the build scripts.

+1

> So the decision is: Is the benefit of being able to test with older Java
> versions worth the differences this would re-introduce?
>
> We don't test the JreCompat code so there aren't any Java version
> specific tests. So what do we gain by testing on Java 7 / Java 8? I can
> think of a few things:
> - that we really have coded to the correct Java version
> - that the code runs as expected on that Java version
>
> Both of those things are more testing Java than testing Tomcat but I can
> see that there is some benefit - especially if one is concerned about
> the possibility of the code behaving differently on Java 7/8 compared to
> Java 11.

It is a good point that this is about testing Java (the bytecode
produced should target Java 8 exclusively - talking about Tomcat 9,
for example -, and the behavior of the API should be the same; if
either becomes false, then this is actually a Java bug).

To be honest, I only partially trust that "release" feature right now.
Although it seems to work, it might simply need time to get used to
the concept ! I did point out the testsuite problem when this was
initially discussed. And I understand the lack of trust if Tomcat is
simply not tested on Java 8 (or 7, cough; let's pretend it is really
tested ;) ) before release.

Instead of completely reverting to the previous properties hack and
reintroducing differences between branches, I would simply advocate
moving the offending values to hardcoded property values in build.xml
(which can then be replaced by Java 8 compatible placeholder values in
your own build.properties - same idea than for the dependencies which
can be replaced by Java 8 compatible ones).

> I'm not concerned about that but neither am I too concerned about the
> re-introduction of a few differences. I guess I am -0 overall provided
> that any change does not impact the existing CI systems.

Rémy

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



Re: Tagging 10.1.x and 10.0.x tomorrow

2022-02-10 Thread Rémy Maucherat
On Wed, Feb 9, 2022 at 1:18 PM Mark Thomas  wrote:
>
> On 07/02/2022 21:06, Mark Thomas wrote:
> > Hi all,
> >
> > Just a heads up that, barring surprises, I plan to be in a position to
> > tag 10.1.x and 10.0.x for the February release round towards the end of
> > tomorrow.
>
> There were surprises. Looking more like the end of the week at the moment.

The situation with c3edf437da20af0f11edc0ad6d893399b01e6287 will have
to be resolved before tagging since it is an API change.
As usual in this case, if nobody seconds my objections, then this can
move along.

Rémy

>
> 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: [tomcat] branch main updated: Add support for additional user attributes in TomcatPrincipal

2022-02-10 Thread Rémy Maucherat
On Tue, Feb 8, 2022 at 2:13 PM  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> michaelo pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
>  new c3edf43  Add support for additional user attributes in 
> TomcatPrincipal
> c3edf43 is described below
>
> commit c3edf437da20af0f11edc0ad6d893399b01e6287
> Author: Carsten Klein 
> AuthorDate: Wed Jan 12 15:06:42 2022 +0100
>
> Add support for additional user attributes in TomcatPrincipal
>
> This closes #463

-1 (veto)

Unfortunately, the more I think about this, the more it seems wrong to me.

This makes the realm an object store, which is not a good idea at all,
as it will:
- Encourage all sorts of bad hacks and practices for users
- Force us to gradually add more and more features to this generic
object store feature
- Have massive discrepancies between realms, with the users trying to
figure out pros and cons between realms
- Is a proprietary feature which ties up users to Tomcat

More importantly: application data storage should remain the
prerogative of the application, Tomcat should not attempt to do that.
The only thing Tomcat should provide is a principal name, which is
then the primary key for the third party object store. There is zero
reason to integrate this within the realm or principal API. It also
feels like it can never be complete or appropriate.

I apologize for having to do this, after initially helping out with
this PR, but this is one of those situations where the more I look
about it, the worse I feel about it.

Rémy

> ---
>  java/org/apache/catalina/TomcatPrincipal.java  | 28 +
>  .../apache/catalina/realm/GenericPrincipal.java| 46 
> ++
>  java/org/apache/catalina/realm/JNDIRealm.java  |  2 +-
>  webapps/docs/changelog.xml |  5 +++
>  webapps/examples/jsp/security/protected/index.jsp  | 44 +
>  5 files changed, 117 insertions(+), 8 deletions(-)
>
> diff --git a/java/org/apache/catalina/TomcatPrincipal.java 
> b/java/org/apache/catalina/TomcatPrincipal.java
> index 83f9035..1e3d9f6 100644
> --- a/java/org/apache/catalina/TomcatPrincipal.java
> +++ b/java/org/apache/catalina/TomcatPrincipal.java
> @@ -17,6 +17,8 @@
>  package org.apache.catalina;
>
>  import java.security.Principal;
> +import java.util.Collections;
> +import java.util.Enumeration;
>
>  import org.ietf.jgss.GSSCredential;
>
> @@ -47,4 +49,30 @@ public interface TomcatPrincipal extends Principal {
>   *   exception to LoginContext
>   */
>  void logout() throws Exception;
> +
> +/**
> + * Returns the value of the named attribute as an Object, or
> + * null if no attribute of the given name exists, or if
> + * null has been specified as the attribute's name.
> + * 
> + * Only the servlet container may set attributes to make available custom
> + * information about a Principal or the user it represents.
> + *
> + * @param name a String specifying the name of the attribute
> + * @return an Object containing the value of the attribute, 
> or
> + * null if the attribute does not exist, or if
> + * null has been specified as the attribute's name
> + */
> +Object getAttribute(String name);
> +
> +/**
> + * Returns an Enumeration containing the names of the
> + * attributes available to this Principal. This method returns an empty
> + * Enumeration if the Principal has no attributes available 
> to
> + * it.
> + *
> + * @return an Enumeration of strings containing the names of
> + * the Principal's attributes
> + */
> +Enumeration getAttributeNames();
>  }
> diff --git a/java/org/apache/catalina/realm/GenericPrincipal.java 
> b/java/org/apache/catalina/realm/GenericPrincipal.java
> index 7260da4..584c104 100644
> --- a/java/org/apache/catalina/realm/GenericPrincipal.java
> +++ b/java/org/apache/catalina/realm/GenericPrincipal.java
> @@ -19,7 +19,10 @@ package org.apache.catalina.realm;
>  import java.io.Serializable;
>  import java.security.Principal;
>  import java.util.Arrays;
> +import java.util.Collections;
> +import java.util.Enumeration;
>  import java.util.List;
> +import java.util.Map;
>
>  import javax.security.auth.login.LoginContext;
>
> @@ -120,7 +123,7 @@ public class GenericPrincipal implements TomcatPrincipal, 
> Serializable {
>   */
>  public GenericPrincipal(String name, List roles,
>  Principal userPrincipal, LoginContext loginContext) {
> -this(name, roles, userPrincipal, loginContext, null);
> +this(name, roles, userPrincipal, loginContext, null, null);
>  }
>
>  /**
> @@ -140,7 +143,7 @@ public class GenericPrincipal implements TomcatPrincipal, 
> Serializable {
>  @Deprecated
>  public GenericPrincipal(String 

Re: JDK 18 Rampdown Phase 2 & JDK 19 Early-Access Builds

2022-01-31 Thread Rémy Maucherat
On Mon, Jan 31, 2022 at 10:33 AM David Delabassee
 wrote:
>
> Greetings!
>
> First off, on behalf of Oracle’s Java Team, I’d like to wish you a happy
> and prosperous new year!
>
> In 2022, two Java releases will be made available:
> - JDK 18 (March 2022)
> - JDK 19 (September 2022)
>
> JDK 18[1] has entered Rampdown Phase Two (RDP2)[2]. Given that and to be
> better prepared for the future, it makes sense to begin testing your
> project(s) using early access (EA) builds of JDK 19[3]. Your feedback
> allows us to evaluate and address issues you find while testing EA builds.
>
> This time, we have two heads-up to share:
>
> ## Heads-Up: JDK 18 - JEP 421 Deprecate Finalization for Removal
>
> Finalization is an outdated and brittle resource cleaning mechanism
> present in the platform since, well, forever. Its use has been
> discouraged for quite some time in favor of better alternatives (i.e.,
> 'try with resources' and Cleaners). JEP 421 is another step towards the
> removal of finalizers as it offers tools to investigate if a codebase is
> still using finalization. To learn more, you should read JEP 421[4]. You
> should also listen to the latest episode of the Inside Java Podcast[5]
> dedicated to this topic. We encourage you to check if your project is
> still using finalizers. If so, you should start to think about removing
> them and rely instead on either 'try with resources' or Cleaners.
>
> ## Heads-Up: JVM does not flag constant class entries ending in '/'
>
> Prior to JDK 19, the JVM is loading classes (1) whose class file major
> version is <49, i.e., before JDK 1.5, and (2) the class's name ends with
> a '/'. This violates section 4.2.1 of the JVM specification [6] and is
> addressed in JDK 19. In JDK 19, the JVM is throwing, for such classes, a
> ClassFormatError exception as it already does with newer classes (JDK
> 1.5+). Given that this issue affects only pre-JDK 1.5 classes, we expect
> the compatibility risk to be very low.
>
> For more details, see JDK-8278448[7].
>
> [1] https://jdk.java.net/18/
> [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-January/006361.html
> [3] https://jdk.java.net/19/
> [4] https://openjdk.java.net/jeps/421
> [5] https://inside.java/podcast/21
> [6]
> https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.2.1
> [7] https://bugs.openjdk.java.net/browse/JDK-8278448
>
>
> ## JDK 18
>
> JDK 18 is now in RDP2 (Rampdown Phase Two) with its feature set frozen a
> few weeks back when it entered RDP1.
>
> ### JEPs integrated to JDK 18:
>
> - JEP 400: UTF-8 by Default
> - JEP 408: Simple Web Server
> - JEP 413: Code Snippets in Java API Documentation
> - JEP 416: Reimplement Core Reflection with Method Handles
> - JEP 417: Vector API (Third Incubator)
> - JEP 418: Internet-Address Resolution SPI
> - JEP 419: Foreign Function & Memory API (Second Incubator)

This one was not super exciting, so moving on to the foreign preview
instead (for now it is java.lang.foreign).

> - JEP 420: Pattern Matching for switch (Second Preview)
> - JEP 421: Deprecate Finalization for Removal

Rémy

> JDK 18 Early-Access builds 33 are now available[8], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Also available are the Release Notes[9].
>
> [8] https://jdk.java.net/18/
> [9] https://jdk.java.net/18/release-notes
>
> ### Changes in JDK 18 since Rampdown Phase One that are of interest:
>
> - JDK-8278373: Correcting References to Overloaded Methods in Javadoc
> Documentation
> - JDK-8279065: Deserialization filter and filter factory property error
> reporting under specified
> - JDK-8255409: SunPKCS11 Provider Now Supports Some PKCS#11 v3.0 APIs
> - JDK-8275610: C2: Object field load floats above its null check
> resulting in a segfault [Reported by Apache POI]
>
>
> ## JDK 19
>
> JDK 19 Early-Access builds 7 are now available[10], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> Also available are the Release Notes[11].
>
> [10] https://jdk.java.net/19/
> [11] https://jdk.java.net/19/release-notes
>
> ### Changes in recent JDK 19 EA builds that maybe of interest:
>
> - JDK-8279258: Auto-vectorization enhancement for two-dimensional array
> operations
> - JDK-8273914: Indy string concat changes order of operations
> - JDK-8268081: Upgrade Unicode Data Files to 14.0.0
> - JDK-8278087: Deserialization filter and filter factory property error
> reporting under specified
> - JDK-8276766: Enable jar and jmod to produce deterministic timestamped
> content
> - JDK-8274679: Remove unnecessary conversion to String in security code
> in java.base
> - JDK-8279833: Loop optimization issue in String.encodeUTF8_UTF16
> - JDK-8279064: New options for ktab to provide non-default salt
> - JDK-8280055: JFR: Improve ObjectContext implementation
> - JDK-8268831: Improve javadoc tool handling of streams
>
>
> ## Topics of Interest:
>
> - "State of Valhalla" update
> 

Re: Digicert code-signing

2022-01-27 Thread Rémy Maucherat
On Thu, Jan 27, 2022 at 10:12 PM Mark Thomas  wrote:
>
> Primarily for release managers.
>
> Your API key and certificate have expiry dates. By default this is a
> year after you created them. The error message when they have expired
> just indicates that the credentials are invalid.
>
> If you get unexpected signing errors - check the validity of your API
> key and cert (you can do this through the DigiCert one web interface).

Thanks for the reminder. It's best to go in and check it a little once
in a while (I had forgotten about the website already ...) rather than
be stuck in the middle of some early July release.

Rémy

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



Re: Reproducible builds update

2022-01-21 Thread Rémy Maucherat
On Thu, Jan 20, 2022 at 11:57 PM Mark Thomas  wrote:
>
> On 20/01/2022 11:02, Mark Thomas wrote:
> > On 19/01/2022 16:56, Rémy Maucherat wrote:
> >> On Wed, Jan 19, 2022 at 5:52 PM Emmanuel Bourg  wrote:
> >>> Fortunately a non-reproducible javadoc isn't really important, what
> >>> matters the most is to have reproducible executable packages.
> >>
> >> That seems like a reasonable statement !
> >
> > Ack. I'll look at the Javadoc issue in slower time.
> >
> > I'm currently looking at reproducibility cross-platform. There seem to
> > be differences in ordering for entries in archives. I need to figure out
> > what the root cause is before I decide whether cross-platform
> > reproducibility is worth pursuing further or not.
>
> I think I have figured this out. It is to do with ordering.
>
> Ant's zip task orders files by name and then places them in the archive,
> adjusting the file separator as required.
>
> The issue is that on Linux you have:
>
> webapp/WEB-INF
> webapp2/WEB-INF
>
> whereas on Windows you have
>
> webapp2\WEB-INF
> webapp\WEB-INF
>
> Because in ASCII:
> '/' is 0x2F
> '0'-'9' is 0x30 to 0x39
> 'A'-'Z' is 0x41 to 0x5A
> '\' is 0x5C
> 'a'-'z' is 0x61 to 0x7A
>
> The different file separator between platforms causes the file order to
> change.
>
> I have been working on fixing this here:
> https://github.com/markt-asf/tomcat/commits/reproducible
>
> The biggest change is the removal of the applet example - but since that
> doesn't work on any mainstream browser these days I think that is OK.
>
> I want to run a few more tests on this but, assuming they all pass, I'll
> probably apply these changes tomorrow. They will likely be reorganised
> when I do.

Nice tricks !

Rémy

> I haven't looked beyond the src.zip archive yet. I imagine there might
> be similar issues elsewhere.
>
> 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



[ANN] Apache Tomcat 9.0.58 available

2022-01-20 Thread Rémy Maucherat
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.58.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.58 is a bugfix and feature release. The notable
changes compared to 9.0.56 include:

- Add recycling check in the input and output stream isReady to try to
   give a more informative ISE when the facade has been recycled.

- Implement support for HTTP/1.1 upgrade when the request includes a
   body. The maximum permitted size of the body is controlled by
   maxSavePostSize.

- Improve handling of various cases where one request/response
   processing thread attempts to manage the asynchronous IO for a
   different request/response.

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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



[VOTE][RESULT] Release Apache Tomcat 9.0.58

2022-01-20 Thread Rémy Maucherat
The following votes were cast:

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

No other votes were cast. Therefore, the vote passes.

Thanks to everyone who contributed to this release and testing it.

Rémy

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



Re: [VOTE] Release Apache Tomcat 9.0.58

2022-01-20 Thread Rémy Maucherat
On Sat, Jan 15, 2022 at 3:50 PM Rémy Maucherat  wrote:
>
> The proposed Apache Tomcat 9.0.58 release is now available for voting.
>
> The notable changes compared to 9.0.56 are:
>
> - Add recycling check in the input and output stream isReady to try to
>give a more informative ISE when the facade has been recycled.
>
> - Implement support for HTTP/1.1 upgrade when the request includes a
>body. The maximum permitted size of the body is controlled by
>maxSavePostSize.
>
> - Improve handling of various cases where one request/response
>processing thread attempts to manage the asynchronous IO for a
>different request/response.
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.58/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1354
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.58
> bd9afafc1ec568f8160ed3679a776b26d8a29b99
>
> The proposed 9.0.58 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 9.0.58 (stable)

Still looking for one binding vote.

Thanks,
Rémy

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



Re: Reproducible builds update

2022-01-19 Thread Rémy Maucherat
On Wed, Jan 19, 2022 at 5:52 PM Emmanuel Bourg  wrote:
> Fortunately a non-reproducible javadoc isn't really important, what
> matters the most is to have reproducible executable packages.

That seems like a reasonable statement !

Rémy

-
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.75 (clarified version numbers, again)

2022-01-19 Thread Rémy Maucherat
On Tue, Jan 18, 2022 at 11:26 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 8.5.75 release is now available for voting.
>
> The one notable change compared to 8.5.74 (which was not released due to
> this bug) is:
>
> - Correct a regression in the fix for BZ 65785 that broke HTTP/2
>  server push.
>
> The notable changes compared to 8.5.73 are:
>
> - Provide protection against a known OS bug that causes the acceptor to
> report an incoming connection more than once.
>
> - Fix several potential JVM crashes when using the APR connector.
>
> - Implement a workaround for a JVM bug that can trigger a file
> descriptor leak when using multi-part upload and the application does
> not explicitly close an input stream for an uploaded file that was
> cached on disk.
>
> - Fix exceptions when the security manager is enabled and the first
> request received after starting is an HTTP request to a TLS enabled
> NIO2 connector.
>
> - Implement support for HTTP/1.1 upgrade when the request includes a
> body. The maximum permitted size of the body is controlled by
> maxSavePostSize.
>
> - Improve handling of various cases where one request/response
> processing thread attempts to manage the asynchronous IO for a
> different request/response.
>
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.75/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1355
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.75/
> Commit b5c9c3a25a17f777989408973013f5312acdb8e2
>
> The proposed 8.5.75 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.75 (stable)

Rémy

>
> -
> 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: [VOTE] Release Apache Tomcat 10.0.16

2022-01-17 Thread Rémy Maucherat
On Sat, Jan 15, 2022 at 3:11 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.0.16 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to jakarta.*
>
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes. Java EE applications designed for Tomcat 9 and earlier may be
> placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will
> automatically convert them to Jakarta EE and copy them to the webapps
> directory
>
> The notable changes compared to 10.0.14 are:
>
> - Add recycling check in the input and output stream isReady to try to
>give a more informative ISE when the facade has been recycled.
>
> - Implement support for HTTP/1.1 upgrade when the request includes a
>body. The maximum permitted size of the body is controlled by
>maxSavePostSize.
>
> - Improve handling of various cases where one request/response
>processing thread attempts to manage the asynchronous IO for a
>different request/rsponse
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.0.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.16/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1353
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.16
> 69c88c4a4ca9c5ec1f700c74cda4f3aa75708301
>
> The proposed 10.0.16 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 10.0.16 (stable)

Rémy

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



Re: [VOTE] Release Apache Tomcat 10.1.0-M10

2022-01-15 Thread Rémy Maucherat
On Sat, Jan 15, 2022 at 1:49 PM Mark Thomas  wrote:
>
> The proposed Apache Tomcat 10.1.0-M10 release is now available for
> voting.
>
> Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
> without changes. Java EE applications designed for Tomcat 9 and earlier
> may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat
> will automatically convert them to Jakarta EE and copy them to the
> webapps directory.
>
> The notable changes compared to 10.1.0-M8 are:
>
> - Add recycling check in the input and output stream isReady to try to
>give a more informative ISE when the facade has been recycled.
>
> - Implement support for HTTP/1.1 upgrade when the request includes a
>body. The maximum permitted size of the body is controlled by
>maxSavePostSize.
>
> - Improve handling of various cases where one request/response
>processing thread attempts to manage the asynchronous IO for a
>different request/rsponse
>
> For full details, see the changelog:
> https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.0-M10/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1352
>
> The tag is:
> https://github.com/apache/tomcat/tree/10.1.0-M10
> dc3639dd7123301ced18dbf4ddf2dca93704870d
>
>
> The proposed 10.1.0-M10 release is:
> [ ] Broken - do not release
> [X] Alpha - go ahead and release as 10.1.0-M10 (alpha)

Rémy

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



[VOTE] Release Apache Tomcat 9.0.58

2022-01-15 Thread Rémy Maucherat
The proposed Apache Tomcat 9.0.58 release is now available for voting.

The notable changes compared to 9.0.56 are:

- Add recycling check in the input and output stream isReady to try to
   give a more informative ISE when the facade has been recycled.

- Implement support for HTTP/1.1 upgrade when the request includes a
   body. The maximum permitted size of the body is controlled by
   maxSavePostSize.

- Improve handling of various cases where one request/response
   processing thread attempts to manage the asynchronous IO for a
   different request/response.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.58/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1354
The tag is:
https://github.com/apache/tomcat/tree/9.0.58
bd9afafc1ec568f8160ed3679a776b26d8a29b99

The proposed 9.0.58 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 9.0.58 (stable)

Rémy

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

2022-01-14 Thread Rémy Maucherat
On Fri, Jan 14, 2022 at 11:32 PM Mark Thomas  wrote:
>
> On 13/01/2022 13:44, Christopher Schultz wrote:
>
> > The proposed 8.5.74 release is:
> > [X] Broken - do not release
> > [ ] Stable - go ahead and release as 8.5.73 (stable)
>
> I have discovered HTTP/2 server push was broken.
>
> This is minor for 8.5.x since server push isn't available via the
> Servlet API. You have to cast a request to the Tomcat facade and then
> use Tomcat's ApplicationPushBUilder.

I doubt this is actually used with 8.5, the early adopters will have
moved to 9 by now. Also push is actually not seen very favorably
anymore from what I understand.

So I'm unsure about that.

Rémy

>
> An argument could be made for releasing anyway with this bug but I'm
> leaning towards a new tag.
>
> 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: [tomcat] 01/02: SWitch to building with Java 11 and using --release

2022-01-13 Thread Rémy Maucherat
On Thu, Jan 13, 2022 at 6:28 PM  wrote:
> -   - property="java9.test.option.1"
> - value="--add-opens=java.base/java.lang=ALL-UNNAMED"/>
> -  

This is a nice hack I forgot about, I didn't know how to make jvmarg
conditional. I'll reuse that for the OpenSSL module and Java 17.

Rémy

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

2022-01-13 Thread Rémy Maucherat
On Thu, Jan 13, 2022 at 2:45 PM Christopher Schultz
 wrote:
>
> The proposed Apache Tomcat 8.5.74 release is now available for voting.
>
> The notable changes compared to 8.5.73 are:
>
> - Provide protection against a known OS bug that causes the acceptor to
> report an incoming connection more than once.
>
> - Fix several potential JVM crashes when using the APR connector.
>
> - Implement a workaround for a JVM bug that can trigger a file
> descriptor leak when using multi-part upload and the application does
> not explicitly close an input stream for an uploaded file that was
> cached on disk.
>
> - Fix exceptions when the security manager is enabled and the first
> request received after starting is an HTTP request to a TLS enabled
> NIO2 connector.
>
> - Implement support for HTTP/1.1 upgrade when the request includes a
> body. The maximum permitted size of the body is controlled by
> maxSavePostSize.
>
> - Improve handling of various cases where one request/response
> processing thread attempts to manage the asynchronous IO for a
> different request/response.
>
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat-8.5.x/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.74/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1351
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.74/
> Commit 2ea50557ae05ccfca7f521ab328c238237aec8b1
>
> The proposed 8.5.74 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 8.5.73 (stable)

Rémy

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



Re: [tomcat] branch 9.0.x updated: Add note about version numbering

2022-01-13 Thread Rémy Maucherat
On Thu, Jan 13, 2022 at 2:24 PM  wrote:
>
> 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 ea99f41  Add note about version numbering
> ea99f41 is described below
>
> commit ea99f41f406d184b33648da24d38260f71136ba0
> Author: Christopher Schultz 
> AuthorDate: Thu Jan 13 08:24:30 2022 -0500
>
> Add note about version numbering
> ---
>  res/maven/README.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/res/maven/README.txt b/res/maven/README.txt
> index 3a2d09e..3ddd2a0 100644
> --- a/res/maven/README.txt
> +++ b/res/maven/README.txt
> @@ -20,7 +20,7 @@ General preparations before any publishing:
>  2 - cd res/maven
>  3 - Copy mvn.properties.default to mvn.properties and adjust it as necessary.
>  You will need to set asf.ldap.username and you'll probably need to set
> -gpg.exec
> +gpg.exec; triple-check maven.asf.release.deploy.version

This is supposed to be updated right after the tag, when changelog.xml
is updated to open the section on the next build.

Rémy

>  The other properties should be OK. Note: you will be prompted for your
>  GPG pass-phrase and LDAP password when the script runs.
>
>
> -
> 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



  1   2   3   4   5   6   7   8   9   10   >