Avoimen lähdekoodin VPN-asiakasohjelma: mitä koodi todistaa ja mitä ei
Julkinen repositorio on todiste lähdekoodista, ei asentamastasi buildista tai sen takana olevista palvelimista. Sovita julkaisu ja laajenna sitten tarkastelua.
Lähdekoodi on julkaistu, lisenssi on puhdas, eikä yhteyttä silti voi varmentaa päästä päähän. Tämä aukko on tavallinen eikä ole skandaali. Koodin julkaiseminen tekee yhdestä komponentista sellaisen, jota voivat tarkastella ihmiset, joita ei kutsuttu, ja se on todellinen ja epätavallinen ominaisuus. Tästä ei seuraa, että asentamasi binääri on peräisin tuosta koodista, eikä että mitään palveluntarjoajan toisella puolella ajamaa olisi ylipäätään tarkasteltu.
Erota komponentti tuotteesta
Neljä asiaa voi kantaa avoimen lähdekoodin leimaa, ja harvoin kaikki ovat avoimia. Asiakassovellus on se, mitä ihmiset tarkoittavat. Sen alla oleva protokollatoteutus on eri artefakti, joskus kirjasto ja joskus puun sisäinen koodi. Palvelinohjelmisto on kolmas, ja palveluntarjoajan oma infrastruktuuri, asiakasportaali ja tukityökalut ovat neljäs. Kukin voi olla avoin tai suljettu itsenäisesti.
Niinpä väitteet kuten "sovelluksemme on avointa lähdekoodia" kuvaavat ensimmäistä kohtaa ja jättävät loput käsittelemättä, mikä ei ole epärehellisyyttä vaan pikemminkin kategorialipsahdus. Hyödyllinen kysymys on, mikä repositorio, millä tagilla, vastaa komponenttia, johon luotat.
Tämä ero selittää myös, miksi kaksi tuotetta, joilla on samanlaiset avoimet asiakkaat, voivat tarjota hyvin erilaisia takeita. Asiakas on osa, jonka voit tarkistaa; operaattorin käytös on osa, joka sinun on arvioitava muilla keinoilla.
Sovita asennettu build julkaistuun tagiin
Repositorio on kirjaus aikomuksesta; levylläsi oleva binääri on se, mikä suoritetaan. Tämän aukon sulkeminen on mekaaninen harjoitus, ja se alkaa selvittämällä tarkasti, mitä on asennettu, eikä sitä, mitä lataussivu mainosti.
| Component | What inspection can show | What it leaves untouched |
|---|---|---|
| Client source | How profiles, packets and optional telemetry are handled | Whether the shipped binary matches that source |
| Build output | Whether a declared build reproduces a matching artefact | Whether the source is correct or the toolchain is clean |
| Server software | What the implementation is capable of logging | What the operator actually configures and retains |
| Account and support systems | Almost nothing, unless they are separately published | Everything about how those systems treat your data |
Paketin metatiedot kertovat version ja alkuperän, mikä sulkee pois yksinkertaisen tapauksen vanhentuneesta tai korvatusta paketista. Ne eivät kerro, miten paketti käännettiin, ja juuri tähän kysymykseen toistettavat buildit ovat olemassa. Toistettavat buildit antavat riippumattomalle osapuolelle mahdollisuuden rakentaa uudelleen samasta lähteestä ja verrata tulosta tavu tavulta, jolloin poikkeama muuttuu todisteeksi epäilyn sijaan.
Jopa täydellinen vastaavuus todistaa vähemmän kuin ihmiset toivovat. Se osoittaa, että artefakti vastaa lähdettä ja build-reseptiä, ei että lähde on virheetön eikä että käytetty työkaluketju oli luotettava. Molemmat ovat tiedon arvoisia, mutta ne ovat eri väitteitä.
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgMistä oire yleensä alkaa
Valitus, joka tämän lukemisen käynnistää, on harvoin "koodi on suljettua". Yleensä se on konkreettinen havainto: asiakas, joka soittaa jonnekin odottamattomaan, versio, joka poikkeaa julkaisumuistiinpanoista, tai tukiprosessi, joka pyytää enemmän kuin tunnelin pitäisi tarvita. Jokainen näistä kohdista osoittaa eri komponenttiin.
Odottamaton verkkoliikenne asiakkaasta on asiakkaan lähdekoodikysymys, ja siihen voi vastata lukemalla koodipolun, joka avaa yhteyden. Versiopoikkeama on paketointikysymys. Henkilöllisyysasiakirjoja pyytävä tukiprosessi on asiakastilin järjestelmän kysymys, eikä mikään asiakkaan auditointi ratkaise sitä.
Komponentin nimeäminen muuttaa epämääräisen epäluulon konkreettiseksi tarkistukseksi. Konkreettiseen tarkistukseen voi vastata, siitä voi väitellä tai sen voi sulkea. Vaihtoehto on pysyvä epäily ilman seuraavaa askelta.
Mihin tarkastelu ei yllä, ja mitä sen sijaan tehdä
Säilytys palveluntarjoajan palvelimilla on asiakkaan ulottumattomissa. Samoin laskutusportaalin, petosten tarkistuspalvelun tarjoajan tai liitteitä säilyttävän tukipisteen käytös. Asiakkaan tarkastelu, joka venytetään muotoon "auditoimme palvelun", esittää väitteen, jota todisteet eivät tue.
Lue, mitä operaattori julkaisee säilytyksestä ja pyynnöistä, merkitse päivämäärä ja käsittele sitä asianosaisen lausuntona, älä mittauksena. Se on heikompi todisteen muoto, ja eron selkeä ilmaiseminen on hyödyllisempää kuin sen korottaminen uudelleenkerronnassa.
Käytä sitten sitä, mitä sinulla on, yhtenä syötteenä monien joukossa: asennetun julkaisun identiteetti, ylläpidetäänkö ohjelmistoa, miten asiakas on konfiguroitu ja mitä operaattori sanoo omista järjestelmistään. Avoin koodi vahvistaa tätä arviota yhdessä kohdassa. Se ei korvaa muuta.
Auditointiväitteen tulisi aina nimetä komponenttinsa ja versionsa. Jos raportti ei pysty sanomaan, mitä repositoriota ja mitä buildia se tutki, se kuvaa aikomusta eikä tuotetta.