Antag, at et desktopprogram findes både på udgivelsessiden og et spejl. Filnavne og versioner matcher, men brugeren skal stadig vide, om filerne er ens, hvem der udgav dem, om de kommer fra forventet kode og byggeproces, og om de passer til enheden.
Spørgsmålene kræver forskellige beviser. At kalde alt ”sikkerhedscertificering” skaber forventninger, kontrollerne ikke kan indfri, og kan skjule huller i udgivelsesprocessen for udviklerne.
Kontrolsummer viser, om filer matcher
En hash af downloaden sammenlignet med forventet værdi kan fastslå ens indhold. Værdien skal komme fra en betroet kanal. Hvis fil og kontrolsum kommer fra samme ubekræftede side, fastslår overensstemmelsen ikke udgiverens identitet.
Forskellige hashes betyder forskellige filer, men beviser ikke alene ondsindet hensigt. Andre builds, ompakning eller forkert download kan forklare forskellen. Stop med at betragte filen som verificeret, og kontrollér kilde, målplatform og den tilhørende kontrolsum igen.
Udgivere bør vedligeholde klare filnavne, versioner og kontrolsummer samlet. Brugere skal ikke kopiere en gammel artikels hash og sammenligne med en anden platforms eller et andet builds installationsfil.
Signaturer kræver kontrol af forventet identitet
En digital signatur knytter underskriveren til data, men kontrollen skal også afgøre, om identiteten er den forventede. Sigstores dokumentation kræver kontrol af signatur sammen med relevante identitets- og udstedervilkår. Sigstores verifikationsdokumentation
Ved ”gyldig signatur” bør brugeren også undersøge, hvilken udgiver eller arbejdsgang den repræsenterer. Udviklere skal angive tilladte underskrivere af officielle udgivelser. En matematisk gyldig signatur gør ikke automatisk filen officiel.
Ved certifikat- eller metodeskift kræves en kontrollerbar forklaring. At bede brugeren om straks at stole på et ukendt certifikat er ikke en fuldstændig opdateringsproces.
Byggeoprindelse knytter pakken til produktionsprocessen
GitHubs artefaktattestationer kan registrere byggeoprindelse og verificere forbindelsen til kodearkiv og arbejdsgang. De viser, hvordan filen blev skabt, men den faktiske artefakt og forventede identitet skal stadig kontrolleres. GitHubs attestationer
SLSAs byggeniveauer adskiller eksisterende oprindelsesdata, signerede data fra en hostet platform og strengere beskyttelse af byggeplatformen. Angiv omfang og dokumentation ved omtale af et niveau; tallet er ikke en vurdering af alle softwarerisici. SLSAs byggeniveauer
| Bevis | Hjælper primært med at fastslå | Beviser ikke alene |
|---|---|---|
| Kontrolsum | At forventet filindhold er hentet | Udgiveridentitet eller sikker programadfærd |
| Digital signatur | Hvem der signerede hvilke data | At underskriveren opfylder dine tillidskrav |
| Byggeoprindelse | Hvilken proces der skabte artefakten | At al kode og alle afhængigheder er problemfri |
| Reproducerbart build | At samme artefakt kan genskabes under bestemte vilkår | At programmet er uden sårbarheder eller uønsket adfærd |
Beviserne kan supplere hinanden. Forklar, hvad der tilbydes, og hvilke kontroller der fortsat skal udføres uafhængigt.
Reproducerbare builds kræver klare input og miljøer
Reproducible Builds definerer et reproducerbart build som bitidentiske angivne artefakter fra samme kildekode, byggemiljø og instruktioner. Det er mere præcist end ”det kompilerer på min computer”. Definition af reproducerbare builds
Bevar værktøjskæde, låste afhængigheder, byggeparametre og deres forbindelse til udgivelsens artefakter. Hvis reproducerbarhed ikke er opnået, så beskriv præcist, hvor langt genopbygningen når, frem for at udelade forskelle og erklære godkendt.
Forklar også det offentlige kodearkivs omfang. Det kan indeholde kernekode eller primært byggeværktøjer, konfiguration og programpakker genereret opstrøms. Brugeren skal vide, hvilke dele der faktisk kan undersøges og genopbygges for at vurdere oprindelsesbeviserne rimeligt.
En praktisk rækkefølge for downloadkontrol
- Bekræft udgivelsesarkivet via projektets officielle indgang, ikke kun søgeannoncer eller videresendte links.
- Læs versionsnoter, og kontrollér operativsystem, processorarkitektur og udgivelseskanal.
- Sammenlign filen med den rette kontrolsum; kontrollér også forventet identitet og omfang, når signatur eller oprindelse findes.
- Kontrollér vedligeholdelse og kendte begrænsninger uden at tolke ”seneste” som produktionsklar.
- Ved modstridende oplysninger: behold version og filnavn, og spørg projektets supportkanaler.
Alle behøver ikke blive byggeingeniører. Produktet kan samle komplicerede beviser på en klar side: filernes oprindelse, målgruppe, kontrolmetoder og kontaktvej ved afvigelser.
Langsigtet vedligeholdelse af informationskæden er mere værdifuld end et engangsmærke ”verificeret”. Forklaringer skal stadig være tilgængelige, når en gammel udgivelse trækkes tilbage, signeringen ændres eller en opdatering fejler.
AlphaBizs offentlige arkivbeskrivelse skelner mellem byggeværktøjer og programpakker genereret opstrøms. Beskriv derfor det faktiske kontrolomfang uden at sammenblande offentligt arkiv, komplet kildekode og reproducerbare udgivelser. AlphaBizs projektbeskrivelse
Udviklere kan starte med en oversigt over udgivelsesbeviser; brugere med én download af et ofte anvendt program. Del den verifikationsinformation, du ønsker på udgivelsessider, i AlphaBiz Discussions.