Re: Position on failing tests with vendor-modified OpenSSL packages

2020-04-28 Thread Michael Osipov

Am 2020-04-24 um 01:45 schrieb Michael Osipov:

Folks,

I run test from Tomcat master and libtcnative master on FreeBSD, RHEL 7 
and HP-UX 11.31 on a regular basis and noticed that the OpenSSL 1.0.2 
packages provided by Red Hat and HPE are modified which make several 
tests fail. See an excerpt here [1].
To verify this I have compiled OpenSSL from OpenSSL_1_0_2-stable on 
FreeBSD w/o any modification and all tests pass, so other must have 
modified OpenSSL.


What is our position in terms of support/testing for modified OpenSSL 
packages from OS vendors? Should we add a big fat warning somewhere? Add 
this to tcnative README that we test/recommend upstream only?


[1] http://home.apache.org/~michaelo/issues/openssl-tests/


I have now managed to installed OpenSSL 1.1.1 from OS vendor. It 
contains modifications too: 
http://home.apache.org/~michaelo/issues/openssl-1.1.1-tests/hpux/


M

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



Re: Position on failing tests with vendor-modified OpenSSL packages

2020-04-27 Thread Mark Thomas
On 26/04/2020 10:36, Michael Osipov wrote:
> Am 2020-04-24 um 18:30 schrieb Christopher Schultz:



>> This comes down to algorithms which have been compiled-out of the
>> library, right? So we just need to automatically skip tests which
>> attempt to use those algorithms.

Not entirely. We are affected both by algorithms being removed and
algorithms being added.

>> Unfortunately, the whole point of the unit tests is to make sure we
>> haven't missed anything. In order to both remove unsupported
>> algorithms AND test whether the remaining algorithms are
>> properly-mapped, we need ANOTHER implementation of the mapping, or
>> something similar to cross-check the two.

I think I agree with this. If you mean that somewhere we would need to
maintain a list of algorithms there were supported by the vendor
modified package then, yes I agree. The tricky part being that we can't
always identify what is a vendor modified package.

>> Somewhere, we have a /complete/ list of OpenSSL-specified names that
>> we support.

Ciphers is an enumeration of all the Ciphers OpenSSL supports or has
supported in the past.

In TesterOpenSSL we modify that list to remove Ciphers we know are not
supported in the version we are testing.

>> That can easily be dumped somewhere and sorted
>> alphabetically. Then, "openssl ciphers 'ALL'" can be run, sorted, and
>> compared to the sorted list we have.

"ALL" does not return all supported ciphers. Sigh. You need to use
"ALL:eNULL"

>> Anything which isn't in the
>> "openssl ciphers 'ALL'" list can be removed from the list of cipher
>> suites we test.

The problem is, that is how we detected that the list of supported
Cipher suites has changed for a given OpenSSL branch (yes it can change
between point releases).

>> AIUI, it's possible to individually-remove a cipher suite from the
>> unit tests if it's known to be missing on the platform. We just need
>> to make that process automated, right?
> 
> Up to the point! That's exactly the route one should go.

We would need to clearly separate (from memory I don't recall how clear
the separation is right now):

- Tests that compare the ciphers we think a version of OpenSSL supports
  with the ciphers it reports it supports. These only need to run when
  testing with an unmodified OpenSSL from openssl.org
- Tests just need to know which ciphers OpenSSL supports and, as long as
  they have the correct list, will always pass

Mark

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



Re: Position on failing tests with vendor-modified OpenSSL packages

2020-04-26 Thread Michael Osipov

Am 2020-04-24 um 18:30 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark and Michael,

On 4/24/20 07:24, Michael Osipov wrote:

Am 2020-04-24 um 08:57 schrieb Mark Thomas:

On 24/04/2020 00:45, Michael Osipov wrote:

Folks,

I run test from Tomcat master and libtcnative master on
FreeBSD, RHEL 7 and HP-UX 11.31 on a regular basis and noticed
that the OpenSSL 1.0.2 packages provided by Red Hat and HPE are
modified which make several tests fail. See an excerpt here
[1]. To verify this I have compiled OpenSSL from
OpenSSL_1_0_2-stable on FreeBSD w/o any modification and all
tests pass, so other must have modified OpenSSL.

