Hello,
Let me know if you want an official bug report or this not will suffice. The
message "jsseUtil.noVerificationDepth" which is defined in
https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/LocalStrings.properties
as a one arg string:
jsseUtil.noVerification
Mark,
Can you elaborate around the following:
All combinations support server initiated requests for client certificates
apart from NIO[2]+JSSE on Java 11 as the Java 11 TLSv1.3 implementation does
not include post handshake authentication.
What are the use cases affected. Is it for TLS upgr
Is there anyone working on connectors or Apache is doing just emergency
security releases?
I've submitted a bug [1] with a simple, one liner fix that got overlooked for
this release. We're maintaining a parallel source branch to get around this
issue which breaks authentication integrations and
opers List
Subject: Re: JK 1.2.41
On 27/07/2015 00:05, George Stanchev wrote:
> Is there anyone working on connectors or Apache is doing just
> emergency security releases?
As with all ASF projects, committers work on projects when they want to and
when they have time to.
At the moment, I
I am facing an issue with authentication. Please forgive me if I am posting
this in the wrong place.
I am running IIS+jk_connect+Tomcat 7.0.59 but this issue was replicated on
Tomcat 5.5.36. We are using a security filter from a 3rd party that is failing
to engage while requests are sent over A
I am hoping someone can shed some lights on a question. I did try to search
online and SO but haven't had luck in figure it out so hopefully it is a quick
answer from the people that know that stuff. We have an uber-lib folder where
we keep shared libraries in our TC85-hosted app. If we put jstl
Apologies. I accidently sent this to the wrong mailing list. Will resend to the
user mailing list.
From: George Stanchev
Sent: Tuesday, October 20, 2020 1:02 PM
To: Tomcat Developers List
Subject: jstl jar location
I am hoping someone can shed some lights on a question. I did try to search
I find it quite surprising that you are worried about security for a version
that is so old (latest Tomcat on the 7.0.x branch is 7.0.103). Proper security
practices call for using latest versions where security issues might be
resolved.
From: Victor Rodriguez
Sent: Friday, March 27, 2020 11:5
I ran ant ide-eclipse and the generated project contains a reference to
But D:\work\My Projects\java\Tomcat\8.5.57-src\libraries-download\cglib-3.3.0
contains only cglib-nodep-3.3.0.jar not cglib-nodep-2.2.2.jar. Not sure if I
did something wrong…The resulting eclipse project of course complai
Thanks Martin, it is not a stopper, just pointed it out…
From: Martin Grigorov
Sent: Thursday, July 02, 2020 4:00 AM
To: Tomcat Developers List
Subject: Re: [VOTE] Release Apache Tomcat 8.5.57
On Wed, Jul 1, 2020, 23:48 George Stanchev
mailto:george.stanc...@microfocus.com>> wrote:
I r
Since I was the one that brought up a question about OpenJSSE on the User
Mailing List several weeks ago, just wanted to bring up to your attention that
there are quirks of OpenJSSE that people are discovering. I was able to get
TC85 to run with OpenJSSE but admitting haven’t done extensive test
Mark,
Can you look at my comments at the user's mailing list on the original thread
about the encoding issue. The issue seems to have resurfaced in a different
form.
George
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apac
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Tuesday, August 08, 2017 5:23 AM
To: Tomcat Developers List
Subject: Test keys and certs
All,
Just a heads up.
A few days ago I started to look at bug 59423. I saw all sorts of errors when I
tried to configure a cl
The "clean" target of the TC build file leaves "output\jdbc-pool" directory.
This is because the "clean" target first deletes the output dir [1] but then
calls the jdbc "clean" script [2] which recreates the directory in the "output"
location [3]. Why would [3] be called as part of a "clean" scr
14 matches
Mail list logo