Remove gosu based CVE by building gosu with current golang image #1323

nathanlaceyraft · 2025-02-25T14:21:44Z

gosu security policy https://github.com/tianon/gosu/blob/master/SECURITY.md says they don't update golang unless govulncheck reports CVE's
So gosu is build with a unsupported version of go (1.18)
The two supported go versions that have the most CVE's resolved are 1.23.6 and 1.24.0
I felt using 1.23.6 was a safer upgrade.

Your own documents talk about gosu, and I believe gosu has a fundamental misunderstanding about what a vulnerability free govulncheck means. I understand it to mean that you don't have any external dependencies with vulnerabilities, not that you shouldn't update compiler versions. They are 2 different things.

This PR removes the CVE caused by gosu by doing a custom build of gosu with a currently supported go version.
And copies it into the final image.

trivy image --scanners vuln
shows that we'll get rid of the following CVE's

usr/local/bin/gosu (gobinary)

Total: 58 (UNKNOWN: 0, LOW: 1, MEDIUM: 23, HIGH: 31, CRITICAL: 3)

Thanks for your consideration

cleanup reference

yosifkit · 2025-02-25T17:37:41Z

does not rebuild/release to "fix" CVEs which do not apply

- https://github.com/tianon/gosu/blob/e157efb749be5ce1f32e07aa9849abe3fd953b1c/SECURITY.md (emphasis added)

While the list of CVEs is annoying for users, @tianon is correct and the problem lies in security scanners. They should not blindly attribute a CVE for including a library when go has tooling that they can use to do better and know which functions of the library were included in the binary. They should only attribute the CVE if the vulnerable code path is included and useable in the binary.

nathanlaceyraft · 2025-02-25T18:06:21Z

Lets pretend we are living in a better world where the vulnerability scanners are better and don't report any false CVE's.

You still have a problem of docker postgres including a binary that was created with a compiler that is a year past End Of Life!

The 2 golang compilers that aren't EOL are 1.23.x and 1.24.x
gosu was compiled with 1.18.x,
1.18.x went EOF Feb 2023 when 1.22 was released

tianon · 2025-02-25T18:19:02Z

Is there a concrete problem caused by using an "end of life" compiler? Because if so, the Linux distributions would probably like to know about it. As far as I know, there is no meaningful change caused to the gosu binary by recompiling it with a newer compiler except some strings in the binary have a slightly higher number (and the binaries compile slightly differently due to different changes in the compiler). There aren't any active bugs I'm aware of in the versions of the compiler used that actually affect the gosu binary in any way. If there were, I'd be happy to update (just like a normal Linux distro would/does for their precompiled binary builds).

nathanlaceyraft · 2025-02-25T18:39:29Z

The point about not using EOL software, is that no one is maintaining it any longer, no one is fixing newly discovered problems with it.
It has got to be less work to just keep compilers updated, than it make every 'customer' of your product (downloader of you image) read through every one of the un-needed 58 CVE's caused by gosu and say, 'This is fine'

bgehman · 2025-03-26T22:37:23Z

The point about not using EOL software, is that no one is maintaining it any longer, no one is fixing newly discovered problems with it.

I would add that security researchers are focused on up-to-date supported software versions: that's where they are looking and where CVEs are discovered, and only afterwards are any related older versions called out. Researches are not hacking on old EOL versions of compilers and libraries. This entire debate is akin to someone claiming their Win-95 server is secure because nobody has reported a CVE against Win-95 in the past 20-odd years. 🤦

I would like to see Golang owners chime in here, and confirm or deny this "best practice" of refusing to upgrade dependencies off of EOL.

reneleonhardt · 2025-06-06T20:18:27Z

13/alpine3.20/Dockerfile

@@ -4,6 +4,14 @@
 # PLEASE DO NOT EDIT IT DIRECTLY.
 #

+FROM golang:1.23.6 AS gosubuilder


If security is the reason for rebuilding, then you probably should always use the latest golang (1.23.10) by removing the patch digits.
In addition, Alpine images should probably use -alpine base images instead of Debian.

Suggested change

FROM golang:1.23.6 AS gosubuilder

FROM golang:1.23-alpine3.21 AS gosubuilder

Furthermore alpine3.20 has been removed already, the latest release is 3.22, I recommend to rebase.
postgres 18 has been added too by the way.

@reneleonhardt the go image only matters for creating the binary artifact, and isn't part of the final image, so I don't think we are gaining anything from using alpine in this case.