What is our position in terms of support/testing for modified
OpenSSL packages from OS vendors? Should we add a big fat
warning somewhere? Add this to tcnative README that we
test/recommend upstream only?


The good news is that the tests that are failing are the ones I
would expect to fail.

When we added the code that lets us use OpenSSL syntax to define
ciphers for JSSE (and JSSE syntax to define ciphers for OpenSSL)
we added a these tests to ensure that we correctly tracked things
like "ALL", "DEFAULT" as well as "ECDHE" etc. These are a moving
target as support for new ciphers is added and ciphers viewed as
less secure are removed.

Our unit tests aim to work with the current version of all
publicly supported OpenSSL branches. Currently, master (3.0.x)
and 1.1.1.

I expect the vendor supported 1.0.2 packages are close to current
1.1.1 but I wouldn't be surprised to see some minor differences.

I think we have several options: - document the expectation more
clearly so folks can more easily assess these failures - support
using the vendor supported versions with the unit tests - provide
a configuration option to skip these tests - detect vendor
supplied OpenSSL and automatically skip the tests


We need to do at least the documentation. As for detectection and
support: I consider this to be hardly solvable because there is no
identifier in "openssl version -a" which says I have been modified
by X. See:


$ openssl version -a OpenSSL 1.0.2r  26 Feb 2019 built on:
reproducible build, date unspecified platform: hpux-ia64-cc
options:  bn(64,64) rc4(idx,int) des(idx,risc1,16,long)
blowfish(idx) compiler: cc -I. -I.. -I../include
-I/ssh_ssl_build/ssl-build/OpenSSL_1_0_FIPS_205/build/zlib +Z
-DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS  -DDSO_DLFCN
-DHAVE_DLFCN_H -D_REENTRANT -Ae +DD32 +O2 +Olit=all -z -DB_ENDIAN
-D_REENTRANT -DOPENSSL_BN_ASM_MONT -DRC4_ASM -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM
OPENSSLDIR: "/opt/openssl"


and


$ openssl version -a OpenSSL 1.0.2k-fips  26 Jan 2017 built on:
reproducible build, date unspecified platform: linux-x86_64
options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int)
idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include
-fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches   -m64 -mtune=generic -Wa,--noexecstack
-DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/etc/pki/tls" engines:  rdrand dynamic


The only option I see is to check for OS name/LSB release, call
with depdency graph with ldd and check for libssl/libcrypto in
default locations, but this is really really ugly.

Compared to OpenSSL 1.1.1 from FreeBSD base and OpenSSL 1.0.2
compiled myself:

$ openssl version -a OpenSSL 1.1.1e-freebsd  17 Mar 2020 built
on: reproducible build, date unspecified platform: FreeBSD-amd64
options:  bn(64,64) rc4(16x,int) des(int) idea(int)
blowfish(ptr) compiler: clang OPENSSLDIR: "/etc/ssl" ENGINESDIR:
"/usr/lib/engines" Seeding source: os-specific


Granted, this one says in the version string it is from FreeBSD.


$ /tmp/openssl-1.0.2/bin/openssl version -a OpenSSL 1.0.2v-dev
xx XXX  built on: reproducible build, date unspecified
platform: BSD-x86_64 options:  bn(64,64) rc4(16x,int)
des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: cc -I.
-I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread
-D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN
-O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/tmp/openssl-1.0.2/ssl"



There are probably a few options I've missed.

I will add at this point that debugging a failure and figuring
out the right fix hasn't always easy.

I'm currently wondering if some sort of combination of the above
might work. Detect vendor variations, handle them 

Re: Position on failing tests with vendor-modified OpenSSL packages

2020-04-24 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark and Michael,

