You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2016/04/18 16:37:55 UTC
Time for tc-native 1.2.6
I'd like to get the next tc-native release out before the end of the
month so the next round of Tomcat releases can pick it up - particularly
the cert chain from Java keystore fix.
I'm intending to tag in ~24 hours. Please reply if you need me to delay.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Time for tc-native 1.2.6
Posted by Rémy Maucherat <re...@apache.org>.
2016-04-18 16:37 GMT+02:00 Mark Thomas <ma...@apache.org>:
> I'd like to get the next tc-native release out before the end of the
> month so the next round of Tomcat releases can pick it up - particularly
> the cert chain from Java keystore fix.
>
> I'm intending to tag in ~24 hours. Please reply if you need me to delay.
>
> +1 !
Rémy
Re: Time for tc-native 1.2.6
Posted by Rainer Jung <ra...@kippdata.de>.
Am 19.04.2016 um 12:17 schrieb Rainer Jung:
> Am 19.04.2016 um 11:35 schrieb Rainer Jung:
>> I just now saw, that there's again an API break for OpenSSL 1.1.0.
>>
>> I'll try to fix that during the next hour.
>
> I don't understand the Gump failure for tcnative trunk which happened
> this night. The errors look like tcnative trunk has been compiled
> against a mixture of header files from OpenSSL master and older, but the
> OpenSSL build logs on Gump don't indicate any such error.
>
> For example the first build error was:
>
> /bin/bash /srv/gump/public/workspace/apr-1/dest-20160419/build-1/libtool
> --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX
> -D_REENTRANT -D_GNU_SOURCE -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP
> -I/srv/gump/public/workspace/tomcat-native-trunk/native/include
> -I/usr/lib/jvm/java-8-oracle/include
> -I/usr/lib/jvm/java-8-oracle/include/linux
> -I/srv/gump/public/workspace/openssl-master/dest-20160419/include
> -I/srv/gump/public/workspace/apr-1/dest-20160419/include/apr-1 -o
> src/ssl.lo -c src/ssl.c && touch src/ssl.lo
>
> In file included from src/ssl.c:17:0:
> src/ssl.c: In function 'Java_org_apache_tomcat_jni_SSL_versionString':
> src/ssl.c:312:43: error: 'OPENSSL_VERSION' undeclared (first use in this
> function)
> return AJP_TO_JSTRING(OpenSSL_version(OPENSSL_VERSION));
>
> But the OpenSSL master snapshots for 20160418 and 20140619 contain the line
>
> # define OPENSSL_VERSION 0
>
> in openssl/crypto.h and there have been no more recent changes to the
> OpenSSL master on github from which Gump gets its files.
Konstantin has pointed out on otherthread, that Gump has some issues
with stale git pulled resources currently. The build failures during
last night look to me, as they wouldn't happen with a recent OpenSSL
master checkout (and they don't happen for me locally).
So IMHO we are good to go.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Time for tc-native 1.2.6
Posted by Rainer Jung <ra...@kippdata.de>.
Am 19.04.2016 um 11:35 schrieb Rainer Jung:
> I just now saw, that there's again an API break for OpenSSL 1.1.0.
>
> I'll try to fix that during the next hour.
I don't understand the Gump failure for tcnative trunk which happened
this night. The errors look like tcnative trunk has been compiled
against a mixture of header files from OpenSSL master and older, but the
OpenSSL build logs on Gump don't indicate any such error.
For example the first build error was:
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160419/build-1/libtool
--silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX
-D_REENTRANT -D_GNU_SOURCE -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include
-I/usr/lib/jvm/java-8-oracle/include
-I/usr/lib/jvm/java-8-oracle/include/linux
-I/srv/gump/public/workspace/openssl-master/dest-20160419/include
-I/srv/gump/public/workspace/apr-1/dest-20160419/include/apr-1 -o
src/ssl.lo -c src/ssl.c && touch src/ssl.lo
In file included from src/ssl.c:17:0:
src/ssl.c: In function 'Java_org_apache_tomcat_jni_SSL_versionString':
src/ssl.c:312:43: error: 'OPENSSL_VERSION' undeclared (first use in this
function)
return AJP_TO_JSTRING(OpenSSL_version(OPENSSL_VERSION));
But the OpenSSL master snapshots for 20160418 and 20140619 contain the line
# define OPENSSL_VERSION 0
in openssl/crypto.h and there have been no more recent changes to the
OpenSSL master on github from which Gump gets its files.
I found another API change which I fixed in r1739889, but that was not
related.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Time for tc-native 1.2.6
Posted by Rainer Jung <ra...@kippdata.de>.
I just now saw, that there's again an API break for OpenSSL 1.1.0.
I'll try to fix that during the next hour.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Time for tc-native 1.2.6
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.04.2016 um 18:13 schrieb Rainer Jung:
> Am 18.04.2016 um 17:28 schrieb jean-frederic clere:
>> On 04/18/2016 05:03 PM, Rainer Jung wrote:
>>> Hi Mark,
>>>
>>> Am 18.04.2016 um 16:37 schrieb Mark Thomas:
>>>> I'd like to get the next tc-native release out before the end of the
>>>> month so the next round of Tomcat releases can pick it up -
>>>> particularly
>>>> the cert chain from Java keystore fix.
>>>>
>>>> I'm intending to tag in ~24 hours. Please reply if you need me to
>>>> delay.
>>>
>>> Current code status:
>>>
>>> a) I tried to keep compatibility with OpenSSL 1.0.2 all the time. Any
>>> breaks would be unintended. At least things compiled here. More eyes and
>>> tests for the changes applied since 1.2.5 are very welcome.
>>>
>>> b) it will not compile with against latest OpenSSL 1.1.0 beta, because
>>> to stay compatible with 1.1.0 head we had to use more recent OpenSSL
>>> functions introduced after the last beta
>>>
>>> c) it will not compile with the latest OpenSSL 1.1.0 snapshot either,
>>> because I haven't yet found a solution to an API change only introduced
>>> last week
>>>
>>> I'll see whether I find a fix for c) so that the release would at least
>>> work with a current OpenSSL 1.1.0 snapshot. Even if not, I think you can
>>> release, because OpenSSL 1.1.0 head still doesn't seem to be API stable,
>>> so we are not at the end of changes anyhows.
>>>
>>> Background infoRecently there was another opaqueness change in OpenSSL
>>> 1.1.0 head. There's one incompatibility remaining between tcnative head
>>> and OpenSSL 1.1.0 head for which I didn't find an immediate replacement.
>>> So compiling against latest 1.1.0 snapshots will result in a compilation
>>> error in ssl_verify_CRL().
>>>
>>> The CRL handling code is very different from what we can find in OpenSSL
>>> example/apps code and it could well be, that we should replace a bigger
>>> part of that code with some pre-cooked cert validation function (call)
>>> in OpenSSL.
>>
>> Is mod_ssl also affected by those API changes?
>
> Not 2.4, but our code seems to go back to 2.2. The code has
> significantly changed for 2.4 in r1165056 which is likely the change we
> will adopt as well.
Done in r1739875.
There's lots of changes in the OCSP code in mod_ssl we might want to
take over. I don't plan to work on this (or any other change) before 1.2.6.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Time for tc-native 1.2.6
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.04.2016 um 18:13 schrieb Rainer Jung:
> Am 18.04.2016 um 17:28 schrieb jean-frederic clere:
>> On 04/18/2016 05:03 PM, Rainer Jung wrote:
>>> Hi Mark,
>>>
>>> Am 18.04.2016 um 16:37 schrieb Mark Thomas:
>>>> I'd like to get the next tc-native release out before the end of the
>>>> month so the next round of Tomcat releases can pick it up -
>>>> particularly
>>>> the cert chain from Java keystore fix.
>>>>
>>>> I'm intending to tag in ~24 hours. Please reply if you need me to
>>>> delay.
>>>
>>> Current code status:
>>>
>>> a) I tried to keep compatibility with OpenSSL 1.0.2 all the time. Any
>>> breaks would be unintended. At least things compiled here. More eyes and
>>> tests for the changes applied since 1.2.5 are very welcome.
>>>
>>> b) it will not compile with against latest OpenSSL 1.1.0 beta, because
>>> to stay compatible with 1.1.0 head we had to use more recent OpenSSL
>>> functions introduced after the last beta
>>>
>>> c) it will not compile with the latest OpenSSL 1.1.0 snapshot either,
>>> because I haven't yet found a solution to an API change only introduced
>>> last week
>>>
>>> I'll see whether I find a fix for c) so that the release would at least
>>> work with a current OpenSSL 1.1.0 snapshot. Even if not, I think you can
>>> release, because OpenSSL 1.1.0 head still doesn't seem to be API stable,
>>> so we are not at the end of changes anyhows.
>>>
>>> Background infoRecently there was another opaqueness change in OpenSSL
>>> 1.1.0 head. There's one incompatibility remaining between tcnative head
>>> and OpenSSL 1.1.0 head for which I didn't find an immediate replacement.
>>> So compiling against latest 1.1.0 snapshots will result in a compilation
>>> error in ssl_verify_CRL().
>>>
>>> The CRL handling code is very different from what we can find in OpenSSL
>>> example/apps code and it could well be, that we should replace a bigger
>>> part of that code with some pre-cooked cert validation function (call)
>>> in OpenSSL.
>>
>> Is mod_ssl also affected by those API changes?
>
> Not 2.4, but our code seems to go back to 2.2. The code has
> significantly changed for 2.4 in r1165056 which is likely the change we
> will adopt as well.
The reason for that change was sent by Kaspar Brand on 2011-07-31:
===================
I'm considering cleaning up some of the cert revocation checking code in
mod_ssl, in particular ssl_callback_SSLVerify_CRL(), which currently has
the following comment:
* OpenSSL provides the general mechanism to deal with CRLs but does not
* use them automatically when verifying certificates, so we do it
* explicitly here. We will check the CRL for the currently checked
* certificate, if there is such a CRL in the store.
This was true in 1999 when CRL support was originally added to mod_ssl
by rse, but times have changed - CRL checking support was introduced
with OpenSSL 0.9.7, released in December 2002
(http://cvs.openssl.org/chngview?cn=4670).
===================
So we've got quite some unfortunate code drift between where our code
originally came from and what's there today.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Time for tc-native 1.2.6
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.04.2016 um 17:28 schrieb jean-frederic clere:
> On 04/18/2016 05:03 PM, Rainer Jung wrote:
>> Hi Mark,
>>
>> Am 18.04.2016 um 16:37 schrieb Mark Thomas:
>>> I'd like to get the next tc-native release out before the end of the
>>> month so the next round of Tomcat releases can pick it up - particularly
>>> the cert chain from Java keystore fix.
>>>
>>> I'm intending to tag in ~24 hours. Please reply if you need me to delay.
>>
>> Current code status:
>>
>> a) I tried to keep compatibility with OpenSSL 1.0.2 all the time. Any
>> breaks would be unintended. At least things compiled here. More eyes and
>> tests for the changes applied since 1.2.5 are very welcome.
>>
>> b) it will not compile with against latest OpenSSL 1.1.0 beta, because
>> to stay compatible with 1.1.0 head we had to use more recent OpenSSL
>> functions introduced after the last beta
>>
>> c) it will not compile with the latest OpenSSL 1.1.0 snapshot either,
>> because I haven't yet found a solution to an API change only introduced
>> last week
>>
>> I'll see whether I find a fix for c) so that the release would at least
>> work with a current OpenSSL 1.1.0 snapshot. Even if not, I think you can
>> release, because OpenSSL 1.1.0 head still doesn't seem to be API stable,
>> so we are not at the end of changes anyhows.
>>
>> Background infoRecently there was another opaqueness change in OpenSSL
>> 1.1.0 head. There's one incompatibility remaining between tcnative head
>> and OpenSSL 1.1.0 head for which I didn't find an immediate replacement.
>> So compiling against latest 1.1.0 snapshots will result in a compilation
>> error in ssl_verify_CRL().
>>
>> The CRL handling code is very different from what we can find in OpenSSL
>> example/apps code and it could well be, that we should replace a bigger
>> part of that code with some pre-cooked cert validation function (call)
>> in OpenSSL.
>
> Is mod_ssl also affected by those API changes?
Not 2.4, but our code seems to go back to 2.2. The code has
significantly changed for 2.4 in r1165056 which is likely the change we
will adopt as well.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Time for tc-native 1.2.6
Posted by jean-frederic clere <jf...@gmail.com>.
On 04/18/2016 05:03 PM, Rainer Jung wrote:
> Hi Mark,
>
> Am 18.04.2016 um 16:37 schrieb Mark Thomas:
>> I'd like to get the next tc-native release out before the end of the
>> month so the next round of Tomcat releases can pick it up - particularly
>> the cert chain from Java keystore fix.
>>
>> I'm intending to tag in ~24 hours. Please reply if you need me to delay.
>
> Current code status:
>
> a) I tried to keep compatibility with OpenSSL 1.0.2 all the time. Any
> breaks would be unintended. At least things compiled here. More eyes and
> tests for the changes applied since 1.2.5 are very welcome.
>
> b) it will not compile with against latest OpenSSL 1.1.0 beta, because
> to stay compatible with 1.1.0 head we had to use more recent OpenSSL
> functions introduced after the last beta
>
> c) it will not compile with the latest OpenSSL 1.1.0 snapshot either,
> because I haven't yet found a solution to an API change only introduced
> last week
>
> I'll see whether I find a fix for c) so that the release would at least
> work with a current OpenSSL 1.1.0 snapshot. Even if not, I think you can
> release, because OpenSSL 1.1.0 head still doesn't seem to be API stable,
> so we are not at the end of changes anyhows.
>
> Background infoRecently there was another opaqueness change in OpenSSL
> 1.1.0 head. There's one incompatibility remaining between tcnative head
> and OpenSSL 1.1.0 head for which I didn't find an immediate replacement.
> So compiling against latest 1.1.0 snapshots will result in a compilation
> error in ssl_verify_CRL().
>
> The CRL handling code is very different from what we can find in OpenSSL
> example/apps code and it could well be, that we should replace a bigger
> part of that code with some pre-cooked cert validation function (call)
> in OpenSSL.
Is mod_ssl also affected by those API changes?
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Time for tc-native 1.2.6
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Mark,
Am 18.04.2016 um 16:37 schrieb Mark Thomas:
> I'd like to get the next tc-native release out before the end of the
> month so the next round of Tomcat releases can pick it up - particularly
> the cert chain from Java keystore fix.
>
> I'm intending to tag in ~24 hours. Please reply if you need me to delay.
Current code status:
a) I tried to keep compatibility with OpenSSL 1.0.2 all the time. Any
breaks would be unintended. At least things compiled here. More eyes and
tests for the changes applied since 1.2.5 are very welcome.
b) it will not compile with against latest OpenSSL 1.1.0 beta, because
to stay compatible with 1.1.0 head we had to use more recent OpenSSL
functions introduced after the last beta
c) it will not compile with the latest OpenSSL 1.1.0 snapshot either,
because I haven't yet found a solution to an API change only introduced
last week
I'll see whether I find a fix for c) so that the release would at least
work with a current OpenSSL 1.1.0 snapshot. Even if not, I think you can
release, because OpenSSL 1.1.0 head still doesn't seem to be API stable,
so we are not at the end of changes anyhows.
Background infoRecently there was another opaqueness change in OpenSSL
1.1.0 head. There's one incompatibility remaining between tcnative head
and OpenSSL 1.1.0 head for which I didn't find an immediate replacement.
So compiling against latest 1.1.0 snapshots will result in a compilation
error in ssl_verify_CRL().
The CRL handling code is very different from what we can find in OpenSSL
example/apps code and it could well be, that we should replace a bigger
part of that code with some pre-cooked cert validation function (call)
in OpenSSL.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org