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 2018/09/12 11:12:55 UTC
Gump, Tomcat Native, OpenSSL and Tomcat versions
All,
Gump currently tests 7.0.x, 8.5.x and 9.0.x
Support for OpenSSL cipher names is available in 8.5.x onwards and we
have various unit tests to ensure that our parsing code remains in sync
with OpenSSL.
All versions have TLS unit tests that check the APR/Native connector is
working as expected.
OpenSSL currently has the following four active development branches:
Master (a.k.a. 1.1.2-dev)
1.1.1 (LTS supported until at least 2018-09-11
1.1.0 (supported until 2019-09-11)
1.0.2 (LTS supported until 2019-12-31)
Gump currently builds OpenSSL master and 1.0.2
Tomcat Native has two branches 1.2.x and 1.1.x.
1.1.x will reach EOL at the end of this month.
Gump currently builds
Native 1.1.x with OpenSSL 1.0.2
Native 1.2.x with OpenSSL 1.0.2
Native 1.2.x with OpenSSL master
Gump then tests
9.0.x with Native 1.2.x/OpenSSL master
8.5.x with Native 1.2.x/OpenSSL 1.0.2
7.0.x with Native 1.2.x/OpenSSL 1.0.2
We currently are only testing 3 out of a possible 24 combinations. If we
ignore Native 1.1.x then that becomes 3 out of a possible 12 combinations.
Do we want to change / increase / decrease the combinations we test?
As a starting point for discussion how about:
- Build all current OpenSSL versions (currently 4)
- Build Tomcat Native 1.2.x for each OpenSSL version (i.e. 4)
- No Tomcat Native 1.1.x builds
- Test 9.0.x with all Native/OpenSSL combinations (i.e. 4)
- Test 8.5.x with Native/OpenSSL 1.1.1 (latest LTS)
- Test 7.0.x with Native/OpenSSL 1.0.2 (other LTS)
Testing all 12 combinations (4 OpenSSL * 3 Tomcat) seems like overkill.
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Gump, Tomcat Native, OpenSSL and Tomcat versions
Posted by Mark Thomas <ma...@apache.org>.
On 12/09/18 22:20, Mark Thomas wrote:
<snip/>
> I tend to lean more
> towards trying to speed up start/stop as a way to reduce the test time
> as we do that so many times.
With this in mind and with the help of YourKit's Java Profiler I bring
you a 20% reduce in unit test run time :)
I'm still looking at the profiler results. I doubt I'll find anything as
good but I'll keep looking for a little while.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Gump, Tomcat Native, OpenSSL and Tomcat versions
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 9/12/18 17:20, Mark Thomas wrote:
> On 12/09/18 17:25, Christopher Schultz wrote:
>> Mark, On 9/12/18 7:12 AM, Mark Thomas wrote:
>
> <snip/>
>
>>> Testing all 12 combinations (4 OpenSSL * 3 Tomcat) seems like
>>> overkill.
>>
>> I would propose building+testing against both 1.0.2 (LTS) and
>> 1.1.1 (LTS) but leaving 1.1.0 and master out of the automated
>> builds. Certainly, both 1.1.0 and master should be testable, but
>> I don't think automated testing should be necessary.
>
> Testing with master has given us a heads up when OpenSSL adds new
> ciphers and/or disables old ciphers so we can update what is
> effectively our port of the OpenSSL cipher configuration string
> parsing code and ensure that - as far as we can - we keep out code
> consistent with OpenSSL.
Fair enough, but it's quite rare that OpenSSL announces a new release
line (at all) and then it takes some time before that line is adopted
and distributed to anyone but very bleeding-edge shops. I think any
lag between a release and Tomcat building automated tests against it
would be short enough to not present any problems.
>> Ideally, Tomcat itself should not need testing with tcnative *at
>> all*.
>
> Ideally, I agree. But the two are tightly coupled so that would be
> hard to achieve. Maybe with Native 2.0...
>
>> The testing of tcnative *itself* should be able to determine
>> whether various combinations of tcnative+OpenSSL x.y.z will work
>> together. A smoke-test that tcnative continues to work with both
>> the APR and NIO/NIO2 connectors should be sufficient in most
>> cases. This may not be possible given our current set of unit
>> tests for tcnative.
>
> The current unit tests are, um, 'minimal' (and imported from
> Tomcat) so I'd have to say "may not be possible" is putting a very
> positive spin on it ;)
:)
We need some C programmers to build a bunch of unit tests for
tcnative. That would be another great GSoC project, though not very sexy
.
>> (I'm always irritated whenever every. Single. Unit. Test. must be
>> run against all connector types even when the connector-type
>> should have zero impact on the test.)
>
> I hear you. No solution jumps to mind. Any ideas? I tend to lean
> more towards trying to speed up start/stop as a way to reduce the
> test time as we do that so many times.
The only thing I can think of is to create a new annotation for unit
tests like ConnectorAgnostic or something to that effect. Then, they
could be skipped after being run once (on any connector type). I think
that would require JUnit to be complicit with any such scheme, and I'm
not sure how to do that.
Another option would be to have those connector-agnostic unit tests in
a separate set of packages, and then run those separately a single
time and the connector-based unit tests per-connector. Lots of
re-organization for minimal gain. Well, time spent running unit tests,
but I don't know about everyone else, bu I just do a "nohup ant test >
tomcat_version.log &" and let it run as long as it needs to run.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluepxcACgkQHPApP6U8
pFjSkA/+KN9Ct2Btilfxaw3unYmeLpwflAasYqrdfqTxN9idHP/NcbRtb9IHmdpu
PuNpMaLv+Gfsdn5dejPDjNFaEAnsNNGdJ3yD0sI0HIRXujnJvC7vWlGT5ZDDQbU/
zNei9c+tS8NOkljXtb7qy/MQ42UHhxa33Z6gTaKEOf7N+QRMP38LTK4xF8BgjUEW
klLS+gWgcjBaNv88KiWWkVjNq7/Ugvb+9o6cTtIJsKca7AAE4KdoAX0neR/Wz9uT
KY+rVztMsgq2Sz8qPbZ0Rpn4hHC1mOj0WeSg07a51cIv1TCLqSBwb2D4gupMI3ZN
yhMWL0X8zORfD7TDB7Q1+p2NGdlBs5WqCOygliALTAKYKe2sMUdAOITt9fkh22eT
DnG4MtEQefLtczL0n4cC5n9zbFAos9N/BzR574Q9Gp9/hBi34Mooh2VT+o6dzWQD
ACKUUA840swnX9Hqsv9PP5wbaT4uJ6UdCv66RthTXl6SpiiCIWuQakjisSYao4sA
qdzje1RQqrzMl9zqtp5XADEsAKUg2S484vvzNoVifKiJS9sDXwdqp0bmk+goJfYp
qV9Ul4NcVmiKX5zZNwiHF2pFeOsWFVUr5zvWgnRGque3kySSfiFpq/PQtznGu2PJ
d3MEuTyvTEGf+HXazYaT1pzXuIqaq3Ef2lPuPKEB49UK0toXiYM=
=Hl4l
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Gump, Tomcat Native, OpenSSL and Tomcat versions
Posted by Mark Thomas <ma...@apache.org>.
On 12/09/18 17:25, Christopher Schultz wrote:
> Mark,
> On 9/12/18 7:12 AM, Mark Thomas wrote:
<snip/>
>> Testing all 12 combinations (4 OpenSSL * 3 Tomcat) seems like
>> overkill.
>
> I would propose building+testing against both 1.0.2 (LTS) and 1.1.1
> (LTS) but leaving 1.1.0 and master out of the automated builds.
> Certainly, both 1.1.0 and master should be testable, but I don't think
> automated testing should be necessary.
Testing with master has given us a heads up when OpenSSL adds new
ciphers and/or disables old ciphers so we can update what is effectively
our port of the OpenSSL cipher configuration string parsing code and
ensure that - as far as we can - we keep out code consistent with OpenSSL.
> Ideally, Tomcat itself should not need testing with tcnative *at all*.
Ideally, I agree. But the two are tightly coupled so that would be hard
to achieve. Maybe with Native 2.0...
> The testing of tcnative *itself* should be able to determine whether
> various combinations of tcnative+OpenSSL x.y.z will work together. A
> smoke-test that tcnative continues to work with both the APR and
> NIO/NIO2 connectors should be sufficient in most cases. This may not
> be possible given our current set of unit tests for tcnative.
The current unit tests are, um, 'minimal' (and imported from Tomcat) so
I'd have to say "may not be possible" is putting a very positive spin on
it ;)
> (I'm always irritated whenever every. Single. Unit. Test. must be run
> against all connector types even when the connector-type should have
> zero impact on the test.)
I hear you. No solution jumps to mind. Any ideas? I tend to lean more
towards trying to speed up start/stop as a way to reduce the test time
as we do that so many times.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Gump, Tomcat Native, OpenSSL and Tomcat versions
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 9/12/18 7:12 AM, Mark Thomas wrote:
> All,
>
> Gump currently tests 7.0.x, 8.5.x and 9.0.x
>
> Support for OpenSSL cipher names is available in 8.5.x onwards and
> we have various unit tests to ensure that our parsing code remains
> in sync with OpenSSL. All versions have TLS unit tests that check
> the APR/Native connector is working as expected.
>
> OpenSSL currently has the following four active development
> branches: Master (a.k.a. 1.1.2-dev) 1.1.1 (LTS supported until at
> least 2018-09-11 1.1.0 (supported until 2019-09-11) 1.0.2 (LTS
> supported until 2019-12-31)
>
> Gump currently builds OpenSSL master and 1.0.2
>
>
> Tomcat Native has two branches 1.2.x and 1.1.x. 1.1.x will reach
> EOL at the end of this month.
>
> Gump currently builds Native 1.1.x with OpenSSL 1.0.2 Native 1.2.x
> with OpenSSL 1.0.2 Native 1.2.x with OpenSSL master
>
>
> Gump then tests 9.0.x with Native 1.2.x/OpenSSL master 8.5.x with
> Native 1.2.x/OpenSSL 1.0.2 7.0.x with Native 1.2.x/OpenSSL 1.0.2
>
>
> We currently are only testing 3 out of a possible 24 combinations.
> If we ignore Native 1.1.x then that becomes 3 out of a possible 12
> combinations.
>
> Do we want to change / increase / decrease the combinations we
> test?
>
> As a starting point for discussion how about: - Build all current
> OpenSSL versions (currently 4) - Build Tomcat Native 1.2.x for each
> OpenSSL version (i.e. 4) - No Tomcat Native 1.1.x builds - Test
> 9.0.x with all Native/OpenSSL combinations (i.e. 4) - Test 8.5.x
> with Native/OpenSSL 1.1.1 (latest LTS) - Test 7.0.x with
> Native/OpenSSL 1.0.2 (other LTS)
>
> Testing all 12 combinations (4 OpenSSL * 3 Tomcat) seems like
> overkill.
I would propose building+testing against both 1.0.2 (LTS) and 1.1.1
(LTS) but leaving 1.1.0 and master out of the automated builds.
Certainly, both 1.1.0 and master should be testable, but I don't think
automated testing should be necessary.
Ideally, Tomcat itself should not need testing with tcnative *at all*.
The testing of tcnative *itself* should be able to determine whether
various combinations of tcnative+OpenSSL x.y.z will work together. A
smoke-test that tcnative continues to work with both the APR and
NIO/NIO2 connectors should be sufficient in most cases. This may not
be possible given our current set of unit tests for tcnative.
(I'm always irritated whenever every. Single. Unit. Test. must be run
against all connector types even when the connector-type should have
zero impact on the test.)
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluZPesACgkQHPApP6U8
pFiLnxAAlY3m7YcCE8zDxbfvFDBx6uXcixroQSSukdJL84upPXeVrclf+3U29qR9
SaMh5aNtoQUT1A63PToBySGvojnHYf0t27pYwU0dF1B96fI/tlLX1P7Ka9DPsUu9
pQ09FNzjnQUNhkB0f3Azj2FClK8ikmjLZEOhZJ/5tDh8ejd1un3m2ySQzhNAszZp
Mck+ECzx0k1fHd3DAsC42p1/DsNN9V8Hw34PlQ+thO1YSvtWsO6hP/rfE72hxRIY
NCAK1DU2qjEV3Tr5kn554+OXYdNMWnD4M144sqNDp8WD3A860wnvNHaBWdaKHn6J
KlEnPYxr1UKneXEYtv1F7r2NUAOc8OCsWn+NdOJCY36No/IednWAbnN/5IZaQrcT
rseQfxbq0X+tkQQqcuLFKZw+hlVdTC5Qy8RhQATSZBb8f4jddHX2BCib1sOmDivv
R+C5YR3JNNE1GISWOOu0Xsl8Q0DbMNWJhdn9ur1XxQPbcuLx7Jfnesgjo1vCayKv
Cw9b00Hs4tVm6VmmMfjLSg5nBNvgdZbUnoaR34ukwBvFuinErChrSuMXf7farvA3
LhT13qHfEdzKfp2IytCsugLdLrlth8BjnA/IYSQDNuHwVdazx0k9V+YrCEErd98V
gNd3Jae9yHFHIuMMHk2yAlLF7CAU34+iIOIfACJ4rVlXXO4g73U=
=G4R5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Gump, Tomcat Native, OpenSSL and Tomcat versions
Posted by Mark Thomas <ma...@apache.org>.
On 12/09/18 16:47, Christopher Schultz wrote:
> Mark,
>
> On 9/12/18 7:12 AM, Mark Thomas wrote:
>> OpenSSL currently has the following four active development
>> branches: Master (a.k.a. 1.1.2-dev) 1.1.1 (LTS supported until at
>> least 2018-09-11
>
> A slight correction:
>
> 1.1.1 was *initially* released 2018-09-11 with a support outlook of 5
> years, so the EOL date should be more like 2023-09-11.
ACK. I forgot to add 5.
Mark
>
> 1.1.1 is quite important as it is the first release of OpenSSL which
> includes support for TLSv1.3. It should be drop-in replaceable for
> existing 1.1.0 environments, so you (may be able to) get TLSv1.3
> support through little to no effort.
>
> -chris
>
> ---------------------------------------------------------------------
> 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
Re: Gump, Tomcat Native, OpenSSL and Tomcat versions
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 9/12/18 7:12 AM, Mark Thomas wrote:
> OpenSSL currently has the following four active development
> branches: Master (a.k.a. 1.1.2-dev) 1.1.1 (LTS supported until at
> least 2018-09-11
A slight correction:
1.1.1 was *initially* released 2018-09-11 with a support outlook of 5
years, so the EOL date should be more like 2023-09-11.
1.1.1 is quite important as it is the first release of OpenSSL which
includes support for TLSv1.3. It should be drop-in replaceable for
existing 1.1.0 environments, so you (may be able to) get TLSv1.3
support through little to no effort.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluZNRwACgkQHPApP6U8
pFgM8Q//aiijCTedd4FZ0EhQiqkYKIC+TS3j5G9RV9Twu9wuotGpVHmX9lynpj7I
UkWCDaCB/aFncPt0jrUmCpMMGicMEQqOy20+BdXPxDUfquMTvJftD9niRw45kPri
xSWTuZ/432NO5oL287mEd0Y2CvHvaORi6VhRImHcqE+fvikWQuYw4D+5NkdAGzPX
q3Y0vwLWtKYRb41riomRpcphNYpazRgSe86poO+v3WZMSQ7x21axVPOjrhIfRWUW
Gxs33GCSEmyvwo2n7Ck/lai2ZEv0kGmFG0BR7jyZuayfkO2e78pSjLQ2iu08ho7M
mZ38fQ4icwWKQycf92ozAryJUwhOLwDxmV0iIYnZojhuA9RroxqwMUok/00XDglG
YdqeqVFUylbae4FMtSaNBQJe7jGwWAejOW23jYdQ5SgD1oqmfZDBWoC6XGHmIVps
9+nmft8C3vq/3egYmH6GRv8t0y0U2EER7/89qlaveEZrRRbNrYWuIvjTq0h7o91u
yWndOIrKryaeGCD1EgAA/7qs9mEg7YejWa1pzQ//8iEPN9duv77ULdhTQ5mNGsUt
fbh//nZfftW19MyP71xTlV7ihm+hdLWLf4zHGBROz9jZw/IffRhB+eAovZ0RnxhS
nSV+MMzGY+/Wwj1Tt6EXkmCuBEtbMJDqE4bUkBZ6YX0hfEJSAcM=
=x9v1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Gump, Tomcat Native, OpenSSL and Tomcat versions
Posted by Mark Thomas <ma...@apache.org>.
On 12/09/18 17:22, Mark Thomas wrote:
> On 12/09/18 15:57, Rainer Jung wrote:
>> Am 12.09.2018 um 13:12 schrieb Mark Thomas:
<snip/>
>>> As a starting point for discussion how about:
>>> - Build all current OpenSSL versions (currently 4)
>>> - Build Tomcat Native 1.2.x for each OpenSSL version (i.e. 4)
>>> - No Tomcat Native 1.1.x builds
>>> - Test 9.0.x with all Native/OpenSSL combinations (i.e. 4)
>>> - Test 8.5.x with Native/OpenSSL 1.1.1 (latest LTS)
>>> - Test 7.0.x with Native/OpenSSL 1.0.2 (other LTS)
>>>
>>> Testing all 12 combinations (4 OpenSSL * 3 Tomcat) seems like overkill.
>>>
>>> Thoughts?
>>
>> I like it. Broad coverage for our latest branch and some additional
>> checks for the older branches.
>>
>> A variation we could think about, is dropping OpenSSL master at least
>> until that branch produces alpha releases for 1.1.2. Since 1.1.1 is now
>> GA I think it will be the relevant newest version for quite some time.
>> Probably master will not become relevant for us before EOL for 1.1.0.
>
> It is almost easier to leave to master build in place.
>
> I've added the additional OpenSSL builds for 1.1.0 and 1.1.1. I'll wait
> and see what happens with those builds in the next Gump run first in
> case I have missed something in setting them up.
OpenSSL 1.0.2, 1.1.0, 1.1.1 and master have been building happily for a
while now.
I've just dropped the Tomcat Native 1.1.x build (that branch is no
longer supported) and I've added the additional Tomcat Native 1.2.x +
OpenSSL builds so we are building with all 4 current OpenSSL versions.
I did a little renaming to make it clearer what is going on and I
configured 8.5.x to test against 1.2-1.1.1.
Assuming all the above changes work (I don't have a high success rate
for getting Gump config changes right first time) I'll then add the
additional runs with 9.0.x. (1.2-1.1.1, 1.2-1.1.0, 1.2-1.0.2).
I won't be surprised if we see test failures because the tests don't
fully account for running with different OpenSSL versions.
If (OK, when) we get Gump failures, I'll get them fixed as quickly as I can.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Gump, Tomcat Native, OpenSSL and Tomcat versions
Posted by Mark Thomas <ma...@apache.org>.
On 12/09/18 15:57, Rainer Jung wrote:
> Am 12.09.2018 um 13:12 schrieb Mark Thomas:
>> Gump currently tests 7.0.x, 8.5.x and 9.0.x
>>
>> Support for OpenSSL cipher names is available in 8.5.x onwards and we
>> have various unit tests to ensure that our parsing code remains in sync
>> with OpenSSL.
>> All versions have TLS unit tests that check the APR/Native connector is
>> working as expected.
>>
>> OpenSSL currently has the following four active development branches:
>> Master (a.k.a. 1.1.2-dev)
>> 1.1.1 (LTS supported until at least 2018-09-11
>> 1.1.0 (supported until 2019-09-11)
>> 1.0.2 (LTS supported until 2019-12-31)
>>
>> Gump currently builds OpenSSL master and 1.0.2
>>
>>
>> Tomcat Native has two branches 1.2.x and 1.1.x.
>> 1.1.x will reach EOL at the end of this month.
>>
>> Gump currently builds
>> Native 1.1.x with OpenSSL 1.0.2
>> Native 1.2.x with OpenSSL 1.0.2
>> Native 1.2.x with OpenSSL master
>>
>>
>> Gump then tests
>> 9.0.x with Native 1.2.x/OpenSSL master
>> 8.5.x with Native 1.2.x/OpenSSL 1.0.2
>> 7.0.x with Native 1.2.x/OpenSSL 1.0.2
>>
>>
>> We currently are only testing 3 out of a possible 24 combinations. If we
>> ignore Native 1.1.x then that becomes 3 out of a possible 12
>> combinations.
>>
>> Do we want to change / increase / decrease the combinations we test?
>>
>> As a starting point for discussion how about:
>> - Build all current OpenSSL versions (currently 4)
>> - Build Tomcat Native 1.2.x for each OpenSSL version (i.e. 4)
>> - No Tomcat Native 1.1.x builds
>> - Test 9.0.x with all Native/OpenSSL combinations (i.e. 4)
>> - Test 8.5.x with Native/OpenSSL 1.1.1 (latest LTS)
>> - Test 7.0.x with Native/OpenSSL 1.0.2 (other LTS)
>>
>> Testing all 12 combinations (4 OpenSSL * 3 Tomcat) seems like overkill.
>>
>> Thoughts?
>
> I like it. Broad coverage for our latest branch and some additional
> checks for the older branches.
>
> A variation we could think about, is dropping OpenSSL master at least
> until that branch produces alpha releases for 1.1.2. Since 1.1.1 is now
> GA I think it will be the relevant newest version for quite some time.
> Probably master will not become relevant for us before EOL for 1.1.0.
It is almost easier to leave to master build in place.
I've added the additional OpenSSL builds for 1.1.0 and 1.1.1. I'll wait
and see what happens with those builds in the next Gump run first in
case I have missed something in setting them up.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Gump, Tomcat Native, OpenSSL and Tomcat versions
Posted by Rainer Jung <ra...@kippdata.de>.
Am 12.09.2018 um 13:12 schrieb Mark Thomas:
> Gump currently tests 7.0.x, 8.5.x and 9.0.x
>
> Support for OpenSSL cipher names is available in 8.5.x onwards and we
> have various unit tests to ensure that our parsing code remains in sync
> with OpenSSL.
> All versions have TLS unit tests that check the APR/Native connector is
> working as expected.
>
> OpenSSL currently has the following four active development branches:
> Master (a.k.a. 1.1.2-dev)
> 1.1.1 (LTS supported until at least 2018-09-11
> 1.1.0 (supported until 2019-09-11)
> 1.0.2 (LTS supported until 2019-12-31)
>
> Gump currently builds OpenSSL master and 1.0.2
>
>
> Tomcat Native has two branches 1.2.x and 1.1.x.
> 1.1.x will reach EOL at the end of this month.
>
> Gump currently builds
> Native 1.1.x with OpenSSL 1.0.2
> Native 1.2.x with OpenSSL 1.0.2
> Native 1.2.x with OpenSSL master
>
>
> Gump then tests
> 9.0.x with Native 1.2.x/OpenSSL master
> 8.5.x with Native 1.2.x/OpenSSL 1.0.2
> 7.0.x with Native 1.2.x/OpenSSL 1.0.2
>
>
> We currently are only testing 3 out of a possible 24 combinations. If we
> ignore Native 1.1.x then that becomes 3 out of a possible 12 combinations.
>
> Do we want to change / increase / decrease the combinations we test?
>
> As a starting point for discussion how about:
> - Build all current OpenSSL versions (currently 4)
> - Build Tomcat Native 1.2.x for each OpenSSL version (i.e. 4)
> - No Tomcat Native 1.1.x builds
> - Test 9.0.x with all Native/OpenSSL combinations (i.e. 4)
> - Test 8.5.x with Native/OpenSSL 1.1.1 (latest LTS)
> - Test 7.0.x with Native/OpenSSL 1.0.2 (other LTS)
>
> Testing all 12 combinations (4 OpenSSL * 3 Tomcat) seems like overkill.
>
> Thoughts?
I like it. Broad coverage for our latest branch and some additional
checks for the older branches.
A variation we could think about, is dropping OpenSSL master at least
until that branch produces alpha releases for 1.1.2. Since 1.1.1 is now
GA I think it will be the relevant newest version for quite some time.
Probably master will not become relevant for us before EOL for 1.1.0.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org