On 4/24/20 07:24, Michael Osipov wrote:
> Am 2020-04-24 um 08:57 schrieb Mark Thomas:
>> On 24/04/2020 00:45, Michael Osipov wrote:
>>> Folks,
>>>
>>> I run test from Tomcat master and libtcnative master on
>>> FreeBSD, RHEL 7 and HP-UX 11.31 on a regular basis and noticed
>>> that the OpenSSL 1.0.2 packages provided by Red Hat and HPE are
>>> modified which make several tests fail. See an excerpt here
>>> [1]. To verify this I have compiled OpenSSL from
>>> OpenSSL_1_0_2-stable on FreeBSD w/o any modification and all
>>> tests pass, so other must have modified OpenSSL.
>>>
>>> What is our position in terms of support/testing for modified
>>> OpenSSL packages from OS vendors? Should we add a big fat
>>> warning somewhere? Add this to tcnative README that we
>>> test/recommend upstream only?
>>
>> The good news is that the tests that are failing are the ones I
>> would expect to fail.
>>
>> When we added the code that lets us use OpenSSL syntax to define
>> ciphers for JSSE (and JSSE syntax to define ciphers for OpenSSL)
>> we added a these tests to ensure that we correctly tracked things
>> like "ALL", "DEFAULT" as well as "ECDHE" etc. These are a moving
>> target as support for new ciphers is added and ciphers viewed as
>> less secure are removed.
>>
>> Our unit tests aim to work with the current version of all
>> publicly supported OpenSSL branches. Currently, master (3.0.x)
>> and 1.1.1.
>>
>> I expect the vendor supported 1.0.2 packages are close to current
>> 1.1.1 but I wouldn't be surprised to see some minor differences.
>>
>> I think we have several options: - document the expectation more
>> clearly so folks can more easily assess these failures - support
>> using the vendor supported versions with the unit tests - provide
>> a configuration option to skip these tests - detect vendor
>> supplied OpenSSL and automatically skip the tests
>
> We need to do at least the documentation. As for detectection and
> support: I consider this to be hardly solvable because there is no
> identifier in "openssl version -a" which says I have been modified
> by X. See:
>
>> $ openssl version -a OpenSSL 1.0.2r  26 Feb 2019 built on:
>> reproducible build, date unspecified platform: hpux-ia64-cc
>> options:  bn(64,64) rc4(idx,int) des(idx,risc1,16,long)
>> blowfish(idx) compiler: cc -I. -I.. -I../include
>> -I/ssh_ssl_build/ssl-build/OpenSSL_1_0_FIPS_205/build/zlib +Z
>> -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS  -DDSO_DLFCN
>> -DHAVE_DLFCN_H -D_REENTRANT -Ae +DD32 +O2 +Olit=all -z -DB_ENDIAN
>> -D_REENTRANT -DOPENSSL_BN_ASM_MONT -DRC4_ASM -DSHA1_ASM
>> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM
>> OPENSSLDIR: "/opt/openssl"
>
> and
>
>> $ openssl version -a OpenSSL 1.0.2k-fips  26 Jan 2017 built on:
>> reproducible build, date unspecified platform: linux-x86_64
>> options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int)
>> idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include
>> -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2
>> -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>> -fstack-protector-strong --param=ssp-buffer-size=4
>> -grecord-gcc-switches   -m64 -mtune=generic -Wa,--noexecstack
>> -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
>> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM
>> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
>> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
>> OPENSSLDIR: "/etc/pki/tls" engines:  rdrand dynamic
>
> The only option I see is to check for OS name/LSB release, call
> with depdency graph with ldd and check for libssl/libcrypto in
> default locations, but this is really really ugly.
>
> Compared to OpenSSL 1.1.1 from FreeBSD base and OpenSSL 1.0.2
> compiled myself:
>> $ openssl version -a OpenSSL 1.1.1e-freebsd  17 Mar 2020 built
>> on: reproducible build, date unspecified platform: FreeBSD-amd64
>> options:  bn(64,64) rc4(16x,int) des(int) idea(int)
>> blowfish(ptr) compiler: clang OPENSSLDIR: "/etc/ssl" ENGINESDIR:
>> "/usr/lib/engines" Seeding source: os-specific
>
> Granted, this one says in the version string it is from FreeBSD.
>
>> $ /tmp/openssl-1.0.2/bin/openssl version -a OpenSSL 1.0.2v-dev
>> xx XXX  built on: reproducible build, date unspecified
>> platform: BSD-x86_64 options:  bn(64,64) rc4(16x,int)
>> des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: cc -I.
>> -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread
>> -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN
>> -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
>> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM
>> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
>> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
>> OPENSSLDIR: "/tmp/openssl-1.0.2/ssl"
>
>> There are probably a few options I've missed.
>>
>> I 

