Chcel som konečne začať podpisovať svoje commity, hlavne preto, že okrem iných dôvodov to zvyšuje celkovú dôveryhodnosť mojej práce. S rozhodnutím GitHubu zobrazovať žlté varovanie Unverified pri zozname commitov sa trend smerom k podpisovaniu takmer určite bude len ďalej rozvíjať.

Táto situácia sa môže a možno aj vyvinie do bodu, kde budú všeobecne prijímané len podpísané commity, kdekoľvek pracuje s repozitárom viac ľudí, a to je dobrá vec. Riadne podpísaná práca výrazne znižuje šancu, že sa do nej vkradne škodlivý kód, ak nič iné.

Problém leží v slove riadne. Existuje jasný spôsob, ako riadne podpisovať commity. Nie je však jasný spôsob, keď urobíme ďalší krok: Ako zaobchádzať so podpisovacími kľúčmi riadne?

Zaobchádzanie s GnuPG kľúčmi #

Je k dispozícii obrovské množstvo materiálu a nedávno som si prečítal dosť veľa z toho. Všetko ma priviedlo k dvom záverom: Celá PGP scéna (vrátane OpenPGP a GnuPG) je neporiadok, bez ktorého sa pravdepodobne nemôžeme zaobísť.

Spočiatku som si myslel, že som neadaptoval gpg pracovný tok skôr, pretože jednoducho nebol naliehavý dôvod. Ale existujú vlastne dva scenáre, prečo sa nenaučiť používať nástroj alebo pracovný tok, ktorý inak používate pravidelne a považujú ho za dôležitý aj iní ľudia robiaci to isté:

  1. Neučiť sa kvôli žiadnemu naliehavému dôvodu, ako je uvedené
  2. Neučiť sa preto, že nástroj nevyžaduje učenie, pokiaľ nerobíte niečo špecifické

Ako príklad druhého scenára by som uviedol kategóriu webových bundlerov. Nástroje ako Webpack, Rollup, Parcel alebo niektorí noví hráči ako Snowpack, Vite alebo ESbuild.

Príliš veľa ľudí používa tieto nástroje bez toho, aby sa kedy naučili s nimi pracovať, keďže prichádzajú nakonfigurované niekým iným a na dané účely zvyčajne len fungujú. Tento argument možno aplikovať na veľa iných vecí, napríklad že používanie IDE bráni učeniu sa git príkazov, alebo dokonca jednoduchšia forma tvrdenia, že používanie GUI bráni učeniu sa akýchkoľvek základných príkazov.

GitHub automaticky podpisuje commity #

Okamih, keď ma to nechalo trochu zmäteného, bol, keď som zistil, že pri pridávaní commitov cez webové rozhranie GitHubu sa automaticky zobrazujú ako Verified. Prekvapilo ma to, pretože som vedel, že som sa nedotýkal žiadnych PGP polí v rozhraní GitHubu, a nevedel som, ako mohli byť podpísané. Ako poznámka na okraj, primárne používam vlastný Gitea server a som s ním celkom spokojný, preto nesledujem všetky zmeny, ktoré GitHub zavádza.

Nie som si úplne istý, ako GitHub robí automatické podpisovanie commitov, keďže som o tom mechanizme zatiaľ nič nečítal. Pravdepodobne je to založené na predpoklade, že som prihlásený bezpečne, môj e-mail je overený a podobné informácie. Táto funkcia sa prejavuje v zvláštnom svetle, keď napríklad pracujete na spoločnom Pull Request a pushujete samostatné commity cez oba kanály: webové rozhranie GitHub a git push do vetvy môjho forku, sledovaného daným Pull Requestom.

Pri pohľade na takto vytvorené commity to vytvára chaos. Commity pochádzajú od tej istej osoby, ale niektoré sú overené a niektoré nie. Verím, že takýto obraz, kde sa slová Verified a Unverified striedajú divoko, znižuje dôveru v kód, ktorý pushujem. Toto sa môže stať aj keď niekto robí všetko podpisovanie úplne manuálne a niekedy zabudne podpísať, ale v tomto scenári je to voľba používateľa adaptovať pracovný tok, kde si musia pamätať určité veci (nezabudnúť podpísať každý commit manuálne). V predchádzajúcom prípade GitHub namiesto toho robí určité rozhodnutia.

Mali by byť všetky commity podpísané? #

Uvažujme hypotetický scenár, kde GitHub vynúti politiku, že každý jednotlivý commit prijatý do jeho ekosystému musí byť podpísaný a neexistuje iná možnosť.

Odložme bokom všetky politické, ekonomické a spoločenské dôsledky, ktoré sú všetky vo svojej podstate dôležité, a sústreďme sa čisto na niektoré technické dôsledky. Zaistila by taká silná politika, že všetky commity by boli skutočne podpísané? Odpoveď je áno. Žiadny podpis, žiadny push. Problém vyriešený.

Ale znamenalo by to, že všetky commity sú podpísané riadne? Uvažujme scenár, kde nejaký používateľ omylom pushne master kľúč použitý na podpisovanie commitov do toho istého repozitára? A čo ak to nejaký používateľ urobí zámerné, ako akt vzdoru voči vynútenej politike?

Znamenalo by to, že všetky commity sú podpísané? Áno, táto požiadavka by stále platila. Ale znamenalo by to, že všetky commity sú podpísané riadne? Určite nie, ale ešte musím pochopiť všetky alebo aspoň hlavné dôsledky takého scenára.

Záver #

Aj po všetkom tomto výskume a rokoch hovorenia si “musím čoskoro začať používať GnuPG”, najmä na podpisovanie commitov, nehovoriac o šifrovaných/ podpísaných e-mailoch, stále som nezačal.

Dôvodom je, že vyzerá to tak, že existuje príliš veľa spôsobov, ako to urobiť zle. Vyzerá to tiež tak, že z dlhodobého hľadiska sa oplatí urobiť to správne, čo si zjavne vyžaduje nejaký prieskum a veľmi pravdepodobne aj investície do dedikovaného hardvéru. Buď sa to všetko stane plynulejším, alebo sa donutím sa to konečne naučiť a nastaviť. Všetko je nemožné, kým to neurobíte.

Toto je 38. príspevok z #100daystooffload.

Aktualizácia #

Len niekoľko dní po publikovaní tohto príspevku som zistil, že existuje len jeden podpis, ktorý je tiež zverejnený na keyserveri, informácie možno vyhľadať takto:

gpg --search-keys 4AEE18F83AFDEB23

gpg: data source: https://hkps.pool.sks-keyservers.net:443
(1)	GitHub (web-flow commit signing) <[email protected]>
	 2048 bit RSA key 4AEE18F83AFDEB23, created: 2017-08-16

Stále by som to chcel pochopiť hlbšie, dúfajme, že narazím na nejaký príspevok vysvetľujúci problematiku v stráviteľnejších kúskoch.

Odkazy #