Rzekoma publikacja kodu źródłowego aplikacji mObywatel

Wyobraźcie sobie, że polski rząd produkuje lokomotywy. Ustawa nakazuje publikację dokumentacji technicznej lokomotyw. Rząd publikuje wzorniki do tworzenia tabliczek instalowanych na panelu sterowania i ogłasza: opublikowaliśmy dokumentację! Tak właśnie wygląda dziś sprawa publikacji kodu źródłowego aplikacji mObywatel.

Wolę pisać o tematach technicznych, ale – niestety – dziś będzie o polityce. Minister Krzysztof Gawkowski i wiceminister Michał Gramatyka psują państwo. Nie mają odwagi powiedzieć, że ich zdaniem zadekretowana ustawą transparentność jest szkodliwa i z tego powodu ich rząd przeprowadzi nowelizację wycofującą obowiązek publikowania kodu źródłowego.

Zamiast tego minister z wiceministrem wolą robić z obywateli idiotów i publikują kilka procent plików składających się na mObywatela – tych o najmniejszym znaczeniu. Obywatele dobrze wiedzą, że są traktowani jak idioci. Jednocześnie wszyscy mają świadomość, że ministrów nie spotkają żadne nieprzyjemności – ani za fasadową i wybiórczą realizację przepisów prawa, ani za osłabianie w ten sposób praworządności.

---

Z ciężkim sercem siadam do pisania niniejszego tekstu, bo wcześniejsza koncepcja była nieco inna. Spodziewałem się cenzury ograniczonej do najbardziej newralgicznych modułów i zawczasu planowałem heheszki w rodzaju „władzuchna usunęła ze źródeł adresy serwerów i od razu jest bezpieczniej” albo „ponglish mObywatela czyli isPies 2.0”.

Wyszło jednak, jak wyszło, więc zamiast tego będzie długa i żmudna orka na ugorze. Znaczy tego, wysiłek edukacyjny. Uwaga edytorska – aplikacja mObywatel jest wydana w wersjach na Androida i iOS, uwagi i opinie odnoszą się do obu tych wersji naraz, w przykładach i opisach technicznych dominuje wersja dla Androida.

Zaczynajmy.

O co w ogóle chodzi?

Ustawa z 26 maja 2023 zobowiązała rząd do opublikowania kodu źródłowego aplikacji mobilnej mObywatel. Miało się to wydarzyć do połowy roku 2024, stanęło na grudniu 2025 (kalendarium poniżej). 29 grudnia 2025 Ministerstwo Cyfryzacji poinformowało, że kod źródłowy został udostępniony.

Co tak naprawdę udostępniono? Jedynie komponenty interfejsu użytkownika – przyciski, pola tekstowe, listy rozwijane itp. Na oko – kilka procent plików składających się na aplikację. To nawet nie są definicje ekranów mObywatela, a jedynie klocki, które są tam używane. Słowem – OPUBLIKOWANO WIELKIE NIC.

Nie jesteśmy w stanie sprawdzić, czy komunikacja z serwerami jest realizowana zgodnie z zasadami sztuki. Nie jesteśmy w stanie sprawdzić, czy celowe zaburzenia komunikacji z tymi serwerami nie będą skutkować niepożądanymi efektami ubocznymi. Nie sprawdzimy, czy mobilny dokument mObywatel (tzw. mDowód) jest chroniony w urządzeniu przy użyciu poprawnie dobranych i odpowiednio użytych procedur kryptograficznych ani czy wykluczono możliwość obejścia procedury logowania do aplikacji. Nie dowiemy się, czy dane z QR-kodów są w odpowiedni sposób walidowane.

Pozwolę sobie na cytat, Robert Frycz pisze na Twitterku:

[…] Najciekawsze jest jednak to, że przekaz jest sformułowany w sposób, który ma zniechęcić do zadawania pytań. Kto zapyta „gdzie reszta?”, ten najwyraźniej „nie rozumie procesu”. Kto wskazuje różnicę między UI a realnym kodem aplikacji – pewnie „sieje dezinformację”. Metoda stara, znana i niestety skuteczna: kontrola narracji zamiast faktów.

Nie trzeba być paranoikiem, by zauważyć, że to już nie transparentność, tylko jej symulacja. A symulacja prawdy zawsze była wygodnym narzędziem władzy – eleganckim, czystym, bez śladów, ale z bardzo konkretnym celem.

Podsumowując: to nie jest otwarcie kodu. To PR-owy teatrzyk, w którym obywatel ma klaskać, nie zaglądając za kulisy. A jeśli ktoś jednak zajrzy – cóż, wtedy spektakl nagle się kończy.

Dokładniejsze kalendarium

marzec 2023 – Nowa Nadzieja

Premier Mateusz Morawiecki przedstawia rządowy projekt ustawy o aplikacji mObywatel, który zostaje skierowany do pierwszego czytania i prac w komisjach.

Michał Gramatyka, poseł opozycyjnej partii Polska 2050, zgłasza poprawkę, zgodnie z którą rok po wejściu ustawy w życie Minister Cyfryzacji będzie zobowiązany do publikacji kodu źródłowego aplikacji mObywatel.

Poprawka zostaje przyjęta i trafia do ustawy z dnia 26 maja 2023 r. o aplikacji mObywatel. Poseł Gramatyka jest z siebie bardzo dumny.

