Where a release comes from
Most of what you install is somebody else's code. This page shows which parts, under what terms they may be shipped, and how to read back — without taking anyone's word for it — what an installed version is actually made of.
Written for: Administrator
Most of what you install is somebody else's code. This page shows which parts, under what terms they may be shipped, and how to read back — without taking anyone's word for it — what an installed version is actually made of.
The list of components
Go to Settings → General and press Read the licence. The second document in that panel, Third-party components, is the whole list: every Go module compiled into one of the programs, every npm package behind the web interface, and the font the panel sends to your browser. Above the list is how many there are and how many distinct licences they fall under; below it, every licence in full.
The same text sits on every server, in the file Debian keeps for it:
cat /usr/share/doc/corecp-agent/copyrightThe list is not maintained by hand. Every build compares it against the pinned dependencies, and a component whose licence has not been reviewed fails the build instead of quietly riding along. So "the list is complete" is not a promise but a condition of publishing at all.
Why not every licence is allowed
CoreCP is proprietary and is not delivered as source. Some licences require exactly that as soon as you give the program to somebody — the GPL family is the best-known example, and because a Go program bakes its dependencies into the executable, the whole agent would fall under it. Those licences are refused, with the reason attached. What is allowed are the licences that only ask for attribution (MIT, BSD, ISC, Apache-2.0) and the font licence OFL, which asks that its text travels with every copy — which is why it is in the panel in full.
The icons in the panel are drawn here. That saves kilobytes, and it also means no third party's licence is attached to them.
The bill of materials beside a release
Two extra files sit next to every published package: a bill of materials (an SBOM, in the CycloneDX format scanners read) and a provenance note saying which script built the package, with which tools, and from which source revision. They live under the same directory as the package:
V=$(dpkg-query -W -f='${Version}' corecp-agent)
BASE=https://packages.corecp.dev/corecp/releases/corecp-agent/$V
curl -fsS "$BASE/corecp-agent_${V}_amd64.sbom.cdx.json" -o sbom.json
curl -fsS "$BASE/corecp-agent_${V}_amd64.provenance.json" -o provenance.jsonWhen you need to know whether a vulnerable package is in your installation, the bill of materials is the answer: every component is in it with its version and its purl, the identifier vulnerability databases use.
Checking they are genuine
Both files are signed, and their hashes are also inside the signed release manifest — so whoever verified the manifest has verified these two as well. Checking one on its own takes the stock minisign:
curl -fsS https://packages.corecp.dev/corecp/keys/current.pub -o corecp.pub
curl -fsS "$BASE/corecp-agent_${V}_amd64.sbom.cdx.json.minisig" -o sbom.json.minisig
minisign -V -p corecp.pub -m sbom.json$ minisign -V -p corecp.pub -m sbom.json
Signature and comment signature verified
Trusted comment: corecp-attestation package=corecp-agent version=0.39.0 file=corecp-agent_0.39.0_amd64.sbom.cdx.jsonA release with no bill of materials is not published: signing refuses it. For packages older than this practice the manifest carries an empty list — so you know there is nothing, rather than having to guess.
What the provenance note does and does not prove
It says: this file, this hash, built by this script from this source revision, with these compiler versions, at this time, on this machine. It is signed, so you would notice if somebody edited it afterwards.
It does not say the build ran in an isolated environment, or that it is reproducible. Here the machine that builds is also the machine that distributes, and the note writes that down itself. So read it as an accurate table of contents that is hard to forge, not as proof that the build could not have been tampered with.
See also
- Licence and ownership — who owns CoreCP and what you tell a customer.
- Managing releases — channels, promoting and rolling back.