This pr has been sitting for months, so I won't be touching it unless it looks like it starts moving forward.

But I believe you are wrong about removing patch digits.
They are important, otherwise you don't know when you need to create a new release. And update your own patch digits on your image

golang:1.24.4@sha256:10c131810f80a4802c49cab0961bbe18a16f4bb2fb99ef16deaa23e4246fc817

is how the current image should really be tagged.
The hash gives us protection from Supply Chain attack, if the image was compromised we would be told there was a problem instead of releasing our own compromised image

In my ideal world, we would add a .github/dependabot.yml file with
version: 2
updates:

package-ecosystem: "docker"
directories:

"/"
schedule:
interval: "daily"

And dependabot would be able to keep these files updated (we would need to include all the sub-folders within the directories config)

Most maintainers in most projects don't allow update contributions as you can see here after your own work.
Most of my pull requests have never been accepted, especially if I added dependabot in addition to all my tedious manual updates (docker, npm, gomod, cargo, github-actions, ...).
I mean there's a reason why there are decades of technical debt in most projects if the maintainers even don't allow dependabot to automate most of that work 🤷

Of course it would be nice if dependabot would create those patches / hashes in a timely matter, but maintainers would still not merge them, so what would be gained?

What could work much better for users would be a cron workflow to rebuild the image with all available updates, compare if anything (meaningful) changed and release / publish if necessary without having to wait for a maintainer to press a merge button.
Then consumers would receive the best possible fresh image everyday.
It's hard to conceive why thousands of upstream maintainers work hard everyday to analyze and fix bugs when downstream maintainers just choose to ignore those updates for months or years.

reneleonhardt · 2025-06-06T20:20:49Z

13/alpine3.20/Dockerfile

@@ -4,6 +4,14 @@
 # PLEASE DO NOT EDIT IT DIRECTLY.
 #

+FROM golang:1.23.6 AS gosubuilder
+ENV GOSU_VERSION=1.17


Please note that ENV variables are propagated to runtime, I suggest using ARG variables during build.
In addition, there have been 33 commits since 1.17, rebuilds could actually use the latest code instead of an outdated tag.

Suggested change

ENV GOSU_VERSION=1.17

ARG GOSU_VERSION=1.17

reneleonhardt · 2025-06-06T20:26:10Z

13/alpine3.20/Dockerfile

+RUN git clone https://github.com/tianon/gosu.git --branch $GOSU_VERSION
+WORKDIR /go/src/github.com/tianon/gosu
+RUN go mod download
+RUN go build


Maybe it would be better to stay closer to the original build instructions, for example the build flags.

-trimpath -ldflags '-d -w'

https://github.com/tianon/gosu/blob/master/Dockerfile#L12

jlcox1970 · 2025-08-15T23:43:52Z

I there a plan to patch this out?

I understand the the 2 differing views on this and I have to say I am disappointed that security is taken so lightly in this day and age.

I the enterprise IT world the idea of having a CVE with a known exploit in the wild is not tolerated given the number, size and cost of data breaches

I ran postgres:17.6-alpine thru one of my scan tools ad to see the shear number of CVE's against gosu made my heart sink, especially after reading this thread and the related issue

I think we all have a duty of care to make this container the best it can be, and to do that we need to remove as many CVE's as possible so that the enterprise CTO,CISO etc feel good when there InfoSEC teams conduct scans.
At the end of the day they are our customers and they need to be looked after

here is my scan that could be fixed just by bumping up the golang and gosu versions


