Repository navigation
[BEE-1343] Security fix service binary in localstack docker desktop - #109
Conversation
Moves the builder from golang:1.25-alpine to golang:1.26-alpine. Go 1.25 is EOL and the floating tag is stuck at 1.25.14; the three flagged stdlib CVEs are only fixed in 1.26.9 / 1.27.2, so a rebuild alone no longer clears them. The tag stays floating on the 1.26 line so future stdlib CVEs keep self-healing on routine rebuilds. CVE-2026-78667 net/http CVE-2026-78669 net/http/internal/http2 CVE-2026-97031 crypto/tls Bumps golang.org/x/net to v0.60.0, clearing CVE-2026-78669 in the module copy of http2. x/net@v0.60.0 requires go 1.26, which raises the go directive; x/crypto, x/sys and x/text move with it as MVS requirements. Bumps TAG to 2026.10.0. Verified with trivy: service gobinary goes from 5 HIGH to 1 HIGH. The remainder is CVE-2026-55677 against echo v3.3.10+incompatible, which has no fixed version for the v3 module path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One unfixable HIGH leftover but otherwise clean. |
|
|
||
| ### Changed | ||
|
|
||
| - Security update — clears CVE-2026-78667, CVE-2026-78669, CVE-2026-97031 |
There was a problem hiding this comment.
Just a quick thought on listing the exact CVE numbers...in general publishing specific vulnerability details can sometimes make it easier to target unpatched versions. Do you think we should generalize the wording here, or is there a reason we should specify them for this release?
There was a problem hiding this comment.
I guess the thing is you can just run trivy (oss) against any version of the public images and yield the same list? I am not sure there is much more security in obfuscation here but providing direct links might prompt people on the other hand to update where "Security update" might no be a lot of information.
There was a problem hiding this comment.
True, also probably does not matter in this case as I cannot think of any harm you could do with just the extension....Just looks a bit odd to say to the world "yo you can exploit this with my image" haha instead of letting them figure it out on it's own....but I'm also happy to let it merge like so 👍
security-rebuild.yml reads TAG from the Makefile as the currently published version and scans that image, then bump-version.sh writes the new TAG and CHANGELOG entry itself. A manual bump to 2026.10.0 would make it scan a tag that was never published. Reverts the Makefile and CHANGELOG changes from the previous commit; the workflow will produce the same 2026.10.0 entry on release. Also updates the README's builder reference to golang:1.26-alpine. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Moves the builder from golang:1.25-alpine to golang:1.26-alpine. Go 1.25 is EOL and the floating tag is stuck at 1.25.14; the three flagged stdlib CVEs are only fixed in 1.26.9 / 1.27.2, so a rebuild alone no longer clears them. The tag stays floating on the 1.26 line so future stdlib CVEs keep self-healing on routine rebuilds.
CVE-2026-78667 net/http
CVE-2026-78669 net/http/internal/http2
CVE-2026-97031 crypto/tls
Bumps golang.org/x/net to v0.60.0, clearing CVE-2026-78669 in the module copy of http2. x/net@v0.60.0 requires go 1.26, which raises the go directive; x/crypto, x/sys and x/text move with it as MVS requirements.
Bumps TAG to 2026.10.0.
Verified with trivy: service gobinary goes from 5 HIGH to 1 HIGH. The remainder is CVE-2026-55677 against echo v3.3.10+incompatible, which has no fixed version for the v3 module path.