[tomcat-native] branch main updated: Improve wording
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 The following commit(s) were added to refs/heads/main by this push: new 5eb766be2 Improve wording 5eb766be2 is described below commit 5eb766be2da09fedc2b08af3d0eac82da4d53023 Author: Mark Thomas AuthorDate: Mon Jul 4 12:07:48 2022 +0100 Improve wording --- xdocs/miscellaneous/tls-renegotiation.xml | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xdocs/miscellaneous/tls-renegotiation.xml b/xdocs/miscellaneous/tls-renegotiation.xml index 1d411cc20..42904ec6d 100644 --- a/xdocs/miscellaneous/tls-renegotiation.xml +++ b/xdocs/miscellaneous/tls-renegotiation.xml @@ -40,9 +40,10 @@ - Support for unsafe legacy negotiation depends on OpenSSL. Only if Tomcat - Native is compiled with a build of OpenSSL that supports legacy renegotiation - will Tomcat Native support it. + Support for unsafe legacy negotiation depends on OpenSSL. Unsafe legacy + renegotiation is disabled by default and will not be allowed unless the + OpenSSL configuration option + SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set. - 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 2.0.0
On 30/06/2022 17:55, Christopher Schultz wrote: Mark, On 6/30/22 09:58, Mark Thomas wrote: This is the first release of the Tomcat Native 2.0.x branch. The major differences compared to the 1.2.x branch are: - JNI API has been reduced to just that required to support the use of OpenSSL rather than JSSE for TLS connections. The APR/native connector is not supported. This statement is confusing. I think it should say "JNI API has been reduced to just that required to support OpenSSL as a JSSE provider for TLS connections. The API/native connector is no longer supported in this branch." The confusion is over JSSE versus OpenSSL which are not mutually-exclusive. What we are doing AIUI is specifically using OpenSSL through JSSE, instead of going around JSSE and using OpenSSL directly (well, through APR-connections). Ack. I was trying to avoid saying we were using an OpenSSL based JSSE provider as we are not doing that. How about: "The JNI API has been reduced to just that required to support Tomcat's OpenSSL based TLS implementation. The APR/native connector is no longer supported in this branch." - The minimum supported versions have been increased to OpenSSL 3.0.x, Apache APR 1.7.x, Java 11, Windows 7 / Server 2008 R2 How much do we continue to rely on APR at this point? Usually, the reason to use APR is to take advantage of APRs pooling and e.g. connection-handling capabilities. As we are dropping support for the APR connector, the connection-handling capabilities are no longer required, and the pooling is really only helpful when delayed-cleanup of those pools is necessary. I think we can probably drop the APR dependency -- at least over time. I'm not convinced. We are mostly using APR for the memory management and I don't rate my chances of re-writing the TLS code without it whilst avoiding both bugs and memory leaks. Given the medium / long term direction (the project Panama code Rémy has been working on) I don't think the benefit of fully removing APR is worth the effort.. The 2.0.x branch is primarily intended for use with Tomcat 10.1.x but can be used with earlier versions as long as the APR/native connector is not used. The proposed release artefacts can be found at [1], and the build was done using tag [2]. The Apache Tomcat Native 2.0.0 release is [ ] Stable, go ahead and release [ ] Broken because of ... Thanks, Mark I will try to do some testing on 8.5.x Tx. Mark - 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 2.0.0
On 03/07/2022 04:46, Igal Sapir wrote: Mark, On Thu, Jun 30, 2022 at 6:58 AM Mark Thomas wrote: This is the first release of the Tomcat Native 2.0.x branch. The major differences compared to the 1.2.x branch are: - JNI API has been reduced to just that required to support the use of OpenSSL rather than JSSE for TLS connections. The APR/native connector is not supported. - The minimum supported versions have been increased to OpenSSL 3.0.x, Apache APR 1.7.x, Java 11, Windows 7 / Server 2008 R2 Is this really intended only for Windows? I have been testing previous versions of Tomcat Native on Ubuntu 20.04 but I am unable to test this version. No. I need to reword the above. The minimum versions of OpenSSL, APR and Java have increased for all platforms. The minimum version of Windows that we support has increased to Windows 7 / Server 2008 R2. On the main branch, Tomcat 10.1, my tests are not running? Config settings seem fine to me: --- ❯ ant echoproperties | grep apr [echoproperties] execute.test.apr=true [echoproperties] test.apr.loc=/workspace/build/tomcat/tomcat-native/tomcat-native-2.0.0/lib --- But no tests are running when I run `ant test`: There are no tests anymore. The functionality that was being tested has been removed. There is a single test left that isn't executed by default as it is more of a development / debugging utility class intended to help find memory leaks. On the 10.0.x no matter what I try - building tcnative seems to identify APR 1.7.0 but the test cases are failing because APR 1.6.5 is loaded, and I did edit ~/natives/apr/lib/libapr-1.la ** per the instructions in native/BUILDING. The filename specified in [1] is libapr-2.la but APR 1.7.0 is still libapr-1.la - did you edit the version number anywhere or is that a typo? That looks like I edited a version number I shouldn't have. I'll fix that. Unfortunately I can not install APR 1.7.0 using the package manager as that version is only available for newer Ubuntu versions. Ack. Thanks for the review. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-native] branch main updated: Correct filename
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 The following commit(s) were added to refs/heads/main by this push: new 20e00c03e Correct filename 20e00c03e is described below commit 20e00c03e094a2dd336f6f3a1f1ae355a1e1ed41 Author: Mark Thomas AuthorDate: Mon Jul 4 12:31:58 2022 +0100 Correct filename --- native/BUILDING | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/native/BUILDING b/native/BUILDING index 0e6763d61..79935c45f 100644 --- a/native/BUILDING +++ b/native/BUILDING @@ -60,7 +60,7 @@ Linux / Unix / OSX (static linking) 3. Ensure the static APR library is used - Edit the ~/natives/apr/lib/libapr-2.la file and comment or delete the + Edit the ~/natives/apr/lib/libapr-1.la file and comment or delete the following sections: dlname='...' and library_names='...' This is needed so that libtool picks the static version of the library. - 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 2.0.0
On Mon, Jul 4, 2022 at 1:23 PM Mark Thomas wrote: > > On 30/06/2022 17:55, Christopher Schultz wrote: > > Mark, > > > > On 6/30/22 09:58, Mark Thomas wrote: > >> This is the first release of the Tomcat Native 2.0.x branch. The major > >> differences compared to the 1.2.x branch are: > >> > >> - JNI API has been reduced to just that required to support the use of > >>OpenSSL rather than JSSE for TLS connections. The APR/native connector > >>is not supported. > > > > This statement is confusing. I think it should say "JNI API has been > > reduced to just that required to support OpenSSL as a JSSE provider for > > TLS connections. The API/native connector is no longer supported in this > > branch." > > > > The confusion is over JSSE versus OpenSSL which are not > > mutually-exclusive. What we are doing AIUI is specifically using OpenSSL > > through JSSE, instead of going around JSSE and using OpenSSL directly > > (well, through APR-connections). > > Ack. I was trying to avoid saying we were using an OpenSSL based JSSE > provider as we are not doing that. How about: Yes, some of my coworkers derived a provider from the work I did initially. To be a full provider, we'd lose some of our very useful config capabilities (obviously a provider cannot use SSLHostConfig) and add java.io support (which I considered was useless for Tomcat; although with Loom, maybe it's not so stupid anymore ;) ). > "The JNI API has been reduced to just that required to support Tomcat's > OpenSSL based TLS implementation. The APR/native connector is no longer > supported in this branch." > > > >> - The minimum supported versions have been increased to OpenSSL 3.0.x, > >>Apache APR 1.7.x, Java 11, Windows 7 / Server 2008 R2 > > > > How much do we continue to rely on APR at this point? Usually, the > > reason to use APR is to take advantage of APRs pooling and e.g. > > connection-handling capabilities. As we are dropping support for the APR > > connector, the connection-handling capabilities are no longer required, > > and the pooling is really only helpful when delayed-cleanup of those > > pools is necessary. > > > > I think we can probably drop the APR dependency -- at least over time. > > I'm not convinced. We are mostly using APR for the memory management and > I don't rate my chances of re-writing the TLS code without it whilst > avoiding both bugs and memory leaks. > > Given the medium / long term direction (the project Panama code Rémy has > been working on) I don't think the benefit of fully removing APR is > worth the effort.. I agree. Of course, if someone wants to do it ... Rémy > >> The 2.0.x branch is primarily intended for use with Tomcat 10.1.x but > >> can be used with earlier versions as long as the APR/native connector > >> is not used. > >> > >> The proposed release artefacts can be found at [1], > >> and the build was done using tag [2]. > >> > >> The Apache Tomcat Native 2.0.0 release is > >> [ ] Stable, go ahead and release > >> [ ] Broken because of ... > >> > >> Thanks, > >> > >> Mark > > > > I will try to do some testing on 8.5.x > > Tx. > > 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] branch main updated: Add renegotiation info
On 30/06/2022 17:47, Christopher Schultz wrote: On 6/30/22 03:35, ma...@apache.org wrote: + + + Support for unsafe legacy negotiation depends on OpenSSL. Only if Tomcat + Native is compiled with a build of OpenSSL that supports legacy renegotiation + will Tomcat Native support it. + Does this mean it's /possible/ (and configurable) to use Unsafe Legacy Negotiation, or does it mean that it's always-on for openssl builds where it's there, and always-off when it's not there? It means that it is possible, configurable and disabled by default to use unsafe legacy negotiation unless OpenSSL has been compiled with that functionality explicitly removed. In which case it is completely disabled. My memory is that I found a page that indicated it was possible to compile OpenSSL with that functionality removed. When I went to re-check my facts before writing this email, I couldn't find anything to confirm that. I'll re-write that page to make clear that the behaviour is determined by OpenSSL configuration and that with 3.0.x, support is disabled by default. Mark - 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 2.0.0
Hi all, OpenSSL has announced a 3.0.5 release is scheduled for tomorrow that will include security fixes. Depending on the details of those fixes we may need a 2.0.1 release. (And a 1.2.x release.) We currently have 2 PMC votes for this release so we are 1 vote short. There is an argument for proceeding with this release anyway (if it gets another vote) - folks can always build 2.0.0 from source with their chosen version of OpenSSL. My current plan is wait to see if 2.0.0 gets any further votes and to wait for the details of the OpenSSL security issues and then decide what to do. Mark On 30/06/2022 14:58, Mark Thomas wrote: This is the first release of the Tomcat Native 2.0.x branch. The major differences compared to the 1.2.x branch are: - JNI API has been reduced to just that required to support the use of OpenSSL rather than JSSE for TLS connections. The APR/native connector is not supported. - The minimum supported versions have been increased to OpenSSL 3.0.x, Apache APR 1.7.x, Java 11, Windows 7 / Server 2008 R2 The 2.0.x branch is primarily intended for use with Tomcat 10.1.x but can be used with earlier versions as long as the APR/native connector is not used. The proposed release artefacts can be found at [1], and the build was done using tag [2]. The Apache Tomcat Native 2.0.0 release is [ ] Stable, go ahead and release [ ] Broken because of ... Thanks, Mark [1] https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/2.0.0 [2] https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=39c19afe4a3df7ea4fda778d82dc25bd494a110c - 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 2.0.0
On Mon, Jul 4, 2022 at 2:50 PM Mark Thomas wrote: > > Hi all, > > OpenSSL has announced a 3.0.5 release is scheduled for tomorrow that > will include security fixes. Depending on the details of those fixes we > may need a 2.0.1 release. (And a 1.2.x release.) > > We currently have 2 PMC votes for this release so we are 1 vote short. > There is an argument for proceeding with this release anyway (if it gets > another vote) - folks can always build 2.0.0 from source with their > chosen version of OpenSSL. > > My current plan is wait to see if 2.0.0 gets any further votes and to > wait for the details of the OpenSSL security issues and then decide what > to do. +1 Rémy > Mark > > > On 30/06/2022 14:58, Mark Thomas wrote: > > This is the first release of the Tomcat Native 2.0.x branch. The major > > differences compared to the 1.2.x branch are: > > > > - JNI API has been reduced to just that required to support the use of > >OpenSSL rather than JSSE for TLS connections. The APR/native connector > >is not supported. > > > > - The minimum supported versions have been increased to OpenSSL 3.0.x, > >Apache APR 1.7.x, Java 11, Windows 7 / Server 2008 R2 > > > > The 2.0.x branch is primarily intended for use with Tomcat 10.1.x but > > can be used with earlier versions as long as the APR/native connector is > > not used. > > > > The proposed release artefacts can be found at [1], > > and the build was done using tag [2]. > > > > The Apache Tomcat Native 2.0.0 release is > > [ ] Stable, go ahead and release > > [ ] Broken because of ... > > > > Thanks, > > > > Mark > > > > > > [1] > > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/2.0.0 > > > > [2] > > https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=39c19afe4a3df7ea4fda778d82dc25bd494a110c > > > > > > - > > 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
[GitHub] [tomcat] naveensrinivasan closed pull request #525: chore: Included githubactions in the dependabot config
naveensrinivasan closed pull request #525: chore: Included githubactions in the dependabot config URL: https://github.com/apache/tomcat/pull/525 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-connectors] branch main updated: Common: Fix compiler warning when nitializing and copying fixed length strings.
This is an automated email from the ASF dual-hosted git repository.
rjung pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat-connectors.git
The following commit(s) were added to refs/heads/main by this push:
new 97bc5677a Common: Fix compiler warning when nitializing and copying
fixed length strings.
97bc5677a is described below
commit 97bc5677af22184bb7fe56d5e41fc76617b5cdbf
Author: Rainer Jung
AuthorDate: Mon Jul 4 18:35:25 2022 +0200
Common: Fix compiler warning when nitializing and copying fixed length
strings.
---
native/common/jk_ajp_common.c | 21
native/common/jk_ajp_common.h | 6 ++---
native/common/jk_lb_worker.c | 41 ++
native/common/jk_lb_worker.h | 16 ++--
native/common/jk_shm.c| 52 ---
native/common/jk_shm.h| 21
native/common/jk_status.c | 48 ++--
native/common/jk_uri_worker_map.c | 2 +-
native/common/jk_util.c | 38 +---
native/common/jk_util.h | 3 ---
native/common/jk_worker.c | 4 ---
xdocs/miscellaneous/changelog.xml | 4 +++
12 files changed, 146 insertions(+), 110 deletions(-)
diff --git a/native/common/jk_ajp_common.c b/native/common/jk_ajp_common.c
index 02c090bc5..5e078c608 100644
--- a/native/common/jk_ajp_common.c
+++ b/native/common/jk_ajp_common.c
@@ -1122,7 +1122,7 @@ void jk_ajp_pull(ajp_worker_t * aw, int locked,
jk_log_context_t *l)
{
int address_change = JK_FALSE;
int port = 0;
-char host[JK_SHM_STR_SIZ];
+shm_str host;
jk_sockaddr_t inet_addr;
JK_TRACE_ENTER(l);
@@ -1148,7 +1148,7 @@ void jk_ajp_pull(ajp_worker_t * aw, int locked,
jk_log_context_t *l)
if (aw->addr_sequence != aw->s->addr_sequence) {
address_change = JK_TRUE;
aw->addr_sequence = aw->s->addr_sequence;
-strncpy(host, aw->s->host, JK_SHM_STR_SIZ);
+jk_shm_str_copy(host, aw->s->host, l);
port = aw->s->port;
}
if (locked == JK_FALSE)
@@ -1156,7 +1156,7 @@ void jk_ajp_pull(ajp_worker_t * aw, int locked,
jk_log_context_t *l)
if (address_change == JK_TRUE && port != 0) {
aw->port = port;
-strncpy(aw->host, host, JK_SHM_STR_SIZ);
+jk_shm_str_copy(aw->host, host, l);
if (!jk_resolve(host, port, _addr,
aw->worker.we->pool, aw->prefer_ipv6, l)) {
jk_log(l, JK_LOG_ERROR,
@@ -1222,7 +1222,7 @@ void jk_ajp_push(ajp_worker_t * aw, int locked,
jk_log_context_t *l)
if (aw->s->addr_sequence != aw->addr_sequence) {
++aw->s->addr_sequence;
address_change = JK_TRUE;
-strncpy(aw->s->host, aw->host, JK_SHM_STR_SIZ);
+jk_shm_str_copy(aw->s->host, aw->host, l);
aw->s->port = aw->port;
aw->addr_sequence = aw->s->addr_sequence;
}
@@ -2925,18 +2925,16 @@ int ajp_validate(jk_worker_t *pThis,
host = "undefined";
}
tmp = jk_get_worker_host(props, p->name, host);
-if (jk_check_attribute_length("host name", tmp, l) == JK_FALSE) {
+if (jk_shm_str_init(p->host, tmp, "host name", l) == JK_FALSE) {
JK_TRACE_EXIT(l);
return JK_FALSE;
}
-strncpy(p->host, tmp, JK_SHM_STR_SIZ);
p->prefer_ipv6 = jk_get_worker_prefer_ipv6(props, p->name, JK_FALSE);
tmp = jk_get_worker_source(props, p->name, "");
-if (jk_check_attribute_length("source address", tmp, l) == JK_FALSE) {
+if (jk_shm_str_init(p->source, tmp, "source address", l) == JK_FALSE) {
JK_TRACE_EXIT(l);
return JK_FALSE;
}
-strncpy(p->source, tmp, JK_SHM_STR_SIZ);
if (p->s->h.sequence == 0) {
/* Initial setup.
*/
@@ -2971,7 +2969,7 @@ int ajp_validate(jk_worker_t *pThis,
p->s->last_maintain_time = time(NULL);
p->s->last_reset = p->s->last_maintain_time;
p->s->port = p->port;
-strncpy(p->s->host, p->host, JK_SHM_STR_SIZ);
+jk_shm_str_copy(p->s->host, p->host, l);
jk_ajp_push(p, JK_TRUE, l);
}
else {
@@ -3266,7 +3264,10 @@ int JK_METHOD ajp_worker_factory(jk_worker_t **w,
aw->buf,
sizeof(jk_pool_atom_t) * TINY_POOL_SIZE);
-strncpy(aw->name, name, JK_SHM_STR_SIZ);
+if (jk_shm_str_init(aw->name, name, "name", l) == JK_FALSE) {
+JK_TRACE_EXIT(l);
+return JK_FALSE;
+}
aw->login = NULL;
aw->ep_cache_sz = 0;
diff --git a/native/common/jk_ajp_common.h b/native/common/jk_ajp_common.h
index a2402b2c2..c0827f523 100644
--- a/native/common/jk_ajp_common.h
+++ b/native/common/jk_ajp_common.h
@@ -287,7 +287,7 @@ struct ajp_worker
/* Shared memory worker data */
jk_shm_ajp_worker_t *s;
-char
[Bug 66161] New: EL change broke String.concat with null
https://bz.apache.org/bugzilla/show_bug.cgi?id=66161
Bug ID: 66161
Summary: EL change broke String.concat with null
Product: Tomcat 9
Version: 9.0.64
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: EL
Assignee: dev@tomcat.apache.org
Reporter: t...@silbergrau.com
Target Milestone: -
Hello, I use Tomcat 9 with JSF. Currently 9.0.59 and wanted to update to
9.0.64.
Then a Nullpointer occured, so I tried to find out the commit which is related
to our problem.
Since version 9.0.60 the problem occurs and is still a problem with 9.0.64.
Probably introduced with commit
https://github.com/apache/tomcat/commit/d4050b4cc979302c5f5cc9237609e1564fa367c4
?
The EL behaviour has changed for string.concat() with null values. Probably the
new behaviour is more correct than before, but we are not sure yet if the new
behaviour is expected. So could you please check and let us know, if this is a
bug or desired behaviour?
How to reproduce:
--- Our usecase was like xhtml has an is passed, sometimes foo is
null/not added via ui:param.
In someother.xhtml we had the following EL:
With tomcat 9.0.59 passing null resulted in 'sometext'.concat('') [empty
string] -> 'sometext'.
With tomcat 9.0.60 passing null results in 'sometext'.concat(null) which leads
to an Nullpointer in java String.concat()
Using 'sometext' += foo would be nullsafe, but produces 'sometextnull'.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66161] EL change broke String.concat with null
https://bz.apache.org/bugzilla/show_bug.cgi?id=66161 --- Comment #1 from t...@silbergrau.com --- Some additions: maybe the current wrong behaviour (for us) resulted due to updates and we missed something updating from EL2.x to EL3.0. And the tomcat update and the resulting error was just a "by-product". We also set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL true and currently still provide a own EmptyNullStringResolver¹ (which might be the problem here). Without the Resolver, an empty string is passed to concat. I will take a look into removing the custom resolver. ¹ see eg. https://balusc.omnifaces.org/2015/10/the-empty-string-madness.html So this bug simple might be invalid. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