Wynikiem 447:1 #Sejm zobowiązał rząd do publikacji kodu źródłowego @mObywatelGOV – kapitalna wiadomość dla wszystkich fanów #OpenData
Szacunek @jciesz i @Andruszkiewicz1 za zrozumienie potrzeby 💛@PL_2050 @CyfryzacjaKPRM pic.twitter.com/AVpJc7LVmf

— Michał Gramatyka 🇵🇱🇪🇺 #Polska2050 💛 (@McGramat) March 9, 2023

Publiczność zachowuje zdrowy sceptycyzm, pojawiają się proroctwa:

maj 2024 – Imperium Kontratakuje

Wiceminister cyfryzacji Michał Gramatyka, ogromny zwolennik publikacji kodu źródłowego mObywatela, orientuje się, że termin owej publikacji mija lada moment. Nie jest już członkiem opozycji, tylko rządu, więc znienacka „przemawiają do niego względy bezpieczeństwa” a on decyduje się „doprowadzić tę publikację na odpowiednie tory”.

Można się załamać 🤦‍♂️ @McGramat o udostępnieniu kodu źródłowego #mObywatel

cc: @jciesz pic.twitter.com/q0oyBtiEux

— Tomasz Janusz (@TomaszJanusz) May 8, 2024

Do ustawy z dnia 15 maja 2024 r. o zmianie ustawy o pomocy obywatelom Ukrainy trafia wrzutka następującej treści:

W poprawce nie jest już wskazana data publikacji kodu źródłowego. Publiczność nie jest zachwycona, tu Czasopismo Lege Artis: „ […] nie wiadomo nawet czy i kiedy się tego wszystkiego dowiemy: jak dotąd ustawa wyznaczała ścisły termin, tak po nowelizacji dzień udostępnienia kodu źródłowego oprogramowania zostanie ogłoszony w magicznym komunikacie, który może będzie kiedyś opublikowany w Monitorze Polskim — może kiedyś, bo jak widać tym razem termin promulgacji owego komunikatu nie został w żaden sposób zakreślony”

Zmiany wchodzą życie w lipcu 2024, przez kolejnych 16 miesięcy nie dzieje się nic.

grudzień 2025 – Powrót (zadowolonego) Jedi

Pod koniec listopada 2025 Minister Cyfryzacji wydał wreszcie rozporządzenie, ustalając datę publikacji kodu źródłowego mObywatela na 29 grudnia.

Ministerstwo coś tego dnia publikuje. Wiceminister Michał Gramatyka wyraża na LinkedIn satysfakcję:

Gdy jednak kilka godzin później zapytałem, czy jest dumny z publikacji kodu źródłowego mObywatela – entuzjazm zdążył przygasnąć. Może pan wiceminister dowiedział się, że owe „znaczne fragmenty kodu” były nieznaczne tak pod względem objętości jak i ważności.

Minister cyfryzacji Krzysztof Gawkowski nie odniósł się w swoich social mediach do faktu publikacji źródeł mObywatela. Wprawdzie 30 grudnia napisał na Twitterze, że „końcówka roku przynosi ogromny sukces polskiej cyfryzacji”, ale – niestety – miał na myśli inny ogromny sukces.

Jaka dupokrytka została tu zastosowana?

Pierwotna wersja ustawy przegłosowana w maju 2023 roku mówiła wprost – rok od wejścia ustawy w życie należy udostępnić kod źródłowy. Z tą myślą żyliśmy prawie 12 miesięcy.

Potem pojawiła się nowelizacja odsuwająca ten termin i dodająca wymóg pozyskania opinii trzech CSIRT-ów czyli zespołów reagowania na incydenty bezpieczeństwa polskiego kawałka cyberprzestrzeni – CSIRT NASK, GOV i MON.

Tym samym więc opozycjonista Michał Gramatyka przeforsował otworzenie źródeł a wiceminister Michał Gramatyka zyskał dupokrytkę pozwalającą na usunięcie zasadniczo dowolnej części źródeł. W typowej apce bezpośredni związek z „bezpieczeństwem aplikacji” może mieć z 5% kodu, np. operacje kryptograficzne na mDowodzie (poprawniej: dokumencie mObywatel). Zamiast tego z udostępnianej paczki usunięto 95% kodu, co zredukowało rzekomą otwartość do zawstydzającego żartu.

Warto przy tym nadmienić, że ustawowy „zakres niezagrażania bezpieczeństwu aplikacji” nie jest wprost powiązany z opiniami CSIRT-ów – minister ma je uzyskać, ale nie jest związany ich treścią.

Co znalazło się w tych opiniach? Z tekstu „Analizujemy opinię CSIRT MON w sprawie publikacji kodu mObywatela” opublikowanego w serwisie Kontrabanda.net wiemy, że tylko jedna z tych opinii jest jawna. Wrócimy do niej w dalszej części artykułu.

Dygresja: w Biuletynie Informacji Publicznej czytamy: „[minister] udostępnił część kodu źródłowego aplikacji, prezentującą filozofię oraz strukturę kodowania”. Pewien Kierownik Projektu w Centralnym Ośrodku Informatyki chyba lekko się podłożył. Jego zadaniem była publikacja „kodu w zakresie niezagrażającym bezpieczeństwu”, a nie prezentowanie próbek „filozofii i struktury”, cokolwiek miałoby to znaczyć.

