Re: [Buildroot] [PATCH 1/3] package/pkg-golang: record vendored Go modules in show-info

["Mattias Walström" <lazzer@gmail.com>]

Thomas Perale via buildroot <buildroot@buildroot.org> writes:

> Hi Mattias,
>
> I haven't totally check the series yet but during the ELCE2026 Buildroot dev
> meeting we have discussed this issue. Go is not the only case this would be
> required: Rust, the kernel, potentially NPM packages and other standalone
> packages that support generating an SBOM (such as wolfssl, brotli, ...) would
> also benefit from a proper SBOM generation support.

Hi Thomas,

Thanks for the context from the dev meeting, I wasn't aware of the
discussion. A generic SBOM step sounds like the right place for this, and
I'm happy to rework the series in whatever direction you settle on.

> The idea was to add a "<pkg>_SBOM" step to the generic package infrastructure
> so we can both have something shared per infra such as Go and individual package
> implementing their own procedure.

If it helps, the series is already split along those lines: a post-build
hook in pkg-golang.mk writes the module list to the build directory, and
generate-cyclonedx only reads a generic "vendored_dependencies" field from
show-info. Turning the hook into a $(2)_SBOM_CMDS step in pkg-generic
with pkg-golang providing the default should be straightforward, and
other infras could fill the same field.

> There are still some missing links before we move forward this way:
>
> - How do we support the variety of SBOM format (CycloneDX, SPDX, compilation
>   database)
> - Do we include in the CycloneDX SBOM or just reference it ?

I don't have a strong opinion. What the series does is record facts
(name, version, purl) in show-info and leave the format to the generator,
which keeps SPDX possible later. For packages that produce a complete SBOM
themselves (wolfssl, brotli), referencing it from the package component
seems simpler than merging, but I haven't tried.

> Some question for you for the Go case:
>
> - Would it make sense to use the utility CycloneDX maintain for Go instead [1] ?
>   If we go with the "<pkg>_SBOM" step I described it's something we could add
>   to the dependencies. And Rust packages could also use the CycloneDX utility
>   for Rust.
> - Can you compare the output of this utility to the one you propose so we can
>   better assess the pros and cons ?

I hadn't looked at cyclonedx-gomod before, so I tried it. I ran
"cyclonedx-gomod bin" (v1.12.0) on the Go binaries of an Infix [2] build
(x86_64) and compared it with what this series records for the same
packages:

  package      binaries  cyclonedx-gomod  this series
  podman            3         164             164
  cni-plugins      17          14              14
  yangerd           2          11              10
  webui             1           3               2
  netbrowse         1           0               0

Both read the build info Go embeds in the binary (go version -m), so the
module lists come out the same. The differences I found:

- podman: "+incompatible" versions. The series percent-encodes the "+"
  in the purl, cyclonedx-gomod leaves it as is.
- yangerd, webui: cyclonedx-gomod emits "pkg:golang/../features@(devel)"
  for a "replace ... => ../features" directive. The series skips local
  replacements since that code is part of the package source. I may be
  wrong that skipping is the right call.
- webui: the series records github.com/openconfig/goyang as
  pedigree.ancestors of the github.com/kernelkit/goyang fork that replaces
  it. cyclonedx-gomod reports only the fork.

Things cyclonedx-gomod can do that the series cannot: module hashes and
license detection. The hashes were empty in all 181 components here, as
Go doesn't record them for -mod=vendor builds. License detection needs
every module in the module cache; in our case the cache is only filled
when go-post-process runs on the same machine, so with a populated DL_DIR
or a mirror it would need to download the modules again at SBOM time. I
don't record licenses either, so neither approach gives us that today.

Practical differences: cyclonedx-gomod produces one document per binary,
so we would need to merge and deduplicate per package ourselves
(cni-plugins has 95 components for 14 modules), and it would be a new
host package that follows the latest Go release. The series is a small
Python script using the host go we already build, and it stores the
result in show-info rather than in CycloneDX directly. On the other hand
cyclonedx-gomod is maintained by the CycloneDX project, and if Rust and
others end up using the CycloneDX tools as well, consistency may matter
more than the points above.

Let me know what you'd like to see in a v2.

> [1] https://github.com/CycloneDX/cyclonedx-gomod

[2] https://github.com/kernelkit/infix

Best regards,
Mattias
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot