feat: add make sbom target

[MarkAtwood]

Summary

Adds make sbom, make install-sbom, and make uninstall-sbom targets to the autotools build.

• Stages a temporary install to extract the built .so for hashing
• Dumps preprocessor defines via cc -dM -E for the options snapshot
• Calls gen-sbom (from wolfssl scripts/gen-sbom) to produce CycloneDX and SPDX outputs
• Validates SPDX with pyspdxtools

Usage

```sh
./configure --with-wolfssl=/path/to/wolfssl/install
make
make sbom WOLFSSL_DIR=/path/to/wolfssl/source
```

Outputs: wolfssh-<version>.cdx.json, wolfssh-<version>.spdx.json, wolfssh-<version>.spdx

Requirements

• WOLFSSL_DIR must point to a wolfssl source tree containing scripts/gen-sbom (available on the feat/sbom-embedded branch of wolfssl)
• python3 and pip install spdx-tools on the build host

Test plan

• ./configure --with-wolfssl=... && make && make sbom WOLFSSL_DIR=...
• Verify three output files are produced
• pyspdxtools --infile wolfssh-*.spdx.json passes validation

[Copilot]

Pull request overview

Adds SBOM generation and install/uninstall targets to the autotools build, intended to produce CycloneDX + SPDX outputs and validate SPDX on the build host.

Changes:

• Add make sbom, make install-sbom, and make uninstall-sbom targets plus related variables/cleanup in Makefile.am.
• Extend configure.ac to discover python3 / pyspdxtools and to break out libtool version-info components into separate substituted variables.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
Makefile.am	Adds SBOM generation/validation targets and output staging/cleanup rules.
configure.ac	Adds tool discovery for SBOM prerequisites and refactors libtool version-info variables.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ejohnstown]

Tested make sbom end-to-end on macOS (--enable-all, gen-sbom from wolfssl feat/sbom-embedded, spdx-tools + pcpp installed): exits 0, all three outputs produced, the Mach-O .dylib discovery branch fires, the trap cleans up the staging tree and temp defines file, the configured feature macros (WOLFSSH_SFTP/SCP/CERTS/AGENT/SSHD, NO_INLINE, NDEBUG) now appear in the SBOM, and pyspdxtools re-validation passes clean. Two follow-ups below, none blocking.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

[aidangarske]

🐺 Skoll Code Review

Overall recommendation: REQUEST_CHANGES
Findings: 2 total — 2 posted, 0 skipped

Posted findings

• [High] Default SBOM license contradicts source license headers — Makefile.am:98
• [Medium] SBOM workflow can pass without exercising the new target — .github/workflows/sbom.yml:64-79

Review generated by Skoll.

[jackctj117]

Skoll Multi-Scan Review

Modes: reviewOverall recommendation: COMMENT
Findings: 5 total — 5 posted, 0 skipped
4 finding(s) posted as inline comments (see file-level comments below)
1 finding(s) not tied to a diff line (full detail below)

One or more scans did not complete — the results below are partial.

Posted findings

• [Medium] [review] CI workflow pins wolfSSL to an unmerged PR ref for all events, including every pull_request — .github/workflows/sbom.yml:3-13, 41-46
• [Low] [review] wolfssl version.h parse uses [ \t] which does not match a literal tab — scripts/sbom.am:144-145
• [Low] [review] sbomdir hardcodes $(datadir)/doc/$(PACKAGE) instead of using $(docdir) — scripts/sbom.am:55
• [Low] [review] uninstall-hook removes SBOM files that plain make install never installs — scripts/sbom.am:185-196

Findings not tied to a diff line

SBOM targets silently require GNU make; ?= and GNU-only make functions are undocumented

File: scripts/sbom.am:46-63, Makefile.am:98
Function: sbom
Severity: Medium
Category: question

The fragment relies on GNU make extensions: conditional assignment ?= (SBOM_ARTIFACT ?= lib, SBOM_LICENSE_OVERRIDE ?= GPL-3.0-or-later) and the GNU-only functions $(wildcard ...), $(if ...), $(firstword ...), and $(addprefix ...). ?= is not one of Automake's documented assignment operators (=, +=, :=); confirm autoreconf accepts it without error. Note CI only runs autoreconf/configure on the wolfSSH tree when gen-sbom is detected (the steps.gate.outputs.have == 'yes' gate), so a hard Automake failure would only surface when CI checks out a wolfssl ref carrying the script. Under a non-GNU make (e.g. BSD make), SBOM_GEN/SBOM_LIB_GLOBS evaluate to empty and make sbom fails with a misleading 'gen-sbom not found' / 'no artifact found' error rather than a clear 'GNU make required' message.