Po co nam źródła mObywatela?

Załóżmy na potrzeby tego akapitu ameliniowe czapeczki i włączmy myślenie. Co się stanie, gdy zainstalujesz mObywatela? Rząd będzie w stanie śledzić, gdzie jesteś! Rząd podsłucha, co mówisz, i sfilmuje, co robisz!! Rząd przeczyta twojego Facebooka, twojego Whatsappa i podsłucha PIN do twojego banku!!! A na dodatek przejmie twoje odciski palców!!!!

Uspokajam – spiskowe teorie rzadko sprawdzają się w rzeczywistości. Jednak wiedza, które z powyższych scenariuszy są wykluczone i dlaczego, jest wiedzą ekspercką. Dopiero człowiek znający architekturę systemów mobilnych będzie w stanie objaśnić, jak działają mechanizmy gwarantujące poufność i bezpieczeństwo danych. Tylko specjalista od analizy wstecznej będzie w stanie stwierdzić, czy aplikacja realizuje jakieś ukryte cele – a zwykły człowiek musi mu wierzyć, bo przecież nie zweryfikuje tego samodzielnie.

Dlaczego więc dostępność kodu źródłowego mObywatela miałaby komukolwiek pomóc?

Jak w dowcipie – kontrola najwyższą formą zaufania. Gdy wielu niezależnych specjalistów w różnych momentach sprawdzi, że zachowanie aplikacji mObywatel oraz jej skompilowany bajtkod odpowiadają opublikowanym źródłom, zaczną toczyć się dwa długoterminowe procesy.

Po pierwsze – eksperci podzielą się opiniami, dzięki którym osoby postronne będą mogły podjąć decyzję, czy aplikacja mObywatel jest godna zaufania i czy chcą korzystać z udogodnień przez nią oferowanych. Po drugie – możliwość systematycznej kontroli zmian w kodzie źródłowym sprawi, że trudniej będzie w sposób niezauważony dodać jakąkolwiek niepożądaną funkcję. Budowa zaufania do usług elektronicznych trwa o wiele dłużej, niż jedną kadencję parlamentu.

Nie bez znaczenia jest także wartość edukacyjna. Wiele osób nadal uważa, że usługi elektroniczne są tym bezpieczniejsze, im mniej wiadomo o ich implementacji. Tyle tylko, że aplikację mobilną można badać do woli.

Czy bez dostępu do kodu źródłowego da się znaleźć w aplikacji błędy?

Nie będzie chyba lepszej odpowiedzi na to pytanie, niż przypomnienie poważnego błędu odnalezionego właśnie w aplikacji mObywatel. Na konferencji CONFidence 2024 swoje odkrycie zaprezentował Szymon Chadam, w prelekcji pt. „Elektroniczny, ale czy bezpieczny? Hackowanie nowego mObywatela 2.0”. Cała prezka jest warta obejrzenia, mięso zaczyna się w 20 minucie.

Pierwszą z usterek była możliwość wstrzyknięcia dowolnych treści do QR-kodu inicjującego potwierdzenie tożsamości – to mogło posłużyć do wyłudzenia cudzych danych. Druga usterka – dużo grubsza – pozwalała na wstrzykiwanie przejętych w ten sposób danych do własnej komunikacji z serwerami, co oznaczało de facto przejęcie cudzej tożsamości cyfrowej reprezentowanej przez dokument mObywatel.

Jeśli ktoś zainteresowany jest szczegółami technicznymi i zawartością komunikatów wymienianych między apką mObywatel a serwerem, warto zajrzeć do tego tekstu na stronach internetowych firmy Securing.

Ile czasu trwało poszukiwanie, odnalezienie i opisanie tych podatności? DWA DNI. Jakie efekty osiągnie więc adwersarz mający tygodnie i miesiące?

Czy dostępność pełnego kodu źródłowego obniża bezpieczeństwo aplikacji?

Powiedzmy to wprost – jeśli aplikacja mobilna działa na twoim urządzeniu, to masz pełną kontrolę nad jej wykonywaniem i możesz w dowolny sposób badać i modyfikować jej zachowanie. Nie potrzebujesz do tego kodu źródłowego. Narzędzia takie, jak Frida czy Xposed pozwalają na „wkłucie się” w działający program i podglądanie jego stanu.

Komunikator Signal cieszy się uznaniem ekspertów – jego otwarty kod źródłowy przeszedł liczne audyty hobbystów i zawodowców. Czy da się go „shackować”? W tym artykule opisuję, jak podsłuchać komunikację Signala z serwerami i jak zdekodować jego zaszyfrowaną bazę danych – i to bez znajomości kodu źródłowego! Pokazuję też, dlaczego Signal (ani żadna inna apka zainstalowana przez użytkownika) nie jest w stanie sprawdzić, czy takie działania mają miejsce.

