Repository navigation
[Feature request] Dockerfile - Include openssl1.1-compat #2314
Description
Extracted from https://github.com/drwetter/testssl.sh/pull/2305 (specifically this commit)
Which version are you referring to
Both releases: 3.0.x + 3.1dev
Please check this repo whether this is a known feature request
This is for the recent upgrade to Alpine 3.17 where OpenSSL package is now the 3.x series, instead of the previous 1.1 series.
- There was an attempt to PR this. It was closed for proposing too many changes at once.
- An observation with local performance of
1.1performing notably better than3.xfor a CI test suite.
If your feature request otherwise is related to a usage problem, please describe it
- It was observed to be about 30 seconds faster (~190 sec vs ~220 sec). About a 15% improvement in run time.
- There may be other reasons to carry both versions of OpenSSL packages in the image, at least until the
3.xseries is more broadly available (Debian Bullseye for example deploys with1.1).
Describe the solution you'd like
- Adding the
openssl1.1-compatpackage (adds 4MB). - Alternatively offering a Debian or similar base image variant for
glibcwhere performance seems better than Alpine withmuslat the expense of image size.
This is just a suggestion based on insights from the referenced issue and closed PR.
It might be worth waiting to see if it interests / impacts anyone else, or if they also get approx 15% faster run times (both for parallel and single tests).
Activity
polarathene commentedon Feb 3, 2023
CI (GitHub Actions) workflow runs for the test cases I had observed performance of locally (with
--openssl /usr/bin/openssl) now cover thedrwetter/testssl.sh:3.1devimage changed from Alpine 3.16 (OpenSSL 1.1) to Alpine 3.17 (OpenSSL 3.0) below.Alpine 3.16 (199s):
Alpine 3.17 update (223s):
So local observations are likely to benefit the Github Actions CI runs by approx 15% as well if
openssl1.1-compatwere used instead.drwetter commentedon Mar 4, 2023
Probably I haven´t looked good enough at this. Any change in the Dockerimage which is not coherent with the pulled files is not something which I am really fond of -- for both the CI and the user image.
For the former case the point of the CI test is to test the binary. I´d rather skip one test there. And to the user the image should hand out the same as if it's pulled from the repo.
In next development stage (after 3.2) is usage of a different openssl version per default probably a good idea (TBC).
polarathene commentedon Mar 4, 2023
When I was talking about CI, I meant the CI runs on a project I maintain where
testssl.shwas used via the Docker image.No change here. Just an additional package installed in the image that can be used with
--opensslas an alternative binary.The user running the image would explicitly provide that option and path to use the
openssl1.1-compatbinary.Sorry, I'm not following?
With the upgrade to Alpine 3.17 base image, OpenSSL is 3.x series, where as previously it was the 1.x series. This is not related to
testssl.shbeyondDockerfile.A pull from this repo doesn't control the OpenSSL provided within the base image (or outside of Docker, whatever OpenSSL is on the host system).
It's all good to decline this request 👍
Main benefit is the observed 15% faster performance running
testssl.shwith the OpenSSL 1.x series.Add openssl, offer to query OCSP responder