Dezinformacja

Dezinformacja to coś, co działa w różne strony. Dziś spotkałem się z dezinformacją wymierzoną przeciw Chinom. A w zasadzie chińskim pojazdom. Zaczęło się od social mediów i informacji:

A Norwegian bus company wants to know if their buses could be abused by China in the case of war.

So they drive two buses deep into a limestone mine to isolate them from the internet and forensically investigate how they work.

In the mine, investigators discover a Chinese kill switch which could destroy all Chinese buses.

No sensacja na miarę afery Newagu, który umieścił w oprogramowaniu blokadę wymierzoną przeciw innym serwisom, prawda?

Tylko, że niekoniecznie. Oryginalny, podlinkowany artykuł, w mało popularnym języku (pszypadek? nie sądzę) twierdzi bowiem rzeczy dokładnie odwrotne (Google Translate):

Na przykład, czy możliwe jest, aby chiński rząd uzyskał dostęp do licznych kamer w autobusach miejskich, gdyby pewnego dnia, w nie do pomyślenia przyszłości, chciał wykorzystać je do monitorowania na przykład Chińczyków w Norwegii? Tor Indstøy i jego zespół nie znajdują na to żadnych dowodów. I to jest pozytywne. Ale odkrywają coś jeszcze. Chiński autobus elektryczny zawiera komputer, który między innymi steruje akumulatorem i silnikiem autobusu, aby autobus mógł jak najefektywniej poruszać się po Oslo. Komputer ten – za pośrednictwem małej karty SIM – jest podłączony do internetu, dzięki czemu może wysyłać informacje, a czasami pobierać aktualizacje. Bo tak, autobus można aktualizować dokładnie tak samo, jak telefon. Śledczy doszli do następującego wniosku: taka aktualizacja umożliwia chińskiej firmie stworzenie funkcji, która całkowicie uniemożliwia jazdę autobusowi. Ponownie musimy wyobrazić sobie przyszłość, w której nasze relacje z Chinami będą bardziej napięte niż obecnie, a chiński rząd chce doprowadzić do upadku Oslo, blokując kilkaset autobusów miejskich na środku ulicy w godzinach szczytu. To prawdopodobnie się nie wydarzy. Ale może się wydarzyć.

Czyli nie znaleziono funkcji szpiegujących. Nie znaleziono – dokładnie odwrotnie, niż w przypadku afery Newagu – killswitcha umożliwiającego unieruchomienie sprzętu. To, co znaleziono, to jedynie łączność i możliwość pobierania aktualizacji. Typowe funkcjonalności.

Oczywiście, każda aktualizacja oprogramowania może całkowicie zmienić jego działanie. Czy to w sposób zamierzony, czy niezamierzony – w wyniku błędnej aktualizacji urządzenie może przestać działać. Ale czy o każdym pojeździe z łącznością poprzez kartę SIM i aktualizacją softu napiszemy, że ma killswitcha? Czy systemy Windows i macOS mają killswitcha? Android? iOS? W końcu czy killswitcha ma mój Debian, na którym zainstalowałem unattened-upgrades? Nie, nikt rozsądny tego w ten sposób nie nazwie.

Tymczasem lawina dezinformacji i antychińskiego FUD ruszyła i np. polskie (ale nie tylko) media krzyczą już nagłówkami w stylu Chińskie autobusy mogą być zdalnie sterowane. Szokujące wyniki testu czy Chińczycy mogli sterować autobusami w Danii? Te same pojazdy jeżdżą w Polsce. No i oczywiście po drodze już dorobiły się killswitchy.

Warto sprawdzać źródła[1], tym bardziej, jeśli w grę wchodzi lobbing, kontrakty na sprzęt i duże pieniądze.

I dla jasności, doceniam model zagrożeń, który przewidują Norwegowie. Uważam, że urządzenia (nie tylko pojazdy, instalacje fotowoltaiczne czy lodówki też mogą dać bardzo ciekawe efekty) generalnie nie powinny mieć dostępu do sieci, a użytkownik powinien mieć możliwość samodzielnego decydowania fakcie i czasie wykonywania aktualizacji. Czym może się skończyć aktualizacja w nieodpowiednim momencie – wiadomo.

Warto też zwracać uwagę na ile bliskie politycznie są firmy mające kontrolę nad urządzeniami. Bo czy np. Tesle w Europie mogą szpiegować kamerami? Czy mogą dostać oprogramowanie, które w określonych okolicznościach uniemożliwi otwarcie drzwi, zablokuje możliwość kierowania i rozpędzi pojazd do maksymalnej prędkości? Cytując artykuł: To prawdopodobnie się nie wydarzy. Ale może się wydarzyć.

[1] Tak, mam świadomość, że duński artykuł powstał na bazie norweskiego. Niestety, paywall.

Debian Trixie

Wczoraj została nowa wersja Debiana, o nazwie kodowej Trixie. Podobnie jak przy okazji Bookworm, wrażenia z instalacji.

Na pierwszy rzut, jeszcze wczoraj, poszedł kontener LXC w którym działa nowy certstream[1]. Nie bardzo miało co pójść nie tak i… nie poszło. Aktualizacja w zasadzie nudna, jedyne o czym warto pamiętać, to zmiana formatu w jakim podawane są źródła apt. Nie była to nowość, bo w końcu na desktopie mam od dawna Debiana Sid.