W dokładnie taki sam sposób da się kontrolować mObywatela – w swojej prezentacji Szymon pokazał wręcz, jak wstrzykuje do niego spreparowane dane. Możemy podglądać pełną komunikację sieciową – i to w obu kierunkach. Możemy śledzić aktywność systemu plików, czyli zapisy i odczyty zarówno danych tymczasowych, jak i informacji przechowywanych trwale. Możemy kontrolować wywołania funkcji systemowych – wraz z parametrami i wartościami zwracanymi (możemy je też dowolnie modyfikować „w locie”).

Owszem, zaciemnianie kodu wykonywalnego – zastosowane w mObywatelu – spowalnia proces, ale nie podnosi znacząco wymaganych kompetencji. Odtworzenie metod działania apki jest jedynie kwestią umiejętności i czasu. Zastanówmy się więc…

Czy kod źródłowy mObywatela pomoże ruskim?

Polska graniczy z rosją – państwem rządzonym przez zbrodniczy reżim, od kilku lat toczącym pełnoskalową wojnę z Ukrainą. Tamtejsi propagandyści nie ustają w podsycaniu nienawiści do naszego kraju – wskazują wręcz, że Polska będzie następna w kolejce do zbrojnego najazdu.

Czy ta perspektywa może wpłynąć na decyzje dotyczące systemów informatycznych administracji publicznej? W końcu do ich atakowania potrzebne są kompetencje i czas a tego naszym wrogom nie brakuje. Powtórzmy, aby się utrwaliło – tzw. state actors to nie przestępcy, którzy stanąwszy wobec kłopotów z reverse engineeringiem poszukają łatwiejszego celu. To ludzie, którzy mogą pracować nad jednym tematem przez miesiące i lata, zaś odkryte w ten sposób podatności gromadzić do użycia w dogodnym dla zleceniodawców momencie.

Nie musimy i nie powinniśmy rezygnować z transparentności, bo ona sama w sobie niesie dużą wartość i wzmacnia systemy demokratyczne! To rzekłszy, z całą pewnością należy podjąć działania, które zminimalizują dające się zidentyfikować ryzyka.

Oto niekompletna lista działań zaradczych i procesów, które warto wdrożyć przed otwarciem źródeł aplikacji takiej, jak mObywatel:

1. Wystawianie „do świata” jedynie kopii kodu źródłowego składającego się na kolejne publiczne wydania aplikacji. Mile widziane będzie repozytorium, jeden płaski commit (git merge --squash) per release wystarczy. Procesy produkcyjne nie muszą być jawne.
2. Wycięte metadane – m.in. aby chronić tożsamość programistów pracujących nad aplikacją. Zero branchy developerskich, zero hardkodowanych danych uwierzytelniania, URL-i środowisk testowych itp.
3. Wszystkie sekrety przeniesione do zamkniętego procesu CI/CD – repozytorium kodu nie powinno zawierać jakichkolwiek certyfikatów, niepublicznych kluczy API, itp.
4. Odpowiednio zmodyfikowane procesy developerskie – np. zastąpienie komentarzy typu FIXME albo TODO odpowiednio zarządzanym bugtrackerem
5. Wdrożenie procesu, w którym zgłoszenia błędów bezpieczeństwa realizowane są w sposób niepubliczny

Po napisaniu tych słów zajrzałem do wspomnianej już opinii CSIRT MON i znalazłem tam listę zbliżoną do powyższej, zakończoną konkluzją, z którą w pełni się zgadzam: „powyższe implikuje konieczność ponownej analizy kodu i usunięcia zbędnych / nadmiarowych informacji”. Pamiętajmy, że programiści mObywatela wiedzą o tym od maja 2023. Mieli dość czasu na podjęcie działań.

Jak rozpruć mObywatela

Zajmę się wersją mObywatela dla systemu Android, bo znam to środowisko lepiej, niż iOS.

1. Pobieramy paczkę dystrybucyjną aplikacji mObywatel 4.73.0 (najnowszą w chwili tworzenia tego tekstu) ze strony APKMirror, rozpakowujemy plik APKM będący de facto plikiem ZIP. Wewnątrz znajdujemy główny plik APK mObywatela (base.apk) oraz kilkanaście plików z bibliotekami i zasobami dla różnych architektur i rozmiarów ekranu telefonu
2. Ze strony apktool.org pobieramy aplikację apktool
3. Wykonujemy komendę apktool d base.apk

W efekcie wykonania tej komendy otrzymujemy 99.509 plików składających się na kod i zasoby aplikacji mObywatel. Spośród nich 96.262 to pliki SMALI zawierające symboliczny zapis bajtkodu aplikacji.

Oprócz tego możemy podejrzeć inne zasoby – np. w katalogu assets znajdują się regulaminy, fonty i pliki z modelami TensorFlow Lite do rozpoznawania QR-kodów. W katalogu res znajdziemy np. animację flagi, pliki składowe „hologramu z orzełkiem”, tła różnorakich legitymacji oraz wszystkie napisy, jakie pojawiają się gdziekolwiek w aplikacji.

Nie wchodząc w szczegóły techniczne – wszystkie pliki składowe można swobodnie podglądać, modyfikować a następnie za pomocą komendy apktool b złożyć w nową, zmodyfikowaną wersję aplikacji mObywatel. Stopień modyfikacji jest zasadniczo dowolny, ale to często zbędny wysiłek. Biznes, w którym dzieci za 20 zł kupują „apki mObywatel” prezentujące fałszywe dowody osobiste, by przy ich użyciu kupować energetyki i alkohol, opiera się na dużo prymitywniejszych rozwiązaniach. O temacie pisał serwis Demagog, kilkuminutowy materiał nagrał też Piotr Konieczny z Niebezpiecznika.

