Een desktopapp staat zowel op de releasepagina als op een spiegelserver. Bestandsnamen en versienummers komen overeen, maar gebruikers hebben meer antwoorden nodig: zijn dit dezelfde bestanden, wie publiceerde ze, komen ze uit de verwachte code en het bouwproces en zijn ze geschikt voor dit apparaat?
Die vragen vereisen verschillende bewijzen. Elke controle ‘veiligheidscertificering’ noemen wekt verwachtingen die de methoden niet waarmaken en kan ontwikkelaars lacunes in hun releaseproces doen missen.
Checksums beantwoorden of bestanden overeenkomen
Na downloaden een hash berekenen en met de verwachte waarde vergelijken kan vaststellen of de inhoud overeenkomt. Een belangrijke voorwaarde is dat de verwachte waarde uit een betrouwbaar kanaal komt. Als bestand en checksum van dezelfde ongecontroleerde pagina komen, bewijst overeenstemming geen uitgeversidentiteit.
Omgekeerd betekent een andere hash dat de bestanden verschillen, maar bewijst dat op zichzelf geen kwade opzet. Andere builds, opnieuw verpakken of een verkeerde download kunnen verschillen verklaren. Behandel het bestand niet meer als gecontroleerde release en bevestig opnieuw bron, doelplatform en bijbehorende checksum.
Uitgevers moeten duidelijke bestandsnamen, versie-informatie en checksumoverzichten samen onderhouden. Gebruikers zouden geen hash uit een oud artikel hoeven vergelijken met een installatiebestand voor een ander platform of een andere build.
Handtekeningen vragen controle van de verwachte identiteit
Een digitale handtekening verbindt een ondertekenaar met ondertekende gegevens, maar er moet ook worden vastgesteld of dit de verwachte identiteit is. Sigstores documentatie vereist controles van handtekeningen samen met passende identiteits- en uitgeversvoorwaarden en illustreert daarmee dit onderscheid. Sigstore-verificatiedocumentatie
Bij ‘geldige handtekening’ moeten gebruikers ook nagaan welke uitgever of workflow zij vertegenwoordigt. Ontwikkelaars moeten bepalen welke identiteiten officiële releases mogen ondertekenen. Iedere handtekening die wiskundig klopt mag niet automatisch officiële status geven.
Bij veranderende certificaten of ondertekeningsmethoden moeten uitgevers een controleerbare uitleg geven. Gebruikers ter plekke vragen een onbekend certificaat te vertrouwen is geen volledig updateproces.
Buildherkomst koppelt een pakket aan zijn productieproces
Artefactattestaties van GitHub kunnen buildherkomst vastleggen en de relatie met repository- en workflowinformatie helpen controleren. Ze leveren bewijs over hoe een bestand is gemaakt, maar ook het daadwerkelijke artefact en de verwachte identiteit moeten worden gecontroleerd. GitHub-documentatie over artefactattestaties
SLSA-buildniveaus onderscheiden daarnaast bestaande herkomstgegevens, ondertekende herkomst van een gehost platform en strengere bescherming van dat platform. Vermeld bij een niveau het bereik en bewijs, in plaats van het getal als score voor alle softwarerisico’s te behandelen. SLSA-buildniveaus
| Bewijs | Wat het vooral helpt vaststellen | Wat het op zichzelf niet bewijst |
|---|---|---|
| Checksum | Of de verwachte bestandsinhoud is verkregen | Identiteit van de uitgever of veilig programmagedrag |
| Digitale handtekening | Wie welke gegevens ondertekende | Of de ondertekenaar aan uw vertrouwenseisen voldoet |
| Buildherkomst | Welk proces het artefact heeft gemaakt | Dat alle broncode en afhankelijkheden probleemloos zijn |
| Reproduceerbare build | Of hetzelfde artefact onder bepaalde voorwaarden opnieuw kan worden gebouwd | Dat de software geen kwetsbaarheden of ongepast gedrag heeft |
Deze bewijzen kunnen elkaar aanvullen. Ontwikkelaars moeten uitleggen welke zij leveren en welke controles nog onafhankelijk moeten gebeuren.
Reproduceerbare builds vragen expliciete invoer en omgevingen
Het project Reproducible Builds definieert een reproduceerbare build als een proces dat met dezelfde broncode, bouwomgeving en instructies de opgegeven artefacten bit voor bit identiek oplevert. Dat is een preciezer controledoel dan ‘het compileert op mijn computer’. Definitie van reproduceerbare builds
We adviseren toolchain, vastgelegde afhankelijkheden, bouwparameters en hun relatie met releaseartefacten te bewaren. Als reproduceerbaarheid niet is bereikt, leg dan nauwkeurig vast hoever opnieuw bouwen lukt, in plaats van verschillen weg te laten en succes te verklaren.
Ook het bereik van een openbare repository verdient uitleg. Die kan kernbroncode bevatten, of vooral bouwhulpmiddelen, configuratie en elders gegenereerde applicatiepakketten. Gebruikers moeten weten welke delen ze echt kunnen bekijken en herbouwen om herkomstbewijs redelijk te beoordelen.
Een praktische volgorde voor downloadcontrole
- Bevestig de releaserepository via de officiële projectingang, in plaats van alleen zoekadvertenties of doorgestuurde links te vertrouwen.
- Lees releaseopmerkingen en controleer besturingssysteem, processorarchitectuur en releasekanaal.
- Vergelijk het bestand met de bijbehorende checksum. Controleer bij beschikbare handtekeningen of herkomst ook de verwachte identiteit en het bereik.
- Controleer onderhoud en bekende beperkingen, zonder aan te nemen dat het label ‘latest’ geschiktheid voor productie betekent.
- Bewaar bij tegenstrijdige informatie versie en bestandsnaam en vraag verduidelijking via de ondersteuningskanalen van het project.
Hiervoor hoeft niet iedere gebruiker buildengineer te worden. Producten kunnen complexe bewijzen op een heldere releasepagina ordenen: waar bestanden vandaan komen, voor wie ze bedoeld zijn, hoe ze te controleren zijn en waar verschillen kunnen worden besproken.
Voor ontwikkelaars is deze informatieketen blijvend onderhouden waardevoller dan een eenmalig keurmerk ‘geverifieerd’. Gebruikers moeten relevante uitleg blijven vinden wanneer een oude release wordt ingetrokken, de ondertekening verandert of een update mislukt.
AlphaBiz onderscheidt in zijn openbare repositorybeschrijving bouwhulpmiddelen van elders gegenereerde applicatiepakketten. Bij dergelijke desktopapps moeten we eveneens het werkelijke inspectiebereik beschrijven, in plaats van openbare repository, volledige broncode en reproduceerbare releases gelijk te stellen. AlphaBiz-projectoverzicht
Ontwikkelaars kunnen beginnen met een volledig overzicht van releasebewijzen; gebruikers kunnen één download van een veelgebruikte app controleren. Deel in AlphaBiz Discussions welke verificatie-informatie u op releasepagina’s wilt zien.