You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2022/05/31 15:30:12 UTC

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

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 <ma...@apache.org>
AuthorDate: Wed May 25 16:15:02 2022 +0100

    Minimum OpenSSl version is 3.0.0 is keylog callback is always available
---
 native/include/ssl_private.h | 6 ------
 native/src/ssl.c             | 8 --------
 native/src/sslcontext.c      | 2 --
 3 files changed, 16 deletions(-)

diff --git a/native/include/ssl_private.h b/native/include/ssl_private.h
index fc0f6ba9b..4d99ece20 100644
--- a/native/include/ssl_private.h
+++ b/native/include/ssl_private.h
@@ -242,10 +242,6 @@ extern ENGINE *tcn_ssl_engine;
 #define TLS_server_method                SSLv23_server_method
 #endif /* OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) */
 
-#if OPENSSL_VERSION_NUMBER >= 0x10101000L && !defined(LIBRESSL_VERSION_NUMBER)
-#define HAVE_KEYLOG_CALLBACK
-#endif
-
 #define MAX_ALPN_PROTO_SIZE 65535
 #define SSL_SELECTOR_FAILURE_CHOOSE_MY_LAST_PROTOCOL            1
 
@@ -392,9 +388,7 @@ int         SSL_CTX_use_certificate_chain(SSL_CTX *, const char *, int);
 int         SSL_callback_SSL_verify(int, X509_STORE_CTX *);
 int         SSL_rand_seed(const char *file);
 int         SSL_callback_alpn_select_proto(SSL *, const unsigned char **, unsigned char *, const unsigned char *, unsigned int, void *);
-#ifdef HAVE_KEYLOG_CALLBACK
 void        SSL_callback_add_keylog(SSL_CTX *);
-#endif
 
 #if (OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)) && ! (defined(WIN32) || defined(WIN64))
 unsigned long SSL_ERR_get(void);
diff --git a/native/src/ssl.c b/native/src/ssl.c
index c48cb4247..fa8209cbe 100644
--- a/native/src/ssl.c
+++ b/native/src/ssl.c
@@ -29,7 +29,6 @@ extern apr_pool_t *tcn_global_pool;
 ENGINE *tcn_ssl_engine = NULL;
 tcn_pass_cb_t tcn_password_callback;
 
-#ifdef HAVE_KEYLOG_CALLBACK
 static BIO *key_log_file = NULL;
 
 static void ssl_keylog_callback(const SSL *ssl, const char *line)
@@ -39,7 +38,6 @@ static void ssl_keylog_callback(const SSL *ssl, const char *line)
         BIO_puts(key_log_file, "\n");
     }
 }
-#endif
 
 /* From netty-tcnative */
 static jclass byteArrayClass;
@@ -293,14 +291,12 @@ static void free_dh_params(void)
     }
 }
 
-#ifdef HAVE_KEYLOG_CALLBACK
 void SSL_callback_add_keylog(SSL_CTX *ctx)
 {
     if (key_log_file) {
         SSL_CTX_set_keylog_callback(ctx, ssl_keylog_callback);
     }
 }
-#endif
 
 /* Hand out the same DH structure though once generated as we leak
  * memory otherwise and freeing the structure up after use would be
@@ -401,12 +397,10 @@ static apr_status_t ssl_init_cleanup(void *data)
 #endif
 #endif
 
-#ifdef HAVE_KEYLOG_CALLBACK
     if (key_log_file) {
         BIO_free(key_log_file);
         key_log_file = NULL;
     }
-#endif
 
     /* Don't call ERR_free_strings here; ERR_load_*_strings only
      * actually load the error strings once per process due to static
@@ -863,7 +857,6 @@ TCN_IMPLEMENT_CALL(jint, SSL, initialize)(TCN_STDARGS, jstring engine)
     sClazz = (*e)->FindClass(e, "java/lang/String");
     stringClass = (jclass) (*e)->NewGlobalRef(e, sClazz);
 
-#ifdef HAVE_KEYLOG_CALLBACK
     if (!key_log_file) {
         char *key_log_file_name = getenv("SSLKEYLOGFILE");
         if (key_log_file_name) {
@@ -877,7 +870,6 @@ TCN_IMPLEMENT_CALL(jint, SSL, initialize)(TCN_STDARGS, jstring engine)
             }
         }
     }
-#endif
 
     return (jint)APR_SUCCESS;
 }
diff --git a/native/src/sslcontext.c b/native/src/sslcontext.c
index b69b4480f..80a252021 100644
--- a/native/src/sslcontext.c
+++ b/native/src/sslcontext.c
@@ -325,9 +325,7 @@ TCN_IMPLEMENT_CALL(jlong, SSLContext, make)(TCN_STDARGS, jlong pool,
         goto init_failed;
     }
 
-#ifdef HAVE_KEYLOG_CALLBACK
     SSL_callback_add_keylog(ctx);
-#endif
 
     c->protocol = protocol;
     c->mode     = mode;


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


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

Posted by Rémy Maucherat <re...@apache.org>.
On Tue, May 31, 2022 at 8:02 PM Mark Thomas <ma...@apache.org> wrote:
>
> On 31/05/2022 17:59, Rémy Maucherat wrote:
> > On Tue, May 31, 2022 at 6:48 PM Mark Thomas <ma...@apache.org> wrote:
>
> <snip/>
>
> >> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


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

Posted by Mark Thomas <ma...@apache.org>.
On 31/05/2022 17:59, Rémy Maucherat wrote:
> On Tue, May 31, 2022 at 6:48 PM Mark Thomas <ma...@apache.org> wrote:

<snip/>

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

Mark

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


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

Posted by Rémy Maucherat <re...@apache.org>.
On Tue, May 31, 2022 at 6:48 PM Mark Thomas <ma...@apache.org> wrote:
>
> On 31/05/2022 17:34, Christopher Schultz wrote:
> > Mark,
> >
> > On 5/31/22 11:30, markt@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 <ma...@apache.org>
> >> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


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

Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,

On 5/31/22 12:48, Mark Thomas wrote:
> On 31/05/2022 17:34, Christopher Schultz wrote:
>> Mark,
>>
>> On 5/31/22 11:30, markt@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 <ma...@apache.org>
>>> 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.

Oh, right... there's that.

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

IMO libressl support is a *very* nice to have. If it's not to much 
trouble, I think we should try to support it. Theoretically, it has API 
(ABI?) compatibility with OpenSSL (1.x) so it shouldn't be thqt bad if 
we still support earlier versions OpenSSL. But since you've bumped-up 
the requirement to 3.0.x... I'm not sure where that leaves us.

There is a large deployment of OpenSSL 1.x that isn't likely to change 
for a while. I still see many environments on 1.0.x these days, and they 
wouldn't be able to upgrade to tcnative 2, which isn't necessarily a 
deal-breaker. I wouldn't want to require tcnative-2 on 10.0 or below any 
time soon, possible ever. So I think there's still quite a future for 
tcnative-1.

-chris

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


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

Posted by Mark Thomas <ma...@apache.org>.
On 31/05/2022 17:34, Christopher Schultz wrote:
> Mark,
> 
> On 5/31/22 11:30, markt@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 <ma...@apache.org>
>> 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?

Mark

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


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

Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,

On 5/31/22 11:30, markt@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 <ma...@apache.org>
> 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?

-chris

> ---
>   native/include/ssl_private.h | 6 ------
>   native/src/ssl.c             | 8 --------
>   native/src/sslcontext.c      | 2 --
>   3 files changed, 16 deletions(-)
> 
> diff --git a/native/include/ssl_private.h b/native/include/ssl_private.h
> index fc0f6ba9b..4d99ece20 100644
> --- a/native/include/ssl_private.h
> +++ b/native/include/ssl_private.h
> @@ -242,10 +242,6 @@ extern ENGINE *tcn_ssl_engine;
>   #define TLS_server_method                SSLv23_server_method
>   #endif /* OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) */
>   
> -#if OPENSSL_VERSION_NUMBER >= 0x10101000L && !defined(LIBRESSL_VERSION_NUMBER)
> -#define HAVE_KEYLOG_CALLBACK
> -#endif
> -
>   #define MAX_ALPN_PROTO_SIZE 65535
>   #define SSL_SELECTOR_FAILURE_CHOOSE_MY_LAST_PROTOCOL            1
>   
> @@ -392,9 +388,7 @@ int         SSL_CTX_use_certificate_chain(SSL_CTX *, const char *, int);
>   int         SSL_callback_SSL_verify(int, X509_STORE_CTX *);
>   int         SSL_rand_seed(const char *file);
>   int         SSL_callback_alpn_select_proto(SSL *, const unsigned char **, unsigned char *, const unsigned char *, unsigned int, void *);
> -#ifdef HAVE_KEYLOG_CALLBACK
>   void        SSL_callback_add_keylog(SSL_CTX *);
> -#endif
>   
>   #if (OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)) && ! (defined(WIN32) || defined(WIN64))
>   unsigned long SSL_ERR_get(void);
> diff --git a/native/src/ssl.c b/native/src/ssl.c
> index c48cb4247..fa8209cbe 100644
> --- a/native/src/ssl.c
> +++ b/native/src/ssl.c
> @@ -29,7 +29,6 @@ extern apr_pool_t *tcn_global_pool;
>   ENGINE *tcn_ssl_engine = NULL;
>   tcn_pass_cb_t tcn_password_callback;
>   
> -#ifdef HAVE_KEYLOG_CALLBACK
>   static BIO *key_log_file = NULL;
>   
>   static void ssl_keylog_callback(const SSL *ssl, const char *line)
> @@ -39,7 +38,6 @@ static void ssl_keylog_callback(const SSL *ssl, const char *line)
>           BIO_puts(key_log_file, "\n");
>       }
>   }
> -#endif
>   
>   /* From netty-tcnative */
>   static jclass byteArrayClass;
> @@ -293,14 +291,12 @@ static void free_dh_params(void)
>       }
>   }
>   
> -#ifdef HAVE_KEYLOG_CALLBACK
>   void SSL_callback_add_keylog(SSL_CTX *ctx)
>   {
>       if (key_log_file) {
>           SSL_CTX_set_keylog_callback(ctx, ssl_keylog_callback);
>       }
>   }
> -#endif
>   
>   /* Hand out the same DH structure though once generated as we leak
>    * memory otherwise and freeing the structure up after use would be
> @@ -401,12 +397,10 @@ static apr_status_t ssl_init_cleanup(void *data)
>   #endif
>   #endif
>   
> -#ifdef HAVE_KEYLOG_CALLBACK
>       if (key_log_file) {
>           BIO_free(key_log_file);
>           key_log_file = NULL;
>       }
> -#endif
>   
>       /* Don't call ERR_free_strings here; ERR_load_*_strings only
>        * actually load the error strings once per process due to static
> @@ -863,7 +857,6 @@ TCN_IMPLEMENT_CALL(jint, SSL, initialize)(TCN_STDARGS, jstring engine)
>       sClazz = (*e)->FindClass(e, "java/lang/String");
>       stringClass = (jclass) (*e)->NewGlobalRef(e, sClazz);
>   
> -#ifdef HAVE_KEYLOG_CALLBACK
>       if (!key_log_file) {
>           char *key_log_file_name = getenv("SSLKEYLOGFILE");
>           if (key_log_file_name) {
> @@ -877,7 +870,6 @@ TCN_IMPLEMENT_CALL(jint, SSL, initialize)(TCN_STDARGS, jstring engine)
>               }
>           }
>       }
> -#endif
>   
>       return (jint)APR_SUCCESS;
>   }
> diff --git a/native/src/sslcontext.c b/native/src/sslcontext.c
> index b69b4480f..80a252021 100644
> --- a/native/src/sslcontext.c
> +++ b/native/src/sslcontext.c
> @@ -325,9 +325,7 @@ TCN_IMPLEMENT_CALL(jlong, SSLContext, make)(TCN_STDARGS, jlong pool,
>           goto init_failed;
>       }
>   
> -#ifdef HAVE_KEYLOG_CALLBACK
>       SSL_callback_add_keylog(ctx);
> -#endif
>   
>       c->protocol = protocol;
>       c->mode     = mode;
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 

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