Dygresja i spekulacja bazująca na moim doświadczeniu ex-programisty androidowego – te niemal sto tysięcy plików SMALI odpowiada kilkunastu tysiącom plików źródłowych KT (Kotlin), z których ~80% to biblioteki i komponenty dostarczane przez projekty rozwijane w modelu open-source. Można zgrubnie szacować, że „właściwy” mObywatel składa się z kilku tysięcy plików źródłowych napisanych przez Centralny Ośrodek Informatyki (COI), z których zobaczyliśmy niecałe dwieście.

Popełniono fałszerstwo mObywatela, niech policja natychmiast przyjedzie do internetu!

W tym miejscu ktoś mógłby krzyknąć, że sam popełniam przestępstwo, bo artykuł 270 Kodeksu Karnego mówi w § 1: „Kto, w celu użycia za autentyczny, podrabia lub przerabia dokument lub takiego dokumentu jako autentycznego używa,podlega karze pozbawienia wolności od 3 miesięcy do lat 5”.

Jest gorzej, przecież przeprowadziłem tę operację przy użyciu aplikacji apktool pobranej z internetu, zaś artykuł 269b §1 KK głosi: „Kto wytwarza, pozyskuje, zbywa lub udostępnia innym osobom urządzenia lub programy komputerowe przystosowane do popełnienia przestępstwa określonego w art. […] podlega karze pozbawienia wolności od 3 miesięcy do lat 5”.

Zauważmy – mowa o narzędziach „przystosowanych do” a wystarczy samo ich pozyskanie. Chciałbym uspokoić jednak prokuratora analizującego ten artykuł, narzędzie apktool ma wiele legalnych zastosowań. Jednym z nich jest np. weryfikacja, czy aplikacja, którą wysyłamy do sklepu Play, nie zawiera niepożądanych plików. To dzięki niej odkryłem w marcu 2020, że rządowa aplikacja Kwarantanna Domowa zawierała bony do Leclerca. Także funkcja składania pliku APK przez apktool znajdzie zgodne z prawem zastosowania, jak np. weryfikacja poprawności obfuskacji apki przez narzędzie ProGuard/DexGuard.

Kodeks Karny mówi o „fałszowaniu dokumentu”, jednak oglądanie aplikacji od środka jeszcze fałszerstwem nie jest. Bardzo nieoczywista jest za to kwestia, czym jest zdefiniowany w ustawie „dokument mobilny mObywatel”. Poświęciłem temu zagadnieniu osobny artykuł i nie znalazłem przekonującej odpowiedzi. Prawo po raz kolejny nie nadążyło za technologią.

Czy nieautoryzowane przeróbki mObywatela stanowią zagrożenie?

Wiemy, że każdy może przerobić aplikację mobilną mObywatel w dowolny sposób. Co z tego wynika? Zaskakująco niewiele.

Zmodyfikowana aplikacja pokaże „ruchomą flagę” i „hologram z orzełkiem” (test tzw. „metodą wizualną”, kompletnie bezwartościową), może też zawierać całą resztę oryginalnej aplikacji (przejdzie więc test „metodą funkcjonalną” która jest równie kuriozalna). Żadna modyfikacja nie pozwoli jednak na oszukanie metody kryptograficznej, w której dane użytkownika pojawiają się na drugim urządzeniu (albo stronie internetowej) za pośrednictwem serwerów zarządzanych przez COI i Ministerstwo Cyfryzacji.

Także dystrybucja zmodyfikowanej aplikacji napotka trudności – gdyby nawet trafiła do sklepów Google Play / App Store, zostanie zdjęta jak tysiące innych fałszywek. Dystrybucja apki poza oficjalnymi sklepami jest skrajnie trudna w przypadku iPhone’ów i mocno utrudniona w przypadku Androidów.

Fałszywa aplikacja na pewno nie będzie w stanie nadpisać apki oryginalnej (np. udając aktualizację), bo fałszerz nie dysponuje certyfikatem cyfrowym stanowiącym pilnie strzeżony sekret wydawcy aplikacji. To zaleta kryptografii asymetrycznej – każdy może zweryfikować zgodność podpisu, jednak tylko posiadacz klucza może taki podpis złożyć.

To sprawia, że trudno wyskalować atak tego typu. Przestępcy uzyskują dużo wyższy zwrot z klasycznych oszustw, wyłudzeń i phishingu. Nikły procent atakowanych nie ma jeszcze apki mObywatel a jednocześnie da się nakłonić do jej instalacji z lewego źródła.

Dlaczego publikacja kodu przebiegła w sposób tak głupawy?

Opublikowane fragmenty kodu źródłowego mObywatela zostały wystawione na dedykowanej podstronie serwisu internetowego mobywatel.gov.pl. Aby je obejrzeć, trzeba zalogować się za pomocą Profilu Zaufanego. Okienko prezentujące kod źródłowy blokuje możliwość skopiowania go do schowka za pomocą znanej antyhakerskiej dyrektywy CSS user-select: none !important; – jest ona mniej więcej tak skuteczna, jak kłódka z plasteliny.

