Osoby zainteresowane śledzeniem rozwoju Bitcoin Core, mogą go nawet traktować jako przewodnik zawierający szereg odnośników do dalszej wiedzy.
-----------------------------------------------
Kto kontroluje Bitcoin Core?
Pytanie o to kto kontroluje możliwość merge'owania1 zmian kodu w repozytorium GitHub Bitcoin Core pojawia się regularnie. Było ono wymieniane jako "centralny punkt kontroli" protokołu Bitcoina przez różne strony na przestrzeni lat, ale ja uważam, że samo to pytanie jest zasłoną dymną, ponieważ jest postawione z perspektywy autorytarnej - a ten model nie dotyczy Bitcoina. Z pewnością dla laika nie jest oczywiste, dlaczego tak jest, dlatego celem tego artykułu jest wyjaśnienie, w jaki sposób funkcjonuje Bitcoin Core i, na wyższym poziomie, jak ewoluuje sam protokół Bitcoin.
Historia Bitcoin Core
Bitcoin core w procesie developmentu protokołu Bitcoina jest raczej punktem skupienia2 niż punktem dowodzenia i kontroli. Jeśli z jakiegoś powodu przestałby istnieć, pojawiłby się nowy punkt skupienia - platforma komunikacji technicznej, na której jest oparty (aktualnie repozytorium GitHub) jest raczej kwestią umowy niż jednej z definicji / integralności projektu. W rzeczywistości, widzieliśmy już zmienianie platform developmentu a nawet nazw przez bitcoinowy punkt skupienia.
- Na początku 2009 kod źródłowy projektu Bitcoin był po prostu plikiem .rar hostowanym na SourceForge'u. Wcześni developerzy właściwie wymieniali patche kodu z Satoshim drogą mailową.
- 30 października 2009, Sirius (Martti Malmi) stworzył repozytorium SVN dla projektu Bitcoin na SourceForge'u.
- W 2011 projekt Bitcoin został zmigrowany z SourceForge'a do repozytorium GitHub.
- W 2014 nazwa projektu Bitcoin została zmieniona na Bitcoin Core.
Choć na poziomie organizacyjnym istnieje kilka kont "opiekunów"3 GitHub mających możliwość merge'u kodu do gałęzi master, pełnią one raczej funkcję porządkową niż działają z pozycji władzy. Gdyby każdy mógł wykonać merge do mastera szybko doszłoby do scenariusza "zbyt wielu kucharzy w jednej kuchni". Bitcoin Core kieruje się zasadami najmniejszych uprawnień, tak, że dowolna władza oddana jednostkom może być z łatwością odebrana jeśli zostanie nadużyta.
Core jest transparentny względem listy mającej znaczenie: kluczy PGP, którymi można podpisać commit merge'ujący.
Lekcja do nauczenia to: nie ufać GitHub! Nawet Bitcoin Core nie zna całej listy ludzi mogących modyfikować repozytorium, ze względu na to, że dotyczy to prawdopodobnie kilkudziesięciu pracowników GitHub.
Z kontradyktoryjnego punktu widzenia, GitHubowi nie można ufać. Dowolna liczba pracowników GitHub mogłaby użyć swoich uprawnień administratorskich by wprowadzić kod do repozytorium bez zgody opiekunów. Jednak jest mało prawdopodobne by GitHubowy atakujący był również w stanie przejąć klucz PGP opiekuna Bitcoin Core.
Zamiast opierać integralność kodu na kontach GitHub, BitcoinCore posiada system ciągłej integracji wykonujący weryfikacje zaufanych kluczy PGP wymaganych do podpisania każdego commita merge'ującego.
Choć te klucze są przypisane do znanych tożsamości, nadal nie jest bezpiecznie zakładać, że zawsze tak będzie - klucz mógłby zostać przejęty i nie wiedzielibyśmy o tym dopóki oryginalny właściciel klucza nie powiadomiłby pozostałych opiekunów. W związku z tym klucze commitów również nie zapewniają perfekcyjnego bezpieczeństwa, po prostu utrudniają atakującemu wprowadzenie uznaniowego kodu.
Klucze do królestwa
W momencie pisania tych słów, poniższe są zaufanymi odciskami PGP:
Te klucze są zarejestrowane na:71A3B16735405025D447E8F274810B012346C9A6
133EAC179436F14A5CF1B794860FEB804E669320
32EE5C4C3FA15CCADB46ABE529D4BCB6416F53EC
B8B3F1C0E58C15DB6A81D30C3648A882F4316B9B
CA03882CB1FC067B5D3ACFE4D300116E1C875A3D
Czy to oznacza, że ufamy tym pięciu osobom? Niezupełnie. Klucze nie są potwierdzeniem tożsamości - klucze mogłyby potencjalnie wpaść w ręce innych ludzi. Jakie gwarancje faktycznie otrzymujemy uruchamiając pythonowy skrypt verify-commits?Wladimir J. van der Laan <laanwj@protonmail.com>
Pieter Wuille <pieter.wuille@gmail.com>
Jonas Schnelli <dev@jonasschnelli.ch>
Marco Falke <marco.falke@tum.de>
Samuel Dobson <dobsonsa68@gmail.com>
python3 contrib/verify-commits/verify-commits.py Using verify-commits data from bitcoin/contrib/verify-commits All Tree-SHA512s matched up to 309bf16257b2395ce502017be627186b749ee749 There is a valid path from “HEAD” to 82bcf405f6db1d55b684a1f63a4aabad376cdad7 where all commits are signed!
Skrypt verify-commits jest weryfikatorem integralności, który każdy developer może wykonać na swojej maszynie. Po uruchomieniu, sprawdza sygnatury PGP każdego commita merge'ującego od commita 82bcf405… z grudnia 2015 - ponad 3400 merge'ów w momencie pisania tego artykułu.
Gdy skrypt wykona się z powodzeniem, mówi to nam, że każda linia kodu zmodyfikowana od tamtego punktu [od commita o ID 82bcf405f6db1d55b684a1f63a4aabad376cdad7 - przyp. akos] przeszła przez proces developmentu Bitcoin Core i została podpisana przez kogoś kluczem opiekuna. Choć nie stanowi to niezachwianej gwarancji, że nikt nie wstrzyknął4 złośliwego kodu (opiekun mógł się zbuntować lub jego klucz mógł zostać skradziony), to ogromnie ogranicza płaszczyznę ataku. Kim są opiekunowie i jak otrzymali swoją rolę? Zajmiemy się tym nieco później.
edit: zastąpienie '.' przez '?' w przedostatnim zdaniu
edit2: poprawka odnośników do maili opiekunów