fix: update base image to maven supported #7001
Conversation
Switch base image from jimschubert/8-jdk-alpine-mvn:1.0 to maven:3.6.3-jdk-11-openj9. The jimschubert/8-jdk-alpine-mvn:1.0 is not managed by any project, it has a very old (alpine 3.4) base image with many CVE security flaw. Swap to the image managed by the Maven apache project.
|
cc @jimschubert (the owner of jimschubert/8-jdk-alpine-mvn) |
|
I'm fine with changing it. I rebuild the 2.0 version of that image weekly, not the 1.0 version. I created the image because at the time the official Maven image pulled deps over insecure http. I'll need to bump the Maven version, but my 2.0 image picks up all updates from the underlying openjdk image. I would suggest that we target openjdk, though, as that's what we test against and support. |
|
ok so change the target to be |
|
@donbowman Notice as well that the |
|
we use it in our CI so the image size is a bit of a concern. i don't understand how run-in-docker.sh could be the entrypoint, it calls docker itself, which would imply dind, which we don't allow. |
|
@donbowman I'm curious for what use case you'd be using the Dockerfile in the project root for CI? We don't publish any images from that Dockerfile, so you'd have to be cloning the repo and calling docker directly anyway (in which case If you're pulling the CLI image from Docker Hub, I'll have updated the builder images to my bash-2.0 image via #7129. This image is updated via cron every week. It does still target Maven 3.3.9, and we use these specifically because of the size: 120MB versus maven:3-jdk-8 at 522MB. Even openjdk:15-slim-buster which you'd suggested is 415MB and doesn't include maven. We use a builder context as the base image If you are using one of those released images I'd also be interested in understanding how or why your CI has flagged them with CVEs because as you can see by image history they have no details about the builder image: |
|
alpine doesn't publish CVE, which is a huge red flag. Its one of the reasons we don't use it (the other is the poor performance and poor install time w/ python). ~ 2016 release. All the apk in it are very old and full of security flaws. docker-in-docker is a terrible thing to use: the security is awful, the performance is awful. Since the CI (self-hosted gitlab CI) runs in Kubernetes, its easy to run an arbitrary image, but I don't allow that image to turn around and run another one locally (there is no 2nd docker running). As a consequence in the CI I don't run a 2nd docker image (thus the comment about the run-in-docker script, that is a desktop developer tool). I look for projects to have maintained by the project team, built by their CI, images. It seems that is not the case here (since there is an out-of-band build process? and, the base image is not part of the project but is single maintainer?), so i sense i should locally maintain my own image? Maybe i misunderstood, I assumed the Dockerfile in the root of this repo would automatically build on Dockerhub, and was the base of the openapitools/openapi-generator-cli:v4.3.1? |
|
Oh i see, you have a .hub.cli.dockerfile etc. I should change those too. |
…0.8-jre-slim-buster
|
@donbowman thanks for running through your use case. I think these are excellent points! Sorry for the late response. |
Switch base image from jimschubert/8-jdk-alpine-mvn:1.0 to
maven:3.6.3-jdk-11-openj9.
The jimschubert/8-jdk-alpine-mvn:1.0 is not managed by
any project, it has a very old (alpine 3.4) base image
with many CVE security flaw.
Swap to the image managed by the Maven apache project.
PR checklist
./bin/generate-samples.shto update all Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH.master