Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 68e343be10
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| GHSA-32p9-57cr-4x65 | ||
| EEF-CVE-2026-65624 | ||
| EEF-CVE-2026-59248 | ||
| GHSA-q8x4-x7mp-5vg2 |
There was a problem hiding this comment.
In Helm installations where node ports are reachable, these parser vulnerabilities are not confined to Kubernetes probes: helm/templates/service.yaml exposes the workers' port 4000 via type: NodePort, and helm/templates/api-svc.yaml similarly exposes the gRPC/Cowboy listener on port 50050. An unauthenticated client can therefore exercise the HTTP/1.1 or HTTP/2 parsing paths before HealthCheck or the gRPC handler processes the request, so allowlisting these advisories leaves the exposed processes vulnerable to the documented resource-exhaustion attacks; upgrade the affected Cowboy stack or restrict the listeners before suppressing them.
Useful? React with 👍 / 👎.
| # (RepoProxyService server) and from its own internal gRPC client responses - | ||
| # internal cluster traffic, not untrusted input (same rationale already accepted in | ||
| # github_notifier/.mix-audit.txt). | ||
| GHSA-rv48-qqj5-crxg |
There was a problem hiding this comment.
In deployments where Kubernetes node ports are reachable, protobuf input is not limited to trusted cluster traffic: helm/templates/api-svc.yaml publishes the RepoProxy gRPC server as a NodePort, and hooks/grpc/endpoint.ex installs no authentication interceptor before protobuf decoding. A reachable client can consequently submit a deeply nested message and trigger the unbounded-recursion DoS described by this advisory, so this entry should not be allowlisted unless the endpoint is network-restricted or protobuf is upgraded.
Useful? React with 👍 / 👎.
| ARG ELIXIR_VERSION=1.18.1 | ||
| ARG OTP_VERSION=26.2.5.6 | ||
| ARG ALPINE_VERSION=3.21.6 | ||
| ARG OTP_VERSION=26.2.5.3 |
There was a problem hiding this comment.
Rolled back to 26.2.5.3 because 26.2.5.6 breaks the cold image build. On .6, mix local.hex fails fetching from builds.hex.pm with a TLS unsupported_certificate / key_usage_mismatch alert (OTP's cert-verification change rejects the hex endpoint's cert). Two cold builds on this branch reproduced it; pinning back to .3 builds green, and the only Dockerfile diff between the failing and passing commits is the OTP_VERSION arg. Proper .6 fix is a follow-up, not this PR.
alpine 3.21.6 ships libssl3/libcrypto3 3.3.6-r0, flagged CRITICAL for CVE-2026-31789 (openssl heap buffer overflow on 32-bit systems from large X.509 certificate processing). alpine 3.21.7 ships openssl 3.3.7, which fixes it. Elixir 1.18.1 / OTP 26.2.5.3 unchanged; the matching hexpm/elixir:1.18.1-erlang-26.2.5.3-alpine-3.21.7 image exists on Docker Hub for both amd64 and arm64.
The dependency bump inadvertently reverted OTP from 26.2.5.6 to 26.2.5.3. Restore OTP to match main and keep the intended Alpine 3.21.7 bump.
OTP 26.2.5.6 applies stricter TLS certificate validation that rejects the builds.hex.pm certificate chain (key_usage_mismatch) during mix local.hex in the Alpine base image build, failing the image build. Pin OTP to 26.2.5.3 and keep the Alpine 3.21.7 bump. The OTP version delta is a tracked follow-up.
68e343b to
344fd1e
Compare
3 participants
No description provided.