Re: Position on failing tests with vendor-modified OpenSSL packages

2020-04-24 Thread Mark Thomas
On 24/04/2020 12:24, Michael Osipov wrote:
> Am 2020-04-24 um 08:57 schrieb Mark Thomas:



>> I think we have several options:
>> - document the expectation more clearly so folks can more easily assess
>>    these failures
>> - support using the vendor supported versions with the unit tests
>> - provide a configuration option to skip these tests
>> - detect vendor supplied OpenSSL and automatically skip the tests
> 
> We need to do at least the documentation. As for detectection and
> support: I consider this to be hardly solvable because there is no
> identifier in "openssl version -a" which says I have been modified by X.

That is unhelpful to say the least.

Looks like better docs and an option to skip is the way to go.

Mark

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



Re: Position on failing tests with vendor-modified OpenSSL packages

2020-04-24 Thread Michael Osipov

Am 2020-04-24 um 08:57 schrieb Mark Thomas:

On 24/04/2020 00:45, Michael Osipov wrote:

Folks,

I run test from Tomcat master and libtcnative master on FreeBSD, RHEL 7
and HP-UX 11.31 on a regular basis and noticed that the OpenSSL 1.0.2
packages provided by Red Hat and HPE are modified which make several
tests fail. See an excerpt here [1].
To verify this I have compiled OpenSSL from OpenSSL_1_0_2-stable on
FreeBSD w/o any modification and all tests pass, so other must have
modified OpenSSL.

What is our position in terms of support/testing for modified OpenSSL
packages from OS vendors? Should we add a big fat warning somewhere? Add
this to tcnative README that we test/recommend upstream only?


The good news is that the tests that are failing are the ones I would
expect to fail.

When we added the code that lets us use OpenSSL syntax to define ciphers
for JSSE (and JSSE syntax to define ciphers for OpenSSL) we added a
these tests to ensure that we correctly tracked things like "ALL",
"DEFAULT" as well as "ECDHE" etc. These are a moving target as support
for new ciphers is added and ciphers viewed as less secure are removed.

Our unit tests aim to work with the current version of all publicly
supported OpenSSL branches. Currently, master (3.0.x) and 1.1.1.

I expect the vendor supported 1.0.2 packages are close to current 1.1.1
but I wouldn't be surprised to see some minor differences.

I think we have several options:
- document the expectation more clearly so folks can more easily assess
   these failures
- support using the vendor supported versions with the unit tests
- provide a configuration option to skip these tests
- detect vendor supplied OpenSSL and automatically skip the tests


We need to do at least the documentation. As for detectection and 
support: I consider this to be hardly solvable because there is no 
identifier in "openssl version -a" which says I have been modified by X.

See:


$ openssl version -a
OpenSSL 1.0.2r  26 Feb 2019
built on: reproducible build, date unspecified
platform: hpux-ia64-cc
options:  bn(64,64) rc4(idx,int) des(idx,risc1,16,long) blowfish(idx)
compiler: cc -I. -I.. -I../include 
-I/ssh_ssl_build/ssl-build/OpenSSL_1_0_FIPS_205/build/zlib +Z -DOPENSSL_PIC 
-DZLIB -DOPENSSL_THREADS  -DDSO_DLFCN -DHAVE_DLFCN_H -D_REENTRANT -Ae +DD32 +O2 
+Olit=all -z -DB_ENDIAN -D_REENTRANT -DOPENSSL_BN_ASM_MONT -DRC4_ASM -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM
OPENSSLDIR: "/opt/openssl"


and


$ openssl version -a
OpenSSL 1.0.2k-fips  26 Jan 2017
built on: reproducible build, date unspecified
platform: linux-x86_64
options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) 
blowfish(idx)
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 
-DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 
-mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/etc/pki/tls"
engines:  rdrand dynamic


