linux-kernel - Re: [PATCH v2 00/14] Add SPDX SBOM generation tool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260127231037.GA3378797@ax162>
Date: Tue, 27 Jan 2026 16:10:37 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Luis Augenstein <luis.augenstein@...tech.com>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Greg KH <gregkh@...uxfoundation.org>
Cc: nsc@...nel.org, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	maximilian.huber@...tech.com
Subject: Re: [PATCH v2 00/14] Add SPDX SBOM generation tool

Hi Luis, Greg, and Miguel,

Sorry for not having any input up until this point, as I felt this was
not going to be ready for 6.20/7.0 and I wanted to focus on getting
things ready for that release (on top of other work). Some high level
comments based on what has been discussed so far to follow, it was going
to be hard to reply inline to everything. I will try to take a closer
look at v3 in the next couple of weeks but I might not get to it until
after the merge window closes.

I agree with Miguel that if there is any information that we can add to
the .cmd files or another file generated by Kbuild to avoid hard coding
things while preprocessing, it should be pursued, as we should be making
the build system work for us. We have already some prior art with post
processing Kbuild files like scripts/clang-tools/gen_compile_commands.py
so I am not too worried about that. At the same time, I do like how self
contained the implementation currently is, as it is just there available
for people to use if they want it but it impacts nothing if it is not
being used. It also makes it an easier maintenance burden in the
immediate term, as I would like this to be shown as useful to various
entities before it starts to entangle itself into the build system.

I think getting rid of CONFIG_SBOM in favor of just an sbom make target
is a good direction. If we really wanted some sort of configuration
option, I think it should only mean "generate an SBOM by default" and
nothing more but I worry about this getting turned on via compile
testing and causing issues. At that point, it feels like whatever entity
wants this information can just add 'make sbom' to their build system
since they may have to control the outputs beyond the simple "all" make
target.

I wonder if it would be better for this to live within scripts/ instead
of tools/, as that should allow it to be integrated into the build
process a little bit more naturally, such as using $(Q) instead of @,
$(PYTHON3) instead of the bare python3, being able to access
CONFIG_MODULES directly, and cleaning up the actual implementation of
the sbom target in Makefile.

Cheers,
Nathan