Waar een release vandaan komt

Elk pakket dat je installeert bestaat voor het grootste deel uit code van anderen. Deze pagina laat zien welke, onder welke voorwaarden dat mag, en hoe je van een geïnstalleerde versie terugleest waaruit hij is opgebouwd — zonder iemand op zijn woord te geloven.

De lijst van onderdelen

Ga naar Instellingen → Algemeen en druk op Licentie lezen. Het tweede document in dat paneel, Onderdelen van derden, is de volledige lijst: elke Go-module die in een van de programma's is meegecompileerd, elk npm-pakket achter de webinterface, en het lettertype dat het paneel aan je browser meestuurt. Boven de lijst staat hoeveel het er zijn en onder hoeveel verschillende licenties ze vallen; daaronder staat elke licentie voluit.

Dezelfde tekst staat op elke server, in het bestand dat Debian daarvoor gebruikt:

cat /usr/share/doc/corecp-agent/copyright

De lijst wordt niet met de hand bijgehouden. Bij elke build wordt hij vergeleken met de vastgelegde afhankelijkheden, en een onderdeel waarvan de licentie niet eerder is beoordeeld laat de build vallen in plaats van stilletjes mee te liften. Daardoor is "de lijst is compleet" geen belofte maar een voorwaarde om te kunnen publiceren.

Waarom niet elke licentie mag

CoreCP is eigen software en wordt niet als broncode geleverd. Sommige licenties verplichten dat wél zodra je het programma aan iemand geeft — de GPL-familie is daar het bekendste voorbeeld van, en omdat een Go-programma zijn onderdelen vast in het uitvoerbare bestand meebakt, zou de hele agent daaronder komen te vallen. Zulke licenties worden geweigerd, met de reden erbij. Toegestaan zijn de licenties die alleen om naamsvermelding vragen (MIT, BSD, ISC, Apache-2.0) en de lettertypelicentie OFL, die vraagt dat de tekst met elke kopie meereist — wat de reden is dat hij voluit in het paneel staat.

De iconen in het paneel zijn hier zelf getekend. Dat scheelt niet alleen kilobytes: er zit geen licentie van een ander aan vast.

De stuklijst bij een release

Naast elk gepubliceerd pakket staan twee extra bestanden: een stuklijst (SBOM, in het CycloneDX-formaat dat scanners lezen) en een herkomstnota die zegt door welk script, met welke gereedschappen en uit welke bronversie het pakket is gebouwd. Ze staan onder dezelfde map als het pakket zelf:

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

Wil je weten of een kwetsbaar pakket in je installatie zit, dan is de stuklijst het antwoord: elk onderdeel staat erin met zijn versie en zijn purl, de identificatie die kwetsbaarheidsdatabases gebruiken.

PHP, Node.js en de andere pakketten uit upstream-bronnen

De PHP-versies, de regelset van de websitefirewall, Node.js, imapsync en de test-certificaatautoriteit zijn software van anderen die CoreCP bouwt of herverpakt. Elk daarvan wordt gebouwd in een schone Ubuntu 26.04-omgeving die na afloop wordt weggegooid, zonder internettoegang tijdens het bouwen, uit bronnen die vooraf zijn gedownload en tegen een bekende vingerafdruk zijn gecontroleerd. Ze hebben dezelfde twee bestanden, en hun stuklijst noemt precies die bronnen: voor PHP 8.4 is dat PHP zelf en elke extensie, elk met versie, downloadadres, vingerafdruk en licentie.

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"'

Elk pakket op het kanaal edge heeft deze bestanden; een pakketversie die van vóór deze werkwijze stamt, is uit het kanaal gehaald in plaats van achteraf een stuklijst te krijgen.

Zelf nakijken dat ze echt zijn

Beide bestanden zijn ondertekend, en hun hash staat bovendien ín het ondertekende releasemanifest. Wie het manifest heeft gecontroleerd, heeft daarmee ook deze twee gecontroleerd. Los nakijken kan met het gewone 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

Een release zónder stuklijst wordt niet gepubliceerd: het ondertekenen weigert. Bij pakketten van vóór deze werkwijze staat in het manifest een lege lijst — dan weet je dat er niets is, in plaats van dat je het moet raden.

Wat de herkomstnota wél en niet bewijst

Ze zegt: dit bestand, deze hash, gebouwd door dit script uit deze bronversie, met deze compilerversies, op dit moment, op deze machine. Ze is ondertekend, dus je merkt het als iemand haar achteraf verandert.

Voor de pakketten uit upstream-bronnen zegt ze ook dat de build in de schone omgeving zonder internettoegang draaide, welke omgeving dat was (met zijn vingerafdruk) en welk gereedschap daarin geïnstalleerd was. Twee builds van dezelfde bronnen geven dezelfde bestandslijst — dezelfde namen, rechten en versies; de nota beweert niet dat de bestanden byte voor byte gelijk zijn.

Ze zegt niet dat er niet met de build geknoeid kan zijn. De machine die bouwt is bij ons ook de machine die distribueert en ondertekent, en de nota schrijft dat er zelf bij. Lees haar dus als een nauwkeurige inhoudsopgave die moeilijk te vervalsen is, niet als bewijs van een onaangeroerde build.

Een release komt altijd van een beschermde tag

Een CoreCP-versie (0.50.0, of een kandidaat 0.50.0~rc.1) wordt alleen gebouwd uit een tag in de centrale GitHub-repository — v0.50.0 of v0.50.0-rc.1. Die repository weigert een tag te verplaatsen of te verwijderen, dus de broncode achter een versienummer ligt voorgoed vast.

De bouwserver vraagt GitHub vóór het bouwen naar welke broncode de tag wijst en weigert als zijn eigen kopie het daar niet mee eens is — ook als iemand op de bouwserver zelf één bestand heeft veranderd. Een ontwikkelversie (met ~dev in het nummer) mag uit een werkkopie komen; een versie zonder ~dev nooit.

In de herkomstnota van zo'n release zie je dat terug: naast de bronversie staan de tag (sourceTag) en de route waarlangs de broncode binnenkwam (sourceRoute: remote voor GitHub, bundle als GitHub onbereikbaar was en de eigenaar de broncode als bestand heeft aangeleverd).

Zie ook

• Licentie en eigendom — van wie CoreCP is en wat je een klant vertelt.
• Releases beheren — kanalen, promoveren en terugrollen.