Anta att ett skrivbordsprogram finns på både utgåvesidan och en spegel. Filnamn och versionsnummer matchar, men användaren behöver ändå veta om filerna är samma, vem som publicerat dem, om de kommer från förväntad kod och byggprocess och om de passar enheten.
Frågorna kräver olika bevis. Att kalla allt ”säkerhetscertifiering” väcker förväntningar som kontrollerna inte kan uppfylla och kan dölja luckor i utgivningen för utvecklarna.
Kontrollsummor visar om filer matchar
Att beräkna en hash efter hämtning och jämföra med ett förväntat värde visar om innehållet matchar. Värdet måste komma från en betrodd kanal. Om fil och kontrollsumma kommer från samma obekräftade sida fastställer överensstämmelsen inte utgivarens identitet.
Olika hashvärden betyder olika filer, men bevisar inte i sig illvilja. Olika byggen, ompaketering och felhämtningar kan orsaka skillnader. Sluta behandla filen som verifierad och kontrollera källa, målplattform och motsvarande kontrollsumma igen.
Utgivare bör hålla tydliga filnamn, versioner och kontrollsummelistor samlade. Användare ska inte behöva kopiera en gammal artikels hash och jämföra med en annan plattforms eller ett annat bygges installationsfil.
Signaturer kräver förväntad identitet
En digital signatur knyter undertecknaren till data, men kontrollen måste också avgöra om identiteten är den väntade. Sigstores dokumentation kräver kontroll av signatur samt relevanta identitets- och utfärdarvillkor. Sigstores verifieringsdokumentation
Vid ”giltig signatur” bör användaren även se vilken utgivare eller vilket arbetsflöde den representerar. Utvecklare ska ange tillåtna signerare av officiella utgåvor. Varje matematiskt giltig signatur gör inte filen officiell.
Vid certifikat- eller metodbyte behövs verifierbar information. Att be användaren omedelbart lita på ett okänt certifikat är ingen fullständig uppdateringsprocess.
Byggursprung knyter paket till produktionsprocess
GitHubs artefaktattesteringar kan registrera byggursprung och verifiera koppling till arkiv och arbetsflöde. De ger belägg för hur filen skapats, men den faktiska artefakten och förväntade identiteten måste fortfarande kontrolleras. GitHubs attesteringar
SLSAs byggnivåer skiljer mellan befintlig ursprungsinformation, signerad information från en driftad plattform och strängare plattformsskydd. Ange omfattning och underlag när en nivå nämns; siffran är inget betyg för alla programrisker. SLSAs byggnivåer
| Bevis | Hjälper främst fastställa | Bevisar inte ensamt |
|---|---|---|
| Kontrollsumma | Att rätt filinnehåll hämtats | Utgivaridentitet eller säkert beteende |
| Digital signatur | Vem som signerat vilka data | Att signeraren uppfyller dina tillitskrav |
| Byggursprung | Vilken process som skapat artefakten | Att all kod och alla beroenden är problemfria |
| Reproducerbart bygge | Att samma artefakt kan återskapas under angivna villkor | Att programmet saknar sårbarheter eller olämpligt beteende |
Bevisen kompletterar varandra. Förklara vad som finns och vilka kontroller användaren fortfarande behöver göra separat.
Reproducerbara byggen kräver tydliga indata och miljöer
Reproducible Builds definierar ett reproducerbart bygge som bitidentiska angivna artefakter från samma källkod, byggmiljö och instruktioner. Det är ett mer precist mål än ”det kompilerar på min dator”. Definition av reproducerbara byggen
Behåll verktygskedja, låsta beroenden, byggparametrar och sambandet med utgåvans artefakter. Om reproducerbarhet saknas, ange korrekt hur långt återbyggandet når i stället för att utelämna skillnader och godkänna resultatet.
Förklara också det offentliga arkivets omfattning. Det kan innehålla kärnkod eller främst byggverktyg, konfiguration och programpaket genererade uppströms. Användaren behöver veta vad som faktiskt går att granska och bygga om för att bedöma ursprungsbevis rimligt.
En praktisk ordning för nedladdningskontroll
- Bekräfta utgåvearkivet genom projektets officiella ingång, inte enbart sökannonser eller vidarebefordrade länkar.
- Läs versionsinformationen och kontrollera operativsystem, processorarkitektur och utgivningskanal.
- Jämför filen med rätt kontrollsumma; kontrollera även förväntad identitet och omfattning om signaturer eller ursprung finns.
- Kontrollera underhåll och kända begränsningar utan att tolka ”senaste” som produktionsklart.
- Spara version och filnamn vid motstridiga uppgifter och fråga projektets support.
Alla behöver inte bli byggingenjörer. Produkten kan ordna komplexa bevis på en tydlig sida: var filerna kommer från, vem de passar, hur de kontrolleras och var avvikelser tas upp.
Att långsiktigt underhålla informationskedjan är värdefullare än en engångssymbol ”verifierad”. Förklaringar ska gå att hitta när en äldre utgåva dras tillbaka, signeringen ändras eller en uppdatering misslyckas.
AlphaBizs offentliga arkivbeskrivning skiljer byggverktyg från programpaket genererade uppströms. Beskriv därför den faktiska granskningsomfattningen utan att blanda ihop offentligt arkiv, fullständig källkod och reproducerbara utgåvor. AlphaBizs projektbeskrivning
Utvecklare kan börja med en bevisinventering för en utgåva; användare med en nedladdning av ett vanligt program. Dela vilken verifieringsinformation du vill se på utgåvesidor i AlphaBiz Discussions.