Skąd takie dziwaczne pomysły? Nie musimy zgadywać: wynikają z rekomendacji CSIRT MON, w której czytamy: „udostępnianie powinno uwzględniać jedynie wgląd w kod (bez możliwości pobierania) oraz zapewnić pełną rozliczalność użytkowników (np. logowanie z wykorzystaniem profilu zaufanego lub potwierdzenia aplikacją mObywatel), a jego dostępność powinna zostać ograniczona tylko do obywateli RP”.

Pismo CSIRT MON jest wewnętrznie sprzeczne. Nie da się jednocześnie odnosić korzyści z publikacji kodu ( „publikacja kodu […] może zwiększyć zaufanie obywateli do aplikacji”) przy spełnieniu postulowanych ograniczeń (pełna rozliczalność dostępu, wyłącznie wgląd w kod).

Jeśli użytkownik może wyświetlić kod źródłowy na ekranie swojego komputera i widzi go własnymi oczami – game over, tego dżina nie wepchnięcie już do butelki. A naród u nas przekorny, raptem kilka godzin po publikacji kodu na GitHubie zaczęły pączkować repozytoria z kopią wszystkich udostępnionych plików.

Rygory kontroli dostępności i rozliczalności można byłoby spełnić jedynie poprzez prezentację kodu źródłowego na komputerze odłączonym od internetu i pod nadzorem obserwatora. Tym samym potencjalna „analiza/sprawdzenie kodu przez internautów” traci rację bytu.

Dlaczego nie opublikowano pełnych źródeł mObywatela?

Spekulacja: bo osoby odpowiedzialne w Agencji Bezpieczeństwa Wewnętrznego za opiniowanie takiego udostępniania nie zwykły bawić się w otwartość i transparentność.

Tomasz Rychter pisze:

[…] Resorty siłowe nie są od innowacji, są od bezpieczeństwa i brania odpowiedzialności za to bezpieczeństwo, ktoś złośliwy powiedziałby, że są wręcz betonem. […]
Jaką więc decyzję podejmą bezpiecznicy i co zalecą: “Nie pokazywać, zwłaszcza w obecnej sytuacji geopolitycznej.” […]

Dodajmy, że decyzja o usunięciu niewielkich, krytycznych fragmentów kodu źródłowego z udostępnianej paczki może być przeciwskuteczna. Nawet po obfuskacji da się dopasować zaciemnione binarki do odpowiednich fragmentów kodu. Tym samym brakujące fragmenty będą krzyczeć „tu są interesujące rzeczy, zaczynaj reverse engineering od tego kawałka”.

Co ciekawe, opinia CSIRT MON nie była tu kluczowa, choć to właśnie wojsko kojarzy się z najbardziej konserwatywnym podejściem do przejrzystości. Wśród podejrzanych mamy więc CSIRT NASK oraz CSIRT GOV. Czy rządowy CSIRT GOV pomagał czy przeszkadzał? Oraz – co było tu pomocą a co przeszkodą? Do tego tematu wrócę na końcu tekstu.

Skąd licencja MIT?

Gynvael Coldwind zadał interesujące pytanie – dlaczego opublikowane fragmenty kodu są licencjonowane na licencji MIT?

Ustawa o mObywatelu nałożyła obowiązek publikacji kodu, ale nie wskazała żadnych wymogów dotyczących licencjonowania – w szczególności nie nałożyła obowiązku stosowania licencji typu Open Source / Free Software. Gdyby pliki źródłowe aplikacji po prostu wylądowały na stronach rządowych, publiczność mogłaby je oglądać, ale nie byłaby uprawniona do ich ponownego użycia.

Miłym gestem ze strony Centralnego Ośrodka Informatyki i Ministerstwa Cyfryzacji jest więc użycie licencji, która daje użytkownikom najwięcej swobody. Oficjalnego uzasadnienia brak, nieoficjalne znajdziemy na LinkedIn w komentarzu Radosława Maćkiewicza, dyrektora COI: „[…] Publikując kod raczej powinniśmy nałożyć licencję opensource i została wybrana MIT jako najbardziej odpowiednia. […]”

A co z udziałem społeczności w rozwoju mObywatela?

Wielu ludzi znających model rozwoju Open Source / Free Software ma wyjątkowo proste oczekiwania – aplikacje rządowe powinny trafiać do publicznego repozytorium, aby każdy chętny mógł je oglądać, poprawiać i modyfikować.

Stety lub niestety – to się nie wydarzy. Powodów jest wiele a każdy z nich istotny. Przyjrzyjmy się bliżej kilku z nich.

Po pierwsze – podstawa prawna

Istnieje znacząca różnica między prawami obywatela a prawami regulującymi działalność urzędów. Obywatel może robić wszystko, czego prawo mu nie zabrania. Urząd może robić jedynie to, na co prawo mu zezwala. Różnica jest dość fundamentalna, szczególnie gdy mowa o osobistych i majątkowych prawach autorskich do tworzonego oprogramowania.