Recommendation: Confirm autoreconf accepts ?= on the toolchain versions you support, and document in the README/comment that the SBOM targets require GNU make. Optionally guard with a clearer error when GNU-make features are unavailable.

Referenced code: scripts/sbom.am:46-63, Makefile.am:98-100 (3 lines)

---

Review generated by Skoll

[ejohnstown]

I guess my only issue is this PR depends on wolfSSL's PR 10343 to be merged first. The GitHub Action works without the PR merged, so that's OK. But someone may see the note about the make sbom and it not work if wolfSSH is released with this without the wolfSSL merge.

[MarkAtwood]

Note on the review threads above: the recipe moved out of Makefile.am into scripts/sbom.am, so the line numbers in the older comments now point at the wrong file. Makefile.am keeps five declaration variables and an include scripts/sbom.am.

Both Skoll findings are addressed. [High] default SBOM license: fixed in ccbaecc, Makefile.am:98 is now SBOM_LICENSE_OVERRIDE ?= GPL-3.0-or-later. [Medium] workflow can pass without exercising the new target: fixed in feaf692, the gate now fails on master when gen-sbom is missing or lacks --dep-wolfssl, so a green run means make sbom actually ran. Dismissing this automated review; human review still pending.

[ejohnstown]

Re-reviewed at 7e22d45a (+1 commit since my last pass: "fix: unpin SBOM CI from merged wolfssl PR ref").

Built and ran everything on macOS/arm64 (gcc-15, GNU make 3.81): --enable-all and plain ./configure against a wolfSSL 5.9.2 install, WOLFSSL_DIR pointing at a wolfssl checkout at origin/master (b83f5d60f), --prefix=/opt/wolfssh-sbom. The prefix is root-owned here, so the install was exercised through DESTDIR staging of the identical recipe.

Fixed: CI/docs unpinning

Verified master everywhere -- workflow input default, checkout ref, and both skip-notice strings -- plus the README and the sbom.am NOTE. wolfSSL master's gen-sbom is what I tested against throughout, exit 0.

The new "not an install prefix" error is a real improvement and fires correctly:

$ make sbom WOLFSSL_DIR=/opt/wolfssl
ERROR: no gen-sbom at /opt/wolfssl/scripts/gen-sbom
       WOLFSSL_DIR must name a wolfSSL *source tree*, not an
       install prefix such as /usr/local or /opt/wolfssl.
make: *** [sbom] Error 1

New: the vendored scripts/sbom.am has diverged from the canonical copy

That fix was made by editing scripts/sbom.am in this repo only. The file's own header says:

This is the canonical copy (wolfSSL repository, scripts/sbom.am); product repositories vendor a copy of it and must be kept in sync with this file.

sha256 of scripts/sbom.am:

wolfssl/scripts/sbom.am   282fd7ca...
wolfssh, previous head    282fd7ca...   (identical)
wolfssh, this head        5118dc2e...   (diverged)

Two hunks are wolfSSH-only now: the WOLFSSL_DIR-aware error block and the reworded --dep-wolfssl NOTE. A wolfssl checkout at origin/master does not carry them, and I found no open wolfSSL PR syncing them. Both changes are product-agnostic and belong upstream: land them in wolfSSL first, re-vendor here, and the file goes back to byte-identical. A CI check that diffs the vendored copy against the canonical one would stop this drifting again.

Still open

1. The recorded wolfSSL dependency version does not track the linked wolfSSL

This is the one I would hold on. SBOM_WOLFSSL_VERSION falls back to $(WOLFSSL_DIR)/wolfssl/version.h, but WOLFSSL_DIR is only there to locate gen-sbom and is a different input from --with-wolfssl. Built and linked against wolfSSL 5.9.2, with WOLFSSL_DIR pointing at a tree whose version.h says 9.9.9:

component: wolfssl 9.9.9 pkg:github/wolfSSL/wolfssl@v9.9.9

Worse, with gen-sbom present but no wolfssl/version.h under WOLFSSL_DIR, make sbom exits 0 and emits:

component: wolfssl None None

No version, no purl, no warning -- silently unscannable, which defeats the README's stated reason for the entry ("so vulnerability scanners can associate wolfSSL advisories with a wolfSSH deployment"). gen-sbom's pkg-config fallback does not rescue it, because a non-default prefix is not on the default PKG_CONFIG_PATH and the recipe does not set one.

The new error text sharpens the case: it tells users WOLFSSL_DIR is a source tree and explicitly not an install prefix -- i.e. not the thing you linked. Those are two independent inputs and only the wrong one feeds the dependency version.

Fixable entirely on the wolfSSH side through the documented SBOM_WOLFSSL_VERSION hook, so the canonical sbom.am does not need to change. I prototyped and verified this:

# configure.ac, after AC_CHECK_LIB([wolfssl],[wolfCrypt_Init],...)
# Record the version of the wolfSSL actually being linked, for the SBOM's
# dependency entry.  WOLFSSL_DIR (used by `make sbom` only to locate gen-sbom)
# may be an unrelated source tree, so it must not be the version source.
AC_MSG_CHECKING([wolfSSL version for SBOM])
WOLFSSL_VERSION=
if test -f "${wcpath}/include/wolfssl/version.h"; then
  WOLFSSL_VERSION=`sed -n ['s/.*LIBWOLFSSL_VERSION_STRING[ 	]*"\([^"]*\)".*/\1/p'] "${wcpath}/include/wolfssl/version.h"`
fi
AS_IF([test -n "$WOLFSSL_VERSION"],
      [AC_MSG_RESULT([$WOLFSSL_VERSION])],
      [AC_MSG_RESULT([unknown])])
AC_SUBST([WOLFSSL_VERSION])

# Makefile.am, after SBOM_DEP_WOLFSSL = yes
# Version of the linked wolfSSL, detected by configure from --with-wolfssl.
SBOM_WOLFSSL_VERSION = @WOLFSSL_VERSION@

With that applied it records 5.9.2 even when WOLFSSL_DIR claims 9.9.9, and an explicit make sbom SBOM_WOLFSSL_VERSION=... still overrides.

2. The CI regression guard does not guard

assert any(n.startswith('wolfssl:build:') for n in props), \
    'no wolfssl:build:* properties - options snapshot is empty'

The comment says this catches the options snapshot regressing to empty -- the bug fixed by "scripts/sbom.am: capture AM_CFLAGS/CFLAGS and configurable config.h". It does not. Reconfiguring plainly (exactly as CI does) and reintroducing that regression, i.e. dropping AM_CPPFLAGS from the -dM -E capture:

BASELINE  wolfssl:build:* count = 50   WOLFSSH_TERM present = True
REGRESSED wolfssl:build:* count = 48   WOLFSSH_TERM present = False
CI assertion any(startswith 'wolfssl:build:') -> True

config.h alone always supplies ~50 properties, so the assertion passes while the compiler-side capture is silently broken. Since CI configures plainly, WOLFSSH_TERM is the only marker that comes via AM_CPPFLAGS; asserting on wolfssl:build:WOLFSSH_TERM would make the guard real. (The embedded job's WOLFSSH_SFTP assertion is the strong one.)

3. Scope: the installed apps are not covered

An --enable-all install stages bin/wolfssh and bin/wolfsshd, but SBOM_ARTIFACT = lib means the only components are wolfssh (hash-source: lib) and wolfssl. sbom.am is lib-or-bin, so covering both needs a canonical change. Fine to defer, but given the CRA framing it is worth stating in the README rather than leaving implied.

4. Minor (both gen-sbom side, not this PR)

The main component is GPL-3.0-or-later while the wolfssl dependency component is hardcoded GPL-3.0-only, even though both projects' source headers carry the same "or (at your option) any later version" text. Also, properties on a wolfSSH SBOM are namespaced wolfssl:build:*.

Everything else verified green

• Reproducible across two runs (byte-identical); CDX timestamp matches git log -1 --format=%ct
• --enable-all captures all 12 WOLFSSH_* feature macros (63 properties vs 50 plain), and the library hash changes with configuration
• CPPFLAGS=-DDEFAULT_WINDOW_SZ=16384 at configure time lands in the SBOM
• VPATH build, and --disable-shared --enable-static correctly hashes libwolfssh.a
• install-sbom installs only under share/doc/wolfssh; uninstall-hook chain removes them from a plain make uninstall (0 files left)
• make clean removes the outputs (CLEANFILES correct)
• autogen.sh with WARNINGS=all,error exits 0
• make dist ships scripts/sbom.am; full tarball unpack -> configure -> make -> make sbom exits 0
• pyspdxtools validates the SPDX JSON; tag-value output carries DESCRIBES and DEPENDS_ON
• The GPL-3.0-or-later override is correct: src/ssh.c says "version 3 ... or (at your option) any later version", while LICENSING says only "GPLv3", which detect_license maps to GPL-3.0-only

Net: the mechanics hold up well outside the CI happy path. Findings 1 and 2 above, plus re-syncing scripts/sbom.am upstream, are what I would want before merge.