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

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/copyright

The 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.json

When 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.

PHP, Node and the other packages built from upstream

The PHP versions, the web application firewall's rule set, Node.js, imapsync and the test certificate authority are somebody else's software that CoreCP builds or repackages. Each of them is built in a clean, throwaway Ubuntu 26.04 environment, without internet access while it builds, from sources that were downloaded and checked against a known fingerprint beforehand. They carry the same two files, and their bill of materials lists exactly those sources: for PHP 8.4 that is PHP itself and every extension, each with its version, where it was downloaded, its fingerprint and its licence.

V=$(dpkg-query -W -f='${Version}' corecp-php84)
BASE=https://packages.corecp.dev/corecp/releases/corecp-php84/$V
curl -fsS "$BASE/corecp-php84_${V}_amd64.sbom.cdx.json" | python3 -m json.tool | grep '"name"'

Every package on the edge channel has these files; a package version that was published before this practice was taken out of the channel rather than given a bill of materials after the fact.

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.50.0~dev.1 file=corecp-agent_0.50.0~dev.1_amd64.sbom.cdx.json

A 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.

For the packages built from upstream it also says the build ran in the clean environment without internet access, which environment that was (by its fingerprint), and every tool installed in it. Two builds of the same sources give the same list of files — the same names, permissions and versions; the note does not claim the files are identical byte for byte.

It does not say the build could not have been tampered with. Here the machine that builds is also the machine that distributes and signs, and the note writes that down itself. So read it as an accurate table of contents that is hard to forge, not as proof of an untouched build.

A release always comes from a protected tag

A CoreCP version (0.50.0, or a candidate 0.50.0~rc.1) is only built from a tag in the central GitHub repository — v0.50.0 or v0.50.0-rc.1. That repository refuses to move or delete a tag, so the source behind a version number is fixed for good.

Before building, the build server asks GitHub which source the tag points at, and refuses when its own copy disagrees — including when somebody changed a single file on the build server itself. A development version (with ~dev in the number) may come from a working copy; a version without ~dev never does.

You can see this in the provenance note of such a release: next to the source revision it names the tag (sourceTag) and the route the source arrived by (sourceRoute: remote for GitHub, bundle when GitHub was unreachable and the owner delivered the source as a file).