The only option I see is to check for OS name/LSB release, call with 
depdency graph with ldd and check for libssl/libcrypto in default 
locations, but this is really really ugly.


Compared to OpenSSL 1.1.1 from FreeBSD base and OpenSSL 1.0.2 compiled 
myself:

$ openssl version -a
OpenSSL 1.1.1e-freebsd  17 Mar 2020
built on: reproducible build, date unspecified
platform: FreeBSD-amd64
options:  bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr)
compiler: clang
OPENSSLDIR: "/etc/ssl"
ENGINESDIR: "/usr/lib/engines"
Seeding source: os-specific


Granted, this one says in the version string it is from FreeBSD.


$ /tmp/openssl-1.0.2/bin/openssl version -a
OpenSSL 1.0.2v-dev  xx XXX 
built on: reproducible build, date unspecified
platform: BSD-x86_64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS 
-pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 
-Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/tmp/openssl-1.0.2/ssl"



There are probably a few options I've missed.

I will add at this point that debugging a failure and figuring out the
right fix hasn't always easy.

I'm currently wondering if some sort of combination of the above might
work. Detect vendor variations, handle them where we can recognise them
and skip them where we don't.

I think this needs some further thought.


Please let me know if you need 

Re: Position on failing tests with vendor-modified OpenSSL packages

2020-04-24 Thread Mark Thomas
On 24/04/2020 00:45, Michael Osipov wrote:
> Folks,
> 
> I run test from Tomcat master and libtcnative master on FreeBSD, RHEL 7
> and HP-UX 11.31 on a regular basis and noticed that the OpenSSL 1.0.2
> packages provided by Red Hat and HPE are modified which make several
> tests fail. See an excerpt here [1].
> To verify this I have compiled OpenSSL from OpenSSL_1_0_2-stable on
> FreeBSD w/o any modification and all tests pass, so other must have
> modified OpenSSL.
> 
> What is our position in terms of support/testing for modified OpenSSL
> packages from OS vendors? Should we add a big fat warning somewhere? Add
> this to tcnative README that we test/recommend upstream only?

The good news is that the tests that are failing are the ones I would
expect to fail.

When we added the code that lets us use OpenSSL syntax to define ciphers
for JSSE (and JSSE syntax to define ciphers for OpenSSL) we added a
these tests to ensure that we correctly tracked things like "ALL",
"DEFAULT" as well as "ECDHE" etc. These are a moving target as support
for new ciphers is added and ciphers viewed as less secure are removed.

Our unit tests aim to work with the current version of all publicly
supported OpenSSL branches. Currently, master (3.0.x) and 1.1.1.

I expect the vendor supported 1.0.2 packages are close to current 1.1.1
but I wouldn't be surprised to see some minor differences.

I think we have several options:
- document the expectation more clearly so folks can more easily assess
  these failures
- support using the vendor supported versions with the unit tests
- provide a configuration option to skip these tests
- detect vendor supplied OpenSSL and automatically skip the tests

There are probably a few options I've missed.

I will add at this point that debugging a failure and figuring out the
right fix hasn't always easy.

I'm currently wondering if some sort of combination of the above might
work. Detect vendor variations, handle them where we can recognise them
and skip them where we don't.

I think this needs some further thought.

Mark

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



Position on failing tests with vendor-modified OpenSSL packages

2020-04-23 Thread Michael Osipov

Folks,

I run test from Tomcat master and libtcnative master on FreeBSD, RHEL 7 
and HP-UX 11.31 on a regular basis and noticed that the OpenSSL 1.0.2 
packages provided by Red Hat and HPE are modified which make several 
tests fail. See an excerpt here [1].
To verify this I have compiled OpenSSL from OpenSSL_1_0_2-stable on 
FreeBSD w/o any modification and all tests pass, so other must have 
modified OpenSSL.


What is our position in terms of support/testing for modified OpenSSL 
packages from OS vendors? Should we add a big fat warning somewhere? Add 
this to tcnative README that we test/recommend upstream only?


[1] http://home.apache.org/~michaelo/issues/openssl-tests/

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