NAME           INSTALLED   FIXED IN                       TYPE       VULNERABILITY   SEVERITY  EPSS           RISK
stdlib         go1.18.2    *1.20.10, 1.21.3               go-module  CVE-2023-44487  High      94.4% (99th)   78.8   (kev)
stdlib         go1.18.2    *1.21.9, 1.22.2                go-module  CVE-2023-45288  High      64.9% (98th)   48.6
stdlib         go1.18.2    *1.21.8, 1.22.1                go-module  CVE-2024-24784  High      1.5% (80th)    1.1
stdlib         go1.18.2    *1.21.10, 1.22.3               go-module  CVE-2024-24787  Medium    1.6% (80th)    0.9
stdlib         go1.18.2    *1.19.8, 1.20.3                go-module  CVE-2023-24538  Critical  0.6% (69th)    0.6
stdlib         go1.18.2    *1.21.12, 1.22.5               go-module  CVE-2024-24791  High      0.6% (68th)    0.5
stdlib         go1.18.2    1.21.0-0                       go-module  CVE-2023-24531  Critical  0.4% (57th)    0.3
stdlib         go1.18.2    *1.19.10, 1.20.5               go-module  CVE-2023-29405  Critical  0.3% (54th)    0.3
stdlib         go1.18.2    *1.19.9, 1.20.4                go-module  CVE-2023-24540  Critical  0.2% (47th)    0.2
stdlib         go1.18.2    *1.21.8, 1.22.1                go-module  CVE-2024-24783  Medium    0.4% (59th)    0.2
stdlib         go1.18.2    *1.18.9, 1.19.4                go-module  CVE-2022-41717  Medium    0.4% (60th)    0.2
stdlib         go1.18.2    *1.21.8, 1.22.1                go-module  CVE-2023-45289  Medium    0.4% (60th)    0.2
stdlib         go1.18.2    *1.21.8, 1.22.1                go-module  CVE-2023-45290  Medium    0.3% (54th)    0.2
stdlib         go1.18.2    1.19.6                         go-module  CVE-2022-41723  High      0.2% (45th)    0.2
stdlib         go1.18.2    1.20.0                         go-module  CVE-2023-45287  High      0.2% (40th)    0.1
stdlib         go1.18.2    *1.22.7, 1.23.1                go-module  CVE-2024-34156  High      0.2% (39th)    0.1
stdlib         go1.18.2    *1.21.8, 1.22.1                go-module  CVE-2024-24785  Medium    0.2% (47th)    0.1
stdlib         go1.18.2    *1.19.10, 1.20.5               go-module  CVE-2023-29402  Critical  0.1% (32nd)    0.1
stdlib         go1.18.2    *1.19.11, 1.20.6               go-module  CVE-2023-29406  Medium    0.2% (36th)    < 0.1
stdlib         go1.18.2    1.17.12, *1.18.4               go-module  CVE-2022-30635  High      0.1% (30th)    < 0.1
stdlib         go1.18.2    1.18.6                         go-module  CVE-2022-27664  High      0.1% (30th)    < 0.1
stdlib         go1.18.2    *1.19.10, 1.20.5               go-module  CVE-2023-29404  Critical  < 0.1% (25th)  < 0.1
stdlib         go1.18.2    1.17.13, *1.18.5               go-module  CVE-2022-32189  High      < 0.1% (25th)  < 0.1
stdlib         go1.18.2    *1.21.11, 1.22.4               go-module  CVE-2024-24790  Critical  < 0.1% (21st)  < 0.1
stdlib         go1.18.2    *1.22.7, 1.23.1                go-module  CVE-2024-34158  High      < 0.1% (24th)  < 0.1
stdlib         go1.18.2    *1.22.7, 1.23.1                go-module  CVE-2024-34155  Medium    0.1% (30th)    < 0.1
stdlib         go1.18.2    *1.19.8, 1.20.3                go-module  CVE-2023-24536  High      < 0.1% (20th)  < 0.1
stdlib         go1.18.2    *1.19.9, 1.20.4                go-module  CVE-2023-24539  High      < 0.1% (20th)  < 0.1
stdlib         go1.18.2    *1.20.9, 1.21.2                go-module  CVE-2023-39323  High      < 0.1% (18th)  < 0.1
stdlib         go1.18.2    1.17.12, *1.18.4               go-module  CVE-2022-30632  High      < 0.1% (19th)  < 0.1
stdlib         go1.18.2    1.17.12, *1.18.4               go-module  CVE-2022-30633  High      < 0.1% (19th)  < 0.1
stdlib         go1.18.2    *1.19.12, 1.20.7               go-module  CVE-2023-29409  Medium    < 0.1% (24th)  < 0.1
stdlib         go1.18.2    *1.20.12, 1.21.5               go-module  CVE-2023-45285  High      < 0.1% (17th)  < 0.1
stdlib         go1.18.2    *1.23.12, 1.24.6               go-module  CVE-2025-47907  High      < 0.1% (16th)  < 0.1
stdlib         go1.18.2    1.19.6                         go-module  CVE-2022-41725  High      < 0.1% (15th)  < 0.1
stdlib         go1.18.2    *1.19.9, 1.20.4                go-module  CVE-2023-29400  High      < 0.1% (14th)  < 0.1
stdlib         go1.18.2    *1.20.8, 1.21.1                go-module  CVE-2023-39318  Medium    < 0.1% (19th)  < 0.1
stdlib         go1.18.2    *1.20.8, 1.21.1                go-module  CVE-2023-39319  Medium    < 0.1% (19th)  < 0.1
stdlib         go1.18.2    *1.19.8, 1.20.3                go-module  CVE-2023-24534  High      < 0.1% (12th)  < 0.1
stdlib         go1.18.2    1.17.12, *1.18.4               go-module  CVE-2022-32148  Medium    < 0.1% (14th)  < 0.1
stdlib         go1.18.2    *1.23.10, 1.24.4               go-module  CVE-2025-4673   Medium    < 0.1% (12th)  < 0.1
stdlib         go1.18.2    *1.20.12, 1.21.5               go-module  CVE-2023-39326  Medium    < 0.1% (14th)  < 0.1
stdlib         go1.18.2    *1.18.7, 1.19.2                go-module  CVE-2022-2880   High      < 0.1% (7th)   < 0.1
stdlib         go1.18.2    1.17.12, *1.18.4               go-module  CVE-2022-1705   Medium    < 0.1% (10th)  < 0.1
stdlib         go1.18.2    1.17.12, *1.18.4               go-module  CVE-2022-30631  High      < 0.1% (6th)   < 0.1
stdlib         go1.18.2    *1.23.8, 1.24.2                go-module  CVE-2025-22871  Critical  < 0.1% (4th)   < 0.1
stdlib         go1.18.2    1.17.12, *1.18.4               go-module  CVE-2022-30630  High      < 0.1% (4th)   < 0.1
stdlib         go1.18.2    *1.22.11, 1.23.5, 1.24.0-rc.2  go-module  CVE-2024-45336  Medium    < 0.1% (7th)   < 0.1
stdlib         go1.18.2    1.17.11, *1.18.3               go-module  CVE-2022-30580  High      < 0.1% (3rd)   < 0.1
stdlib         go1.18.2    *1.19.8, 1.20.3                go-module  CVE-2023-24537  High      < 0.1% (3rd)   < 0.1
stdlib         go1.18.2    1.17.11, *1.18.3               go-module  CVE-2022-30629  Low       < 0.1% (14th)  < 0.1
stdlib         go1.18.2    *1.22.11, 1.23.5, 1.24.0-rc.2  go-module  CVE-2024-45341  Medium    < 0.1% (4th)   < 0.1
stdlib         go1.18.2    *1.19.7, 1.20.2                go-module  CVE-2023-24532  Medium    < 0.1% (4th)   < 0.1
stdlib         go1.18.2    *1.18.7, 1.19.2                go-module  CVE-2022-41715  High      < 0.1% (2nd)   < 0.1
stdlib         go1.18.2    1.19.6                         go-module  CVE-2022-41724  High      < 0.1% (2nd)   < 0.1
stdlib         go1.18.2    *1.18.7, 1.19.2                go-module  CVE-2022-2879   High      < 0.1% (2nd)   < 0.1
stdlib         go1.18.2    *1.23.11, 1.24.5               go-module  CVE-2025-4674   High      < 0.1% (1st)   < 0.1
stdlib         go1.18.2    1.17.12, *1.18.4               go-module  CVE-2022-28131  High      < 0.1% (0th)   < 0.1
stdlib         go1.18.2    *1.19.10, 1.20.5               go-module  CVE-2023-29403  High      < 0.1% (0th)   < 0.1
stdlib         go1.18.2    *1.22.12, 1.23.6, 1.24.0-rc.3  go-module  CVE-2025-22866  Medium    < 0.1% (0th)   < 0.1
stdlib         go1.18.2    *1.21.11, 1.22.4               go-module  CVE-2024-24789  Medium    < 0.1% (0th)   < 0.1
stdlib         go1.18.2    1.17.12, *1.18.4               go-module  CVE-2022-1962   Medium    < 0.1% (0th)   < 0.1

