Closed dnwe closed 2 years ago
@dnwe Thanks for the PR Dominic, in general the fix looks good to me ! However need some minor changes. Instead of making changes manually to each of these Dockerfiles, can you make the change here and here. You also might have to do some refactoring in the second part to separate the Alpine instructions from Ubuntu.
Hopefully this should not break anything in Liberty / OpenLiberty, @arthurdm @NottyCode
Thanks @dinogun – force pushed a new version with the corresponding update.sh and Dockerfiles generated from that instead
There is a small bit of code in WASdev/ci.docker/test/verify.sh build test script that would start failing because it wouldn't able to wget within the container anymore, but that would be trivial to fix by wget'ing the liberty zip outside of the docker run and volume mounting it in.
Other than this script I don't believe websphere-liberty is currently shipping anything based atop the alpine variants of ibmjava are they?
hey guys - while WebSphere Liberty doesn't have an Alpine flavour, Open Liberty does - and it does rely on OpenSSL for setting up the keystore https://github.com/OpenLiberty/ci.docker/blob/master/release/kernel/docker-server#L10, which would break @NottyCode
None of these changes (openssl and wget) would affect the Ubuntu flavour?
@arthurdm correct, I haven't currently touched the Ubuntu images, although they still suffer from the same known CVEs and more as they contain the older OpenSSL 1.0.2g and I would recommended that we similarly remove them sometime in the future.
Personally I wouldn't expect a Java base image to be shipping with curl, wget or openssl CLIs
@arthurdm @NottyCode Considering the frequency of updates to openssl due to vulnerabilities, I'm inclined to remove them from the base Java image. Would it work if you installed it only for the steps that you need in the liberty dockerfiles ?
hi @dinogun - don't you get those updates automatically from Docker Hub everytime Ubuntu / Alpine get updated?
@arthurdm the official images don't get periodically rebuilt like that. For Ubuntu they only get refreshed when Canonical release a new cloud image rootfs and for Alpine it seems to be even rarer. See https://hub.docker.com/r/library/alpine/tags/ and https://hub.docker.com/r/library/ubuntu/tags/ for the cadences.
Previously the Dockerfile's were all installing ca-certificates, curl and openssl to allow them to securely fetch the glibc apk and the jre/sdk. However, they were a) not removing openssl after making use of it and b) including an outdated version (from alpine 3.6 repos pre-April?) so any downstream images that built upon this official image are flagged up for various CVEs in 1.0.2n but fixed in 1.0.2o(e.g., CVE-2017-3738, CVE-2018-0733, CVE-2018-0739)
I don't believe there is a need to ship OpenSSL in the image itself, so this PR switches to adding-and-removing the buildtime dependencies. It also switches to using LibreSSL as that is what Alpine Linux uses by default and most OpenSSL CVEs do not apply to it.