Kial malfermfonta VPN estas malakceptata en aĉetado
Recenzanto, kiu kontraŭas malferman fonton, kutime protektas postulon, ne licencan guston. Demandu kiun, poste produktu la dokumenton, kiu respondas ĝin.
Malakceptoj, kiuj citas malferman fonton, malofte temas pri licencado. La recenzanto kutime protektas postulon: ke iu prizorgas la deplojitan eldonon, ke la instalita konstruaĵo estas identigebla, ke pritakso kovras tion, kio estas konektata, aŭ ke la konekto povas esti retirita. La sekva debato kutime respondas demandon, kiun neniu starigis.
Demandu, kiu postulo validas, antaŭ ol defendi licencon. La respondo decidas, kiun dokumenton vi bezonas.
La etikedo ne estas la postulo
Legebla fontkodo signifas, ke la publikigita efektivigo povas esti inspektita. Ĝi ne signifas, ke iu inspektis ĝin, ke la konstruaĵo sur la pordego kongruas kun la publikigita, aŭ ke prizorganto ŝuldas riparon al via deplojo. Ĉiu el tiuj estas aparta aserto kun aparta posedanto, kaj recenzanto, kiu bezonas unu el ili, ne estos kontentigita per la aliaj. Laŭte nomi la aserton kutime sufiĉas por ŝanĝi la konversacion.
La mala eraro estas same ofta. Komerca licenco ne pruvas, ke subteno kovras la funkcion, kiun vi fidas, ke pritakso ekzamenis la komponanton, kiun vi deplojas, aŭ ke la vendanto liveros korekton ene de via bontenada fenestro. Licencado priskribas disdonajn kondiĉojn, dum aĉetaj decidoj temas pri fido. En ambaŭ kazoj la licenco estas la malplej informa parto de la respondo.
Tenu la klienton kaj la servon aparte. Revizio de labortabla kliento diras nenion pri la pordega agordo de la partnero, ĝia identeca provizanto aŭ la maniero, kiel ĝiaj operatoroj traktas kontforigon. Kiujn ajn pruvojn vi kolektas, ili devas kongrui kun la limo, kiun oni petas la partneron fidi.
Turnu la zorgon en dokumenton
Petu la aprobanton esprimi la postulon en unu frazo, poste nomu la dokumenton, kiu kontentigus ĝin. Ĝuste la malklara trankviligo igas tiujn konversaciojn debato pri ideologio.
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework utilas ĉi tie pro unu mallarĝa kialo: ĝi kadras aĉetajn konversaciojn ĉirkaŭ komuna vortprovizo de praktikoj kaj provizanta komunikado. Tio subtenas peti difinitajn pruvojn anstataŭ diskuti pri etikedo, kaj ĝi ne estas atestilo, kiun iu ajn konkreta VPN trapasas.
Rimarku, kion faras la meza kolumno. Ĉiu vico petas dokumenton, kiu aŭ ekzistas aŭ ne, kio transformas opinion en liveraĵon, kiun iu povas produkti aŭ rifuzi.
Apartigu la klienton de la servo
Subtena kontrakto por klienta aplikaĵo ne estas devontigo pri la servilo, kiun via trafiko atingas. Antaŭ ol prezenti pruvojn, marku, kiujn partojn de la vojo funkciigas la partnero kaj kiujn vi funkciigas nome de ĝi. Miksi la du produktas pakaĵon da dokumentoj, kiu aspektas detala kaj respondas nenion.
Se la deplojo estas via, la partnero eble nur bezonas fidi identecon kaj alirregulon, kio estas multe pli malgranda peto ol fidi vian tutan softvaran provizĉenon. Se la deplojo estas ĝia, la kliento, kiun vi preferas, eble estas nerelevanta kaj la pordega agordo fariĝas la temo. Klarigi, en kiu kazo vi estas antaŭ la dua renkontiĝo, ŝparas unu revizian ciklon.
Poste kontrolu la operaciajn demandojn, je kiuj revizioj efektive malsukcesas: kiu forigas konton, kiel rapide, kaj kiaj pruvoj ekzistas poste. Bela dokumentita pritakso sen foriga proceduro ankoraŭ estas malferma konstato.
Finu per decido, ne per debato
Finu la interŝanĝon per skribita rezulto: la akceptita versio, la kontroloj ligitaj al ĝi, la nomitaj operatoroj, la pruvoj ankoraŭ mankantaj kaj la dato, kiam ili estas atendataj. Ĉio nesolvita estu registrita kiel kondiĉo anstataŭ sorbita en ĝeneralan aproban deklaron.
Se la politiko nomas specifan aprobitan produkton, uzu la esceptan vojon anstataŭ konstrui paralelan aranĝon, kiun neniu rajtigis. Konvinka teknika argumento ne donas permeson, kaj neoficiala deplojo estas konstato atendanta esti malkovrita.
Se postulo vere ne povas esti plenumita, transiru al la aprobita alternativo kaj diru kial. La celo de la ekzerco estas establi, kion la organizo povas fidi, kaj klara ne estas pli bona rezulto ol aprobo, kiun neniu povas defendi poste.