Anta at et skrivebordsprogram finnes både på utgivelsessiden og et speil. Filnavn og versjoner stemmer, men brukeren trenger fortsatt svar: er filene like, hvem publiserte dem, kommer de fra forventet kode og byggeprosess, og passer de enheten?
Spørsmålene krever ulike bevis. Å kalle alt «sikkerhetssertifisering» skaper forventninger kontrollene ikke kan innfri, og kan få utviklere til å overse hull i utgivelsesprosessen.
Kontrollsummer viser om filer samsvarer
En hash av nedlastingen sammenlignet med forventet verdi kan bekrefte likt innhold. Verdien må komme fra en betrodd kanal. Hvis fil og kontrollsum kommer fra samme ubekreftede side, fastslår samsvaret ikke utgiveridentiteten.
Ulike hasher betyr ulike filer, men beviser ikke alene ondsinnet hensikt. Andre bygg, ompakking eller feil nedlasting kan forklare forskjellen. Slutt å behandle filen som verifisert, og kontroller kilde, målplattform og riktig kontrollsum på nytt.
Utgivere bør vedlikeholde tydelige filnavn, versjonsinformasjon og kontrollsummer samlet. Brukeren skal ikke kopiere en hash fra en gammel artikkel og sammenligne med et annet bygg eller en annen plattforms installasjonsfil.
Signaturer krever forventet identitet
En digital signatur knytter en underskriver til data, men kontrollen må også fastslå om identiteten er den forventede. Sigstores dokumentasjon krever kontroll av signatur sammen med relevante identitets- og utstedervilkår. Sigstores verifiseringsdokumentasjon
Ved «gyldig signatur» bør brukeren sjekke hvilken utgiver eller arbeidsflyt den representerer. Utviklere må angi hvem som får signere offisielle utgivelser. En matematisk gyldig signatur gjør ikke automatisk filen offisiell.
Ved bytte av sertifikat eller signeringsmetode trengs en etterprøvbar forklaring. Å be brukeren straks stole på et ukjent sertifikat er ikke en fullstendig oppdateringsprosess.
Byggeopphav knytter pakken til produksjonsprosessen
GitHubs artefaktattestasjoner kan registrere byggeopphav og bekrefte tilknytning til kodelager og arbeidsflyt. De viser hvordan filen ble laget, men den faktiske artefakten og forventede identiteten må fortsatt kontrolleres. GitHubs attestasjoner
SLSAs byggenivåer skiller mellom opphavsopplysninger, signerte opplysninger fra en driftet plattform og strengere beskyttelse av byggeplattformen. Oppgi omfang og grunnlag ved nivåangivelse; tallet vurderer ikke alle programrisikoer. SLSAs byggenivåer
| Bevis | Hjelper primært å fastslå | Beviser ikke alene |
|---|---|---|
| Kontrollsum | At forventet filinnhold er hentet | Utgiveridentitet eller trygg programatferd |
| Digital signatur | Hvem som signerte hvilke data | At underskriveren oppfyller dine tillitskrav |
| Byggeopphav | Hvilken prosess som laget artefakten | At all kode og alle avhengigheter er feilfrie |
| Reproduserbart bygg | At samme artefakt kan gjenskapes under gitte vilkår | At programmet mangler sårbarheter eller uønsket atferd |
Bevisene kan utfylle hverandre. Forklar hva som tilbys, og hvilke kontroller som fortsatt må gjøres uavhengig.
Reproduserbare bygg trenger tydelige inndata og miljøer
Reproducible Builds definerer et reproduserbart bygg som bitidentiske angitte artefakter fra samme kildekode, byggemiljø og instruksjoner. Det er mer presist enn «det kompilerer på min maskin». Definisjon av reproduserbare bygg
Behold verktøykjede, låste avhengigheter, byggeparametre og koblingen til utgivelsens artefakter. Hvis reproduksjon ikke er oppnådd, beskriv nøyaktig hvor langt gjenbyggingen kommer, fremfor å utelate forskjeller og erklære godkjent.
Forklar også det offentlige kodelagerets omfang. Det kan inneholde kjernekode eller hovedsakelig byggeverktøy, konfigurasjon og programpakker generert oppstrøms. Brukerne må vite hvilke deler de faktisk kan undersøke og bygge om for å vurdere opphavsbevisene rimelig.
En praktisk rekkefølge for nedlastingskontroll
- Bekreft utgivelseslageret via prosjektets offisielle inngang, ikke bare søkeannonser eller videresendte lenker.
- Les versjonsnotatene og sjekk operativsystem, prosessorarkitektur og utgivelseskanal.
- Sammenlign filen med riktig kontrollsum; sjekk også forventet identitet og omfang når signatur eller opphav finnes.
- Kontroller vedlikehold og kjente begrensninger uten å tolke «nyeste» som produksjonsklart.
- Ved motstridende opplysninger: behold versjon og filnavn og spør prosjektets støttekanaler.
Alle trenger ikke bli byggeingeniører. Produktet kan samle kompliserte bevis på en tydelig side: hvor filene kommer fra, hvem de passer, hvordan de kontrolleres og hvor avvik meldes.
Langsiktig vedlikehold av informasjonskjeden er mer verdifullt enn et engangsmerke «verifisert». Forklaringer må fortsatt finnes når en gammel utgivelse trekkes, signeringen endres eller en oppdatering feiler.
AlphaBizs offentlige lagerbeskrivelse skiller byggeverktøy fra programpakker generert oppstrøms. Beskriv derfor det faktiske inspeksjonsomfanget uten å blande offentlig lager, komplett kildekode og reproduserbare utgivelser. AlphaBizs prosjektbeskrivelse
Utviklere kan starte med en oversikt over utgivelsesbevis; brukere med én nedlasting av et ofte brukt program. Del hvilken verifiseringsinformasjon du ønsker på utgivelsessider i AlphaBiz Discussions.