tianon · 2025-08-18T16:45:48Z

We take security very seriously - if there really is a known exploit in gosu, please report it responsibly and we'll get it patched ASAP. However, if you run govulncheck (which your security scanner should really be using to trim that list - please report this to them), you'll see that the list is much smaller in practice (it should be down to exactly one or zero, and the one will be https://github.com/tianon/gosu/blob/e845c46b6bedb4457cda8c88814c30a53cc6c9e7/govulncheck-with-excludes.sh#L9-L13).

See also https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves

jlcox1970 · 2025-08-18T22:07:13Z

@tianon
as is stated both here and in your repo for gosu, out in the enterprise world people dont use govulncheck as so will always see the CVE list regardless.

I am not understanding your inertia to the change that in all honesty would just take you to compile your gosu under a new go version

OR, remove it all together as is not required in docker as you can just use the USER in the Dockerfile to set and forget as there is no part of of postgres that requires to be run as root after you build the container.

This would remove all the issues and make the community happy

I have created a postgres container that has no gosu, runs as postgres and is alpine so as to keep the CVE list small

This is what all maintainers strive for, no tech debt and as small an attack surface as possible....

https://hub.docker.com/r/jlcox1970/postgresql-hardened

I implore you to do the simple easy thing and either upgrade the version or remove it entirely

reneleonhardt · 2025-08-19T13:02:50Z

@jlcox1970 Thank you so much for providing a minimal docker image, much obliged 🙏

The text works, can you correct the link?
Can you publish a repo for the community to contribute?

jlcox1970 · 2025-08-19T21:24:06Z

@reneleonhard,
I have updated the link above and created a repo
https://gitlab.com/jlcox70/postgres-secure

I currently dont have an automated build pipeline but I will set one up over the next few days

jlcox1970 · 2025-08-19T22:16:58Z

Weirdest part of this whole thread and the suposed "false possitive" @tianon is that for someone who works for Docker that this container even lists the KEV in the Docker Scout
Are you saying that Docker is also wrong.....

tianon · 2025-08-19T22:19:56Z

Correct - Docker Scout should also take govulncheck into account, and does not currently. I have discussed this with the appropriate team (which isn't mine).

Remove gosu based CVE by building gosu with current golang image

2d4d3fd

cleanup reference

nathanlaceyraft mentioned this pull request Feb 25, 2025

manually build gosu with current golang image to resolve CVE (pull/1323) #1324

Open

ankane mentioned this pull request Mar 24, 2025

0.8.0 flagged with CVE-2023-24538 pgvector/pgvector#805

Closed

austalakov mentioned this pull request Mar 26, 2025

Build gosu with a supported version of GO tianon/gosu#136

Open

ImreSamu mentioned this pull request Mar 31, 2025

Security Vulnerabilities in postgis/postgis:15-3.5 (Go 1.18.2, libxslt1.1, CVE-2023-39325) postgis/docker-postgis#415

Closed

reneleonhardt reviewed Jun 6, 2025

View reviewed changes

	FROM golang:1.23.6 AS gosubuilder
	FROM golang:1.23-alpine3.21 AS gosubuilder

Remove gosu based CVE by building gosu with current golang image #1323

Are you sure you want to change the base?

Remove gosu based CVE by building gosu with current golang image #1323

Uh oh!

Conversation

nathanlaceyraft commented Feb 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yosifkit commented Feb 25, 2025

Uh oh!

nathanlaceyraft commented Feb 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tianon commented Feb 25, 2025

Uh oh!

nathanlaceyraft commented Feb 25, 2025

Uh oh!

bgehman commented Mar 26, 2025

Uh oh!

reneleonhardt Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nathanlaceyraft Jun 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

reneleonhardt Aug 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

reneleonhardt Jun 6, 2025

Choose a reason for hiding this comment

Uh oh!

reneleonhardt Jun 6, 2025

Choose a reason for hiding this comment

Uh oh!

jlcox1970 commented Aug 15, 2025

Uh oh!

tianon commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jlcox1970 commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

reneleonhardt commented Aug 19, 2025

Uh oh!

jlcox1970 commented Aug 19, 2025

Uh oh!

jlcox1970 commented Aug 19, 2025

Uh oh!

tianon commented Aug 19, 2025

Uh oh!

Uh oh!

nathanlaceyraft commented Feb 25, 2025 •

edited

Loading

nathanlaceyraft commented Feb 25, 2025 •

edited

Loading

reneleonhardt Jun 6, 2025 •

edited

Loading

nathanlaceyraft Jun 16, 2025 •

edited

Loading

reneleonhardt Aug 16, 2025 •

edited

Loading

tianon commented Aug 18, 2025 •

edited

Loading

jlcox1970 commented Aug 18, 2025 •

edited

Loading