Rozochociło mnie to i jako drugi zacząłem aktualizować kontener z Linuksem na Chromebooku. No nie polecam. Będę przywracał z backupu. Ale to raczej nie wina Debiana, raczej coś przeoczyłem, lub – co najbardziej prawdopodobne – po prostu są dodatkowe elementy wymagane przy interakcji. Komunikaty niezbyt pomocne, w zasadzie naprowadzają jedynie na zbyt małą ilość przydzielonej pamięci ale… nie wygląda na używaną.

Potem zaktualizowałem jeszcze kontenery LXC w których działają blogi. Wymagane były drobne poprawki związane ze zmianami w składni nginx oraz wersją PHP. Dość standardowo.

Więcej roboty było ze skryptami Pythona i virtual environments. Musiałem wszystkie utworzyć, przy okazji wyszły drobne zmiany w bibliotekach. Problemem jest ilość i konieczność ręcznej roboty, nie stopień komplikacji.

Szybka ściągawka z poleceń, oczywiście polecam lekturę instrukcji:

apt update
apt upgrade
# Zmiana wpisów w sources (sed -i "s/bookworm/trixie/" /etc/apt/sources.list)
apt update
apt upgrade --without-new-pkgs
apt full-upgrade
apt autoremove
apt modernize-sources
# Opcjonalnie
apt list '~o'
apt purge '~o'
apt list '~c'
apt purge '~c'

Jeśli coś ciekawego wyniknie na pozostałych systemach, dam znać.

[1] Notka w trakcie tworzenia, nie ma chronologii, oj, nie ma…

Raspberry Pi niemal read only

W końcu padła kolejna karta microSD. Tym razem jakaś chińszczyzna, kupiona wieki temu na Aliexpress. Działała długo. Nie pamiętam od kiedy, ale chyba parę lat. Znaczy się, problemy miała wcześniej, ale nie miałem czasu się tym zająć i jakoś działało. Chodzi oczywiście o Raspberry Pi robiące za router GSM.

O tym, że nie jest z nią dobrze wiedziałem. Przy instalacji nowych pakietów miała narowy i leciały jakieś błędy. Za pierwszym razem ograniczyłem zapisy na kartę – wyłączyłem bieda statystyki w postaci logowania ilości przesłanych danych. Mogłem wyłączyć więcej logów oraz swap, ale nie wpadłem na to. Zresztą, działało.

A teraz pewnego dnia zniknął internet, akurat gdy pracowałem. Oczywiście udostępniłem sobie net z komórki, ale zrobiłem szybką diagnostykę. W logach czysto, w dmesg czysto, uptime 240 dni. Reboot i… nadal nie działało. Za to chwilę po reboocie przy zwykłym działaniu pojawiły się błędy odczytu. Uznałem, że wina karty.

Chyba niesłusznie i była to po prostu awaria a2mobile, bo po przełożeniu modemu do innego komputera netu także nie było.

Tu mała dygresja odnośnie operatorów. Zmigrowałem z Aero2 na a2mobile i tak to sobie działa. Przy okazji – można odzyskać kaucję za kartę, którą pobierało Aero2. Nie trzeba odsyłać karty, nie trzeba podawać numeru ani wypełniać druku – wystarczy napisać email, tak jak to opisano na Pepper. W mniej niż tydzień pieniądze z depozytu miałem na koncie.

Tak w ogóle to widzę, że w Aero2 mają nowe pakiety i może niepotrzebnie rezygnowałem. Bo teraz w Aero2 dają 10 GB za 10 zł bez limitu prędkości. Z kolei obecne a2mobile nadal daje za 12,9 zł 5 GB bez limitu prędkości, kolejne 5 GB z limitem 3 Mbps (modem 3G, więc nie robi to dramatycznej różnicy i spokojnie da się działać), kolejne 5 z limitem 1 Mbps (no tu jest wolno już), a potem 512 kbps. W praktyce pewnie zwykle mieściłbym się w 10 GB, a lepiej dopłacić 10 zł za kolejny pakiet przy tych rzadkich okazjach, kiedy potrzeba będzie więcej transferu. Hmm…

No ale skoro karta ewidentnie pada, to pora na wymianę. Czasu mało, więc zamawiać nie będę, szybka wizyta w sklepie, kupiłem jakiś dziwny wynalazek 32GB za 20 zł. Karta microSD z napisem full HD na opakowaniu. Przy okazji zauważyłem, że bardzo stary Raspbian się tam ostał – jeszcze oparty na bullseye. Zastanawiałem się przez chwilę, czy nie instalować nowego Raspbiana (oparty na bookworm), ale o ile backup obrazu karty miałem, o tyle plików nie. Oczywiście mogłem podmontować i zgrać pliki, ale stwierdziłem, że więcej będzie roboty z szukaniem ich wszystkich, niż z aktualizacją Raspbiana.

No i w sumie miałem rację – aktualizacja była bezproblemowa. Przy okazji wyłączyłem logi, wyłączyłem swap, zrobiłem lekki tuning pamięci, ustawiając minimalną możliwą dla karty graficznej (16 MB zamiast domyślnych 64 MB). No i zobaczymy, ile podziała teraz. Oczywiście mam świeży backup, znowu w postaci obrazu karty.

Przy okazji, trafiłem na ciekawy opis, jak zrobić w Raspberry Pi kartę w trybie read only przy pomocy overlayFS. Spróbowałem i… niestety nie działa, choć raspi-config twierdzi, że przełączył. Nie tylko u mnie, widziałem podobne opisy na forach – na 64bit niby działa, na 32bit – nie. A moje RPi to 1B, więc nie mogę 64bit użyć. Na dokładniejszy debug nie starczyło już czasu, może następnym razem się uda…