kubeovn / kube-ovn / 26897475070
26%
master: 26%

LAST BUILD BRANCH: fix-metallb-underlay-ip-port-mapping-conflict
DEFAULT BRANCH: master
Ran
Jobs 1
Files 212
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 25.657% (+0.006%) from 25.651%
26897475070

Pull #6817

github

oilbeater 
fix(build): always rebuild CNI plugins from source to avoid stale Go stdlib

The go-deps pipeline only rebuilds a downloaded binary from source when the
build-time trivy scan reports a fixable vulnerability for it; otherwise the
upstream prebuilt binary is shipped as-is. Those prebuilt CNI plugins embed
whatever Go toolchain they were released with, so a plugin that scans clean at
base-image build time keeps an outdated stdlib and turns vulnerable the moment a
new stdlib CVE is published. This is exactly what happened to ipvlan: it was not
flagged when the base image was built, kept the upstream Go 1.26.3 build, and was
later reported by `make scan` for CVE-2026-27145 / CVE-2026-42504 / CVE-2026-42507
(fixed in Go 1.26.4), while macvlan/portmap/loopback had been rebuilt and stayed
clean.

The conditional rebuild applies to all four CNI plugins equally; ipvlan was just
the one that drew the short straw. Since the plugins are cheap to build (unlike
kubectl), enlist loopback/macvlan/portmap/ipvlan unconditionally so they are
always compiled with the current Go toolchain and never pinned to the upstream
prebuilt binaries.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Mengxin Liu <liumengxinfly@gmail.com>
Pull Request #6817: fix(build): always rebuild CNI plugins from source to avoid stale Go stdlib

14820 of 57761 relevant lines covered (25.66%)

0.3 hits per line

Jobs
ID Job ID Ran Files Coverage
1 26897475070.1 212
25.66
 GitHub Action Run
Source Files on build 26897475070