Oletetaan, että työpöytäsovellus löytyy julkaisusivulta ja peilipalvelimelta. Tiedostonimet ja versionumerot täsmäävät, mutta käyttäjän on silti tiedettävä, ovatko tiedostot samoja, kuka ne julkaisi, ovatko ne odotetusta koodista ja koontiprosessista ja sopivatko ne laitteelle.
Kysymykset tarvitsevat eri todisteet. Kaiken kutsuminen ”turvallisuussertifioinniksi” luo odotuksia, joita tarkistukset eivät täytä, ja voi peittää julkaisuprosessin aukkoja kehittäjiltä.
Tarkistussummat kertovat tiedostojen vastaavuudesta
Ladatun tiedoston tiivisteen vertaaminen odotettuun arvoon osoittaa sisällön vastaavuuden. Arvon on tultava luotetusta kanavasta. Jos tiedosto ja summa ovat samalta vahvistamattomalta sivulta, niiden vastaavuus ei todista julkaisijan identiteettiä.
Eri tiivisteet tarkoittavat eri tiedostoja, eivät yksin pahantahtoisuutta. Eri koonti, uudelleenpakkaus tai väärä lataus voi selittää eron. Älä enää käsittele tiedostoa tarkistettuna julkaisuna, vaan varmista lähde, kohdealusta ja vastaava tarkistussumma uudelleen.
Julkaisijan tulisi ylläpitää selkeitä nimiä, versiotietoja ja summaluetteloita yhdessä. Käyttäjän ei pitäisi kopioida vanhan artikkelin tiivistettä ja verrata sitä toisen alustan tai koonnin asennustiedostoon.
Allekirjoitus vaatii odotetun identiteetin tarkistuksen
Digitaalinen allekirjoitus sitoo allekirjoittajan tietoihin, mutta tarkistuksen on ratkaistava myös identiteetin vastaavuus odotettuun. Sigstoren dokumentaatio vaatii allekirjoituksen ohella asiaankuuluvien identiteetti- ja myöntäjäehtojen tarkistamista. Sigstoren tarkistusohje
”Kelvollisen allekirjoituksen” kohdalla on selvitettävä myös julkaisija tai työnkulku. Kehittäjien tulee ilmoittaa virallisten julkaisujen sallitut allekirjoittajat. Matemaattisesti kelvollinen allekirjoitus ei automaattisesti tee tiedostosta virallista.
Varmenteen tai allekirjoitustavan vaihdossa tarvitaan tarkistettava selitys. Käyttäjän pyytäminen luottamaan heti tuntemattomaan varmenteeseen ei ole kokonainen päivitysprosessi.
Koontialkuperä yhdistää paketin tuotantoprosessiin
GitHubin artefaktitodistukset voivat tallentaa koontialkuperän ja auttaa tarkistamaan yhteyden koodivarastoon ja työnkulkuun. Ne kertovat tiedoston synnystä, mutta varsinainen artefakti ja odotettu identiteetti on edelleen tarkistettava. GitHubin artefaktitodistukset
SLSA:n koontitasot erottavat alkuperätietojen olemassaolon, isännöidyn alustan allekirjoittamat tiedot ja tiukemman koontialustan suojauksen. Ilmoita tason yhteydessä kattavuus ja perusteet; numero ei arvioi kaikkia ohjelmistoriskejä. SLSA:n koontitasot
| Todiste | Mitä se ensisijaisesti selvittää | Mitä se ei yksin todista |
|---|---|---|
| Tarkistussumma | Saatiinko odotettu tiedostosisältö | Julkaisijan identiteettiä tai turvallista toimintaa |
| Digitaalinen allekirjoitus | Kuka allekirjoitti mitkä tiedot | Allekirjoittajan vastaavuutta luottamusvaatimuksiisi |
| Koontialkuperä | Mikä prosessi tuotti artefaktin | Koodin ja riippuvuuksien täydellistä ongelmattomuutta |
| Toistettava koonti | Voiko saman artefaktin luoda määrätyissä oloissa | Haavoittuvuuksien tai sopimattoman toiminnan puuttumista |
Todisteet täydentävät toisiaan. Kerro, mitä on tarjolla ja mitkä tarkistukset on vielä tehtävä itsenäisesti.
Toistettavat koonnit tarvitsevat täsmälliset syötteet ja ympäristöt
Reproducible Builds määrittelee toistettavan koonnin tuottavan bittitasolla samat määritellyt artefaktit samasta lähdekoodista, ympäristöstä ja ohjeista. Tavoite on täsmällisempi kuin ”kääntyy koneellani”. Toistettavan koonnin määritelmä
Säilytä työkaluketju, lukitut riippuvuudet, koontiparametrit ja niiden yhteys julkaisuartefakteihin. Jos toistettavuutta ei saavuteta, kuvaa tarkasti, mihin uudelleenkoonnissa päästään, älä jätä eroja pois ja julista tulosta hyväksytyksi.
Selitä myös julkisen koodivaraston laajuus. Siellä voi olla ydinkoodi tai lähinnä koontityökaluja, asetuksia ja ylempänä tuotettuja sovelluspaketteja. Käyttäjän on tiedettävä, mitä hän voi todella tarkastaa ja koota uudelleen arvioidakseen alkuperätodisteita järkevästi.
Käytännöllinen latauksen tarkistusjärjestys
- Varmista julkaisuvarasto projektin virallisen aloituspisteen kautta, älä vain hakumainoksista tai välitetyistä linkeistä.
- Lue julkaisutiedot ja tarkista käyttöjärjestelmä, suoritinarkkitehtuuri ja julkaisukanava.
- Vertaa tiedostoa oikeaan tarkistussummaan; tarkista myös odotettu identiteetti ja kattavuus, jos allekirjoitus tai alkuperätiedot ovat saatavilla.
- Tarkista ylläpitotila ja tunnetut rajoitukset tulkitsematta ”uusinta” tuotantovalmiiksi.
- Ristiriidoissa säilytä versio ja tiedostonimi ja kysy projektin tukikanavista.
Kaikkien ei tarvitse ryhtyä koonti-insinööreiksi. Tuote voi järjestää monimutkaiset todisteet selkeäksi sivuksi: tiedostojen alkuperä, kohdekäyttäjät, tarkistustavat ja yhteyspaikka poikkeamille.
Tietoketjun pitkäaikainen ylläpito on arvokkaampaa kuin kertaluonteinen ”tarkistettu”-merkki. Selitysten on löydyttävä vanhan version peruutuksessa, allekirjoitustavan vaihdossa ja päivitysvirheessäkin.
AlphaBizin julkisen varaston kuvaus erottaa koontityökalut ylempänä tuotetuista sovelluspaketeista. Kuvaa siksi todellinen tarkastusala sekoittamatta julkista varastoa, täydellistä lähdekoodia ja toistettavia julkaisuja. AlphaBizin projektikuvaus
Kehittäjä voi aloittaa julkaisun todisteiden luettelosta, käyttäjä yhden usein käyttämänsä sovelluksen latauksesta. Kerro AlphaBiz Discussionsissa, mitä tarkistustietoja toivot julkaisusivuille.