Gdy jako programista zakładasz publiczny projekt na GitHubie i wrzucasz tam swój kod – albo wysyłasz zmiany do cudzego projektu – kwestię praw autorskich do własnego kodu możesz mieć w nosie. Długa jest debata, do jakiego stopnia da się w Polsce zrzec autorskich praw majątkowych czy też w jakiej formie dokonać skutecznego i nieodwoływalnego licencjonowania kodu na wszystkich obecnych i przyszłych polach eksploatacji, ale nie będziemy się tym zajmować. Kto chce, szuka sposobu – np. poprzez wysłanie swojego pull requesta do kernela systemu Linux de facto licencjonujesz zmiany na licencji GNU GPL w wersji drugiej.

Dygresja – choć fundacja The Linux Foundation jest organizacją prywatną, prowadzenie działalności w USA, Europie i Japonii wymusza zgodność z szeroką gamą przepisów. To wyklucza np. współpracę z organizacjami z krajów objętych sankcjami, jak rosja czy Iran – a niekiedy i z indywidualnymi programistami przebywającymi w takich obszarach.

Ministerstwo Cyfryzacji albo COI nie może tak po prostu przyjąć od losowej osoby kodu źródłowego, grafik, dokumentacji ani czegokolwiek innego. Urzędy muszą dbać o podstawy prawne – nawet, gdyby finalny produkt był dystrybuowany pod otwartą licencją. Wyobrażam sobie, że minimalną podkładką chroniącą wszystkich zainteresowanych musiałaby być jakaś forma oświadczenia, porozumienia czy umowy dotyczącej wykorzystania i stosowania osobistych i majątkowych praw autorskich, oraz konieczna byłaby identyfikacja dostawcy / wolontariusza.

Po drugie – nieunikniona nieprzejrzystość procesu

mObywatel nie jest produktem rozwijanym publicznie, nie ma społeczności wpływającej na plan kolejnych wydań ani publicznej listy funkcji czekających na implementację. To sprawia, że propozycje zmian dostarczanych przez wolontariuszy mogłyby spotkać się z odmową. Można przy tym wyobrazić sobie sytuację, że dokładny powód owej odmowy pozostanie niejawny. Taka sytuacja na pewno spowoduje publiczne spory i zarzuty o złą wolę.

O ile można bez większego problemu opublikować zasady formatowania kodu, to dużo trudniej wdrożyć zewnętrznych dostawców do specyfiki danego projektu i wynikających z niej ograniczeń. Zewnętrzni dostawcy nie będą mieli przecież dostępu do środowisk testowych ani jakichkolwiek zasobów wymagających poświadczeń bezpieczeństwa.

Współpraca ze społecznością byłaby konkretnym kosztem i spowalniała prace nad mObywatelem, bo członkowie zespołu zostaliby obciążeni dodatkowymi obowiązkami – np. przeglądami kodu albo obsługą publicznych ticketów ze zgłoszeniami (nie wszystkie będą sensowne).

Po trzecie – fork jest wykluczony

Jeśli programiści pracujący nad oprogramowaniem Open Source nie zgadzają się z narzuconym kierunkiem rozwoju, mogą utworzyć na bazie istniejącego kodu nowy projekt (tzw. fork). Przykładami są MySQL / MariaDB, Terraform / OpenTofu, Redis / Valkey, CyanogenMod / LineageOS. Takiej możliwości nie ma przy projektach scentralizowanych, jak mObywatel.

Kod źródłowy mObywatela będzie stanowił istotną wartość edukacyjną, ale nie udawajmy, że da się go wykorzystać gdziekolwiek indziej. Być może w kraju, w którym poszczególne resorty nie stanowią izolowanych silosów, dałoby się uniknąć wielokrotnego implementowania tych samych funkcjonalności w różnych apkach, ale koordynacja takich zadań jest trudna a korzyści – nieoczywiste.

Po czwarte – nieprzyjaciel czuwa

Nasi wrogowie na pewno sprawdzą, jakich szkód mogliby narobić przy okazji otwarcia mObywatela na zmiany pochodzące z zewnątrz. Do głowy przychodzi próba wstrzyknięcia niepożądanego kodu (afera xz pokazuje, że jest to możliwe nawet w świecie open-source), podstawienie bibliotek zewnętrznych z backdoorem, infiltracja infrastruktury serwerowej, infekcja stacji deweloperskich itp.

Ukraińska Дія/Diia jako przykład (braku) współpracy ze społecznością

Nie musimy zgadywać, jak mógłby wyglądać udział społeczności w rozwoju „zagranicznego mObywatela”, bo mamy dobry przykład – ukraińską aplikację Дія (Diia). Zajrzyjmy na stronę opensource.diia.gov.ua aby dowiedzieć się więcej.

Na stronie tej czytamy, że kod źródłowy aplikacji mobilnych nie jest objęty żadną z popularnych licencji Open Source / Free Software, jak GNU GPL, Apache License czy MIT License. Zamiast tego używana jest licencja oparta o prawo Ukrainy, która nie jest wirusowa (jak copyleft w GPL) ani permisywna (jak MIT). Wymienia za to konkretne warunki użycia, może być cofnięta i jednostronnie zmieniona, zaś jej akceptacja musi mieć formę dokumentu podpisanego cyfrowo.

Jednocześnie repozytorium kodu zawiera szereg projektów opatrzonych wyłącznie copyleftową licencją EUPL 1.2 (zezwalającą na relicencjonowanie m.in. pod licencjami GNU GPL v2/v3).

O co tu chodzi? Może licencje te mają różne obszary użycia i np. licencja rządowa (oparta o ukraińskie prawo) jest przeznaczona dla ukraińskich instytucji, podczas gdy „reszcie świata” bardziej odpowiadać będzie EUPL 1.2? Nie wiadomo. Wprowadza to znaczącą niepewność.

Same repozytoria kodu aplikacji androidowej i aplikacji iOS-owej zgromadziły po kilkaset githubowych gwiazdek, więc są relatywnie mało popularne. Oba mają po raptem kilkanaście commitów i kilka tagów na jedynej dostępnej gałęzi – to oznacza, że rzeczywista praca przebiega gdzie indziej, zaś do publicznego repozytorium wrzucane są zrzuty kodu kolejnych wydań apki.

Współpraca ze społecznością na dobrą sprawę nie istnieje. Nie wiemy, czy jest w ogóle dopuszczalna i mile widziana. Oba repozytoria zgromadziły raptem kilkadziesiąt ticketów i pull requestów. Znaczna większość pochodzi z pierwszej połowy 2024 (data otwarcia źródeł) i nadal wisi otwarta, przy niemal zerowej aktywności instytucji rozwijającej aplikację.

Wnioski? W komunikacji dotyczącej otwierania źródeł aplikacji rządowych należy jasno wskazać, jakie cele są w ten sposób realizowane i jaki jest planowany zakres współpracy z odbiorcami tego kodu. Lepiej zastrzec, że propozycje zmian nie będą przyjmowane, niż pozwolić na tworzenie pull requestów i ignorować je latami.

Co było w niejawnych opiniach CSIRT NASK i CSIRT GOV

Publiczność w social mediach nie była zachwycona rozwojem wypadków:

Tomasz Janusz pisze:

[…] To, co jednak wczoraj miało miejsce, nie sposób inaczej określić jak pokazanie środkowego palca całej społeczności IT, która chciała wspomóc ministerstwo w tworzeniu bezpiecznej i jednocześnie transparentnej dla obywatela platformy usług rządowych. […]

To jest wręcz absurdalna sytuacja, że mObywatela można lepiej poznać poprzez dekompilację pakietu aplikacji pobranego z Google Play. […]

Budowy społeczeństwa obywatelskiego nie zaczyna się od powiedzenia, aby obywatele dali spokój biednym rządzącym. […]

Choć opinie CSIRT NASK i CSIRT GOV na temat udostępnienia kodu źródłowego mObywatela pozostają utajnione, odnośne klauzule można przecież zdjąć. Niniejszy artykuł kończę więc korespondencją, którą wysłałem do wszystkich instytucji zaangażowanych w proces udostępniania kodu źródłowego aplikacji mobilnej mObywatel:

Dzień dobry

Jako redaktor naczelny czasopisma „Informatyk Zakładowy”(wpisanego do rejestru dzienników i czasopism pod numerem Rej Pr 3727) zwracam się do Państwa w następującej sprawie. W dniu 29 grudnia 2025 Ministerstwo Cyfryzacji poinformowało o publikacji kodu źródłowego aplikacji mobilnej mObywatel, jednak – ku powszechnemu rozczarowaniu – w opublikowanym zestawie znalazło się jedynie kilka procent plików składających się na aplikację. Domniemuje się, że było to rezultatem niejawnych opinii przekazanych Ministrowi Cyfryzacji przez CSIRT NASK i CSIRT GOV.

W związku z tym, że udostępnienie tak małej części plików nie realizuje de facto obowiązku nałożonego na Ministra Cyfryzacji, proszę o:

• odtajnienie i udostępnienie opinii CSIRT-ów NASK i GOV w całości lub przynajmniej w części dotyczącej rekomendowanego zakresu udostępnienia kodu;
• udostępnienie decyzji i roboczych dokumentów dotyczących zakresu i procesu publikacji kodu źródłowego aplikacji mobilnej mObywatel.

Z góry dziękuję

Tomasz Zieliński
redaktor naczelny

Jeśli otrzymam odpowiedzi, podlinkuję je poniżej.

[dodano 9.01.2026] rzecznik prasowy ABW (CSIRT GOV) odpowiedział zwięźle: „uprzejmie informujemy, że wymienione w Pana wiadomości email dokumenty stanowią tzw. dokumentację bezpieczeństwa dla aplikacji mObywatel. Mają one charakter niejawny, zatem zgodnie z ustawą o ochronie informacji niejawnych podlegają ochronie i nie mogą być publicznie udostępnione”

[dodano 16.01.2026] Dyrektor Departamentu Bezpieczeństwa Narodowego KPRM na temat dokumentów, o które wnioskowałem : „[…] Mają one charakter niejawny, zatem zgodnie z ustawą o ochronie informacji niejawnych podlegają ochronie i nie mogą być publicznie udostępnione”

Ministerstwo Cyfryzacji o opiniach otrzymanych z CSIRT-ów: „[…] W opinii Ministerstwa Cyfryzacji w opisanym przypadku nie występują jednak przesłanki, aby wystąpić do CSIRT GOV i CSIRT NASK z prośbą o wyrażenie zgody na zniesienie klauzuli niejawności”

Czekam na odpowiedź z CSIRT NASK