Polecam cały artykuł Is that really the source code for this software? a dla niecierpliwych lub niespikających krótkie streszczenie. Wiele wolnego oprogramowania przychodzi w postaci binarnej. Dołączony jest do niej kod źródłowy w teorii odpowiadający dokładnie temu, z którego zostały zbudowane wersje binarne. Zagadnienie jest ważne zarówno z punktu widzenia wolności oprogramowania, jak i bezpieczeństwa.
Autor ww. artykułu postanowił sprawdzić, jak to wygląda w praktyce dla popularnych dystrybucji Linuksa (Debian, Fedora, OpenSUSE). Na przykładzie tak prostego oprogramowania jak tar. Wykorzystał do tego celu minimalne instalacje systemu, korzystał ze źródeł dostarczonych w dystrybucjach i metod budowania zalecanych przez dystrybucje.
Wyniki są dość zaskakujące: ani razu nie udało mu się uzyskać dokładnej (bit w bit) kopii tego prostego przecież pakietu wykorzystując kod źródłowy.
W przypadku Debiana różnice były minimalne (data i id buildu w plikach wykonywalnych), w przypadku OpenSUSE było gorzej. Powstałe pliki binarne były 5 razy większe od oryginału. Po wykonaniu strip na wersjach binarnych sytuacja wyglądała już podobnie jak w przypadku Debiana. Najgorzej wypadła Fedora – nie tylko różnic było najwięcej, ale autorowi artykułu nie udało się ustalić przyczyn wszystkich rozbieżności . Jak pisze „niełatwo stwierdzić, czy samodzielny build ze źródeł będzie funkcjonował identycznie, jak opublikowana wersja binarna z dystrybucji”.
W przypadku skomplikowanych pakietów i projektów luźniej podchodzących do kwestii wolności oprogramowania, niż dystrybucje Linuksowe (np. firmware routerów z wykorzystaniem wolnego oprogramowania – często zamieszczają kernel, ale zwykle jest to wersja waniliowa wzięta na żywca z kernel.org…) różnice będą jeszcze większe. Gdyby ktoś znalazł komentarz RMS do sprawy, proszę o linka – bardzo jestem ciekaw, co ma do powiedzenia w tej sprawie.
UPDATE: Problem czy to naprawdę kod źródłowy danej binarki został dostrzeżony i doceniony, idea reproducible builds stała się popularna.
Co do RMS’a to można do niego napisać 🙂 Jest bardzo responsywny w komunikacji email’owej
Wiem, że jest responsywny, ale trochę mi głupio. Jakby N osób pisało do niego w każdej „ważnej sprawie” to pewnie by zwariował. 😉 Dam trochę czasu, może sam z siebie skomentuje, a jeśli nie, to pewnie napiszę jakoś razem z drugą „ważną sprawą” ( rozie.blox.pl/2012/11/Statystyki-bloga-zmiana-licencji.html czyli ND w licencjach jego artykułów ). Chociaż tu znam uzasadnienie.
Kurcze, ktoś robił te testy kompletnie bez zrozumienia, a potem się dziwi, że wyniki są różne, nadto „streszczenie” jest chyba nazbyt „streszczające”. Otóż autor (pierwotny, czyli przywołanego tekstu) nie zrobił absolutnie nic, co umożliwiłoby stwierdzenie „badanego faktu”. Jedyne co robił, to budował pakiety deb czy rpm z dostarczonych przez dystrybucję źródeł i porównywał wielkość powstałego pakietu z dostarczanym pakietem w dystrybucji. Jak sam potem odkrywa m.in. pakiety różniły się bowiem np. zapisywana była inna data ich zbudowania.
Przeprowadzone testy absolutnie niczego nie dowodzą. Przede wszystkim należałoby porównać w istocie program, a nie paczkę, która służy do jego instalacji w systemie. Nie paczkę tarXXX.deb, a program tar lądujący w /bin/ i inne pliki dostarczane przez tarXXX.deb (czy rpm). W dodatku winien to zrobić jakimś narzędziem, które oferuje porównanie plików bit po bicie. Wówczas dopiero, gdyby wystąpiły różnice i różnice te zostałyby ujawnione można byłoby się zastanawiać nad tym, czy wszystko jest w porządku z „ideą” kodu źródłowego. Obecne „badanie” jest jak odkrycie jakiegoś matematycznego paradoksu.
@pavabaranov Przeczytaj dokładnie oryginał. Różniły się także pliki wykonywalne: The files bin/tar, /usr/sbin/rmt-tar and /usr/share/man/man1/tar.1.gz differ. Podobnie opisywane polecenie strip działa na pliku wykonywalnym, nie na paczce. Więc zarzut, że porównywał tylko paczki, jest bezpodstawny.
Oraz: nie tylko robił to bit po bicie (to zwykły diff potrafi), ale analizował różnice. Przy czym tak naprawdę dla przeciętnego użytkownika zgodność powinna być bit do bitu. Inaczej nie ma prostej możliwości weryfikacji, czy dostarczone źródła są faktycznie dla danego pliku wykonywalnego. Nawet zmiana „tylko” daty w pliku powoduje niezgodność binarną i co za tym idzie sumy kontrolnej. Trudno oczekiwać, że ktoś będzie sprawdzał bajt po bajcie każdy instalowany program. Przy każdej jego aktualizacji.
Oczywiście można to zrobić tak, jak jest domyślnie w *BSD czy Gentoo i kompilować wszystko na miejscu. Także w Debianie widziałem możliwość używania zarządzania pakietami z wykorzystaniem instalacji ze źródeł. Chyba właśnie apt-build. Ale też nie w tym rzecz – sedno jest w ostatnim akapicie.
Ciekawy temat, ostatnio sie zastanawialem czy ktos w ogole weryfikuje co nam dostarczaja autorzy dystrybucji, szczegolnie ci komercyjni. Dobrze, ze jest Debian.