Build image with current Alpine

[maartenwest]

The current image, 1.7.4.3-r1, was built 2 months ago, and today there are some known vulnerabilities in its dependencies.

If I rebuild the image today, with alpine:3.16.2 as base image, the resulting image does not have these vulnerabilities.

Is it possible to trigger Travis CI so a new image is pushed to hub.docker.com, even though there is no new tag of socat?

Thanks for providing this image!

[ozbillwang]

Normally the travispipeline runs per week.

Sure, for vulnerabilities, I can trigger the travis pipeline manually.

[ozbillwang]

exist vulnerabilities report

https://app.travis-ci.com/github/alpine-docker/socat/builds/256567525

[ozbillwang]

the vulnerabilities come from base image, not from socat. reason is we want to use the latest socat version, I have to choice to use alpine:edge.

In alpine:latest, its socat version is 1.7.4.3-r0

It has the current latest socat version 1.7.4.3-r1, but the base image can't pass scan check.

$ docker run -ti --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.cache:/root/.cache aquasec/trivy image --severity HIGH,CRITICAL alpine:edge

Total: 7 (HIGH: 6, CRITICAL: 1)

┌──────────────┬────────────────┬──────────┬───────────────────┬───────────────┬─────────────────────────────────────────────────────────────┐
│   Library    │ Vulnerability  │ Severity │ Installed Version │ Fixed Version │                            Title                            │
├──────────────┼────────────────┼──────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ libcrypto1.1 │ CVE-2021-4044  │ HIGH     │ 1.1.1q-r0         │ 3.0.1-r0      │ openssl: invalid handling of X509_verify_cert() internal    │
│              │                │          │                   │               │ errors in libssl                                            │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-4044                   │
│              ├────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-0778  │          │                   │ 3.0.2-r0      │ openssl: Infinite loop in BN_mod_sqrt() reachable when      │
│              │                │          │                   │               │ parsing certificates                                        │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-0778                   │
│              ├────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-1473  │          │                   │ 3.0.3-r0      │ openssl: OPENSSL_LH_flush() breaks reuse of memory          │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-1473                   │
├──────────────┼────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│ libssl1.1    │ CVE-2021-4044  │          │                   │ 3.0.1-r0      │ openssl: invalid handling of X509_verify_cert() internal    │
│              │                │          │                   │               │ errors in libssl                                            │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-4044                   │
│              ├────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-0778  │          │                   │ 3.0.2-r0      │ openssl: Infinite loop in BN_mod_sqrt() reachable when      │
│              │                │          │                   │               │ parsing certificates                                        │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-0778                   │
│              ├────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-1473  │          │                   │ 3.0.3-r0      │ openssl: OPENSSL_LH_flush() breaks reuse of memory          │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-1473                   │
├──────────────┼────────────────┼──────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ zlib         │ CVE-2022-37434 │ CRITICAL │ 1.2.12-r1         │ 1.2.12-r2     │ zlib: heap-based buffer over-read and overflow in inflate() │
│              │                │          │                   │               │ in inflate.c via a...                                       │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-37434                  │
└──────────────┴────────────────┴──────────┴───────────────────┴───────────────┴─────────────────────────────────────────────────────────────┘

$ docker run -ti --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.cache:/root/.cache aquasec/trivy image --severity HIGH,CRITICAL alpine:latest

...
alpine:latest (alpine 3.16.2)

Total: 0 (HIGH: 0, CRITICAL: 0)

Several decisions we need make :

1. use base image alpine:latest , currently it is alpine:3.16.2, has socat version of 1.7.4.3-r0 only, but no vulnerabilities
2. use base image alpine:edge , can install socat version with 1.7.4.3-r1, but with several vulnerabilities

[maartenwest]

Thanks for the response and checking the vulnerabilities. For my use case, it would be great to use socat 1.7.4.3-r0 on alpine 3.16.

Is it possible to have the pipeline check for new socat versions in both alpine branches, so two variants of the socat image can be built?

So that would be check both
https://pkgs.alpinelinux.org/package/edge/main/x86/socat
https://pkgs.alpinelinux.org/package/v3.16/main/x86/socat
for new versions and build with base images alpine:edge and alpine:3.16 (not specifying the socat version in the Dockerfile, so it will use the latest socat in that alpine).

The tags for the generated images would have to be changed, too, maybe using a pattern like alpine/socat:1.7.4.3-r1-alpine-edge and alpine/socat:1.7.4.3-r0-alpine-3.16.

[gaby]

It's possible to upgrade all the packages from the base image to fix any CVE's using this:

apk -U upgrade

[gaby]

@maartenwest This is the report using the latest image:

ubuntu@ubuntu:~/Desktop$ docker run --net=host --rm aquasec/trivy:latest image alpine/socat:latest
2023-02-21T04:00:53.038Z	INFO	Need to update DB
2023-02-21T04:00:53.038Z	INFO	DB Repository: ghcr.io/aquasecurity/trivy-db
2023-02-21T04:00:53.038Z	INFO	Downloading DB...
2023-02-21T04:00:56.837Z	INFO	Vulnerability scanning is enabled
2023-02-21T04:00:56.837Z	INFO	Secret scanning is enabled
2023-02-21T04:00:56.837Z	INFO	If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2023-02-21T04:00:56.837Z	INFO	Please see also https://aquasecurity.github.io/trivy/v0.37/docs/secret/scanning/#recommendation for faster secret detection
2023-02-21T04:00:57.641Z	INFO	Detected OS: alpine
2023-02-21T04:00:57.641Z	INFO	Detecting Alpine vulnerabilities...
2023-02-21T04:00:57.643Z	INFO	Number of language-specific files: 0

alpine/socat:latest (alpine 3.17.2)
===================================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)