Generate the third-party notices and the bill of materials

[iderex]

Anything downloadable owes its recipient a list of what is inside it. This board
will ship a binary, and the licences of whatever went into that binary travel with
it whether or not anybody wrote them down.

Two deliverables, and they answer different questions.

A third-party notices file, listing every dependency the shipped binary contains,
its version and its licence, with the licence texts that require reproduction
included in full. This is the legal obligation and it is not satisfied by a link,
because a link can rot and the obligation is to supply the text.

A software bill of materials generated at build time, from the build rather than
from a list somebody maintains. This is the operational answer to the question of
what an operator is running, and it is the item the parity work moved out of the
gate and into the release build, because it belongs where the artefact is built.
This issue sits with the legal work rather than with the release because the
notices half is a legal obligation that stands whether or not anything is ever
published, and the release workflow that attaches both is blocked on it.

Generated rather than written is the point of both. A hand-maintained list of
dependencies is correct on the day it is written and wrong shortly afterwards, and
it is wrong in the direction that matters, which is a dependency present in the
binary and absent from the list.

If the runner ends up with no third-party dependencies at all, which the language
and dependency decisions make plausible, then the notices file says exactly that
and the bill of materials is generated anyway. An empty result that was produced is
a different statement from a file nobody created.

Done when both artefacts are generated by the release build, both are attached to
the release, and a run against a tree with a dependency added produces a notices
file that lists it.

[iderex]

The generation half of the notices landed in #134, merged as 466d63a855dd4460d994c6c024805108b78264de.

internal/notices renders the document from the module set the toolchain records inside a binary, and cmd/notices takes that binary and a module cache root as its two arguments and writes the document to standard output. It opens no connection and reads no environment variable, so what it produced can be reproduced by hand from the two paths in its command line. Nothing was added to go.mod: the module table is read with debug/buildinfo from the standard library, so the list comes from the build rather than from anything anybody maintains.

A module whose licence text cannot be read is refused under dependency-has-no-licence-text and named in a section of the document saying it is incomplete by exactly those entries, rather than dropped from a file that then reads as finished. I proved that bites by deleting it: replacing the refusing arm with a silent skip turns exactly the three refusing cases red and leaves the neighbour they name green.

go test ./internal/notices -count=1

Where the three legs of the done-when stand.

The dependency leg is proved for the render and not for a tree. TestADependencyAddedToTheBuildIsListed takes the module set of the case with no dependencies, adds the one from the case that has one, and asserts the document names it and carries its licence text where the first document did neither. What it does not do is compile a module that requires something, because that needs a fetch and this suite runs with no network. So what is measured is that a dependency present in a build reaches the document, not that adding a require line to a tree reaches it.

Generated by the release build, and attached to the release, are both unmet and neither can be met here. There is no release workflow in this tree and no release:

gh api repos/Flowfin/lab/releases --jq 'length'
0

Both belong to #41, which is where the artefacts are attached, and the bill of materials belongs there with them for the reason this issue already gives: it is generated at build time, from the build, and that is the release workflow. This issue stays open on those two legs.

[iderex]

The third leg is measured now. #136 adds cmd/notices/tree_test.go, which builds
one tree twice, the second differing from the first by a require line and an
import, and holds the difference between the two documents. The first must not
name the module and must carry the sentence saying there is nothing to disclose.
The second must name it and reproduce the text it shipped.

What made this leg look unreachable was the fetch. The module is served out of a
directory the test lays out as a module proxy, the checksum database is off, the
toolchain is pinned to the installed one so a go directive is never a download,
and the module cache is a temporary directory, so the licence text in the
document came from that run rather than from what the machine had downloaded
before it. Nothing traced the process, so this is a property of how the test is
written rather than an observation of one.

I proved it bites by deleting the line that collects the modules. With
build.Deps = append(build.Deps, module) in cmd/notices/main.go replaced by a
discard, go test -count=1 ./cmd/... ./internal/... reddens cmd/notices and
nothing else, and inside that package it reddens one test:

--- PASS: TestTheModuleTableOfARealBinaryReachesTheDocument (1.69s)
--- PASS: TestABrokenInvocationIsNotARefusal (1.49s)
--- FAIL: TestATreeWithADependencyAddedProducesADocumentThatListsIt (3.98s)

That is the argument for the test existing. internal/notices stays green
because its cases construct the module set themselves, and the neighbour in
cmd/notices stays green because the binary it reads has no dependency, so a
build read wrongly leaves both of them saying the binary contains no third-party
module.

#136 is not merged. Audit workflows (zizmor) is red on its head for two
findings in .github/workflows/codeql.yml, which that branch does not contain,
and #137 carries them with the commands behind them. Every other check on the
head is green.

The other two legs stand where the last note on this issue left them.