Software Craftsmanship Saturday vol. 81 - Lapsus$, KRaft i Asahi Linux

1. Grupa Hakerska Lapsus$ atakuje Microsoft, Samsunga, Nvidie i Oktę

Według słownika języka polskiego, Lapsus to «błąd w wypowiedzi popełniony przez roztargnienie». Okazuje się, że jest to także (chociaż przy użyciu “hakierskiego” liternictwa – Lapsus$) grupa hakerska, która napsuła w zeszłych tygodniach krwi wielu dużym podmiotom branży IT.

Jedną z zaatakowanych firm był Microsoft (któremu ukradziono kod źródłowy Binga, Bing Maps i asystenta głosowego – Cortany ), Samsung (Ci stracili min. kod źródłowy do modułów biometrycznych Galaxy) czy Nvidii (od której zażądano… wydania otwartoźródłowej wersji sterowników i ściągnięcia ograniczeń w użyciu ich kart do kopania krypto). Oberwało się również UbiSoftowi.

Tak naprawdę jednak najgorszy cios wizerunkowy dostała Okta. Według doniesień, uzyskano dostęp do (w zależności od doniesień) laptopa firmy lub “cienkiego klienta” z dostępami do systemów wewnętrznych

Jak podaje firma:

Potencjalny wpływ na klientów Okta ogranicza się do dostępu, jaki mają inżynierowie wsparcia. Inżynierowie ci nie mogą tworzyć ani usuwać użytkowników ani pobierać baz danych klientów. Inżynierowie pomocy technicznej mają dostęp do ograniczonych danych — na przykład zgłoszeń Jira i list użytkowników — które widać na zrzutach ekranu. Inżynierowie pomocy technicznej mogą również ułatwić użytkownikom resetowanie haseł i czynników MFA, ale nie są w stanie uzyskać tych haseł.

Co, że to brzmi na znacznie mniej groźny incydent niż wyciek Binga? Warto w tym miejscu przypomnieć sobie, czym Okta się zajmuje. Firma zapewnia rozwiązania Single-Sign-On dla firm, stanowi więc pierwszą (i często główną) linie obrony dla wrażliwych danych przedsiębiorstw używających jej usług. Niesmak pozostawia też to, że do incydentu doszło jeszcze w styczniu, ale wychodzi on na jaw dopiero teraz, więc przez całe dwa miesiące klienci firmy nie zdawali sobie sprawy z zagrożenia. Firma twierdzi, że już początkiem roku rozpoczęła akcje naprawcze po swojej stronie, ale dopiero teraz dostała raport o skali całości ze strony firmy wynajętej do zbadania skutków ataku. Eksperci jednak mają do jej reakcji masę zarzutów.

Zabawnym w tym wszystkim jest to, że według doniesień na czele grupy ma stać 16-latek z Oxfordu. Coraz zdolniejszą mamy młodzież.

Oczywiście, cyberwojna za naszą wschodnią granicą trwa, ale chyba i tak zbyt dużo ludzi informuje o ostatnich zakusach Anonimowych, żebym jeszcze ja Was tym zarzucał. Niby wszyscy o tym piszą, ale ja czekam na jakieś info od niebezpiecznika.

Źródła

2. Kafka wyjaśnia, czemu pozbywa się Zookeepera

No, pogadaliśmy sobie o wyciekach danych, to teraz czas wziąć na tapet jakiś mocno “inżynierski” temat, tak na przełamanie.

Algorytmy konsensusu i ogólnie systemy rozproszone są naprawdę fascynującym tematem, i dla mnie osobiście były “gateway drugiem” do wzięcia udziału w spotkaniach grup typu Papers We Love. Miałem zawsze wrażenie, że to jest ta część Computer Science, która należy do najbardziej praktycznych i “przekładalnych” na codzienną praktykę programistyczną. Z perspektywy mam wrażenie, że było to pokłosie wchodzenia w branżę w momencie, kiedy na całym szczycie krzywej hype’u znajdowały się pojawiające jak grzyby po deszczu bazy NoSQL. Pewnie dzisiaj bym się jarał jak pochodnia na blockchainowe whitepapery, z którymi jakiś “epizod” też miałem.

Ale ja jestem dziwny – mój pies się nazywa Paxos

I nie piszę Wam o tym dlatego, żeby jakoś szpanować (nie ma czym, są dziwniejsze hobby), co bardziej wytłumaczyć, dlaczego tak bardzo spodobała mi się publikacja ze strony Confluenta. Twórcy Kafki wypuścili bowiem bardzo dobrze skrojone podsumowanie, dlaczego zmienili Apache Zookepeera (czyli swój poprzedni system do osiągania konsensusu w klastrze Kafkowym) na wewnętrzną implementacje Rafta, którą nazwali KRaft. W odróżnieniu od klasycznych paperów o których wspominałem w poprzednim akapicie, artykuł jest znacznie przystępniejszy, zawiera również masę ilustracji. Poprzez porzucenie swoistego akademickiego rygoru, taka forma przedstawienia może przyciągnąć osoby nie lubujące się w konsumpcji tekstu sformatowanego małą czcionką w dwóch kolumnach.

Z artykułu dowiecie się, jakie problemy Kafka miała z Zookeeperem i dlaczego wybrany został akurat Raft, a nie któryś z innych algorytmów. Od razu zaspoileruje, że główną przyczyną odejścia od Zookeepera był paskudnie długi czas synchronizacji klastra po wystąpienia “rozszczepu mózgu”. Miałem okazję doświadczyć kiedyś tego typu awarii w praktyce (nie przy Kafce, ale przy Apache Solr, który też wykorzystuje Zookeepera), więc jak to mówią:

Źródła

Why ZooKeeper Was Replaced with KRaft – The Log of All Logs

3. Asahi Linux – pierwsza dystrybucja, którą uruchomicie na M1

A na koniec ogłoszenia ze świata systemów operacyjnych. Powstał pierwsza dystrybucja Linuxowa, którą można odpalić na procesorach M1 od Apple – na razie opublikowana w wersji alpha, ale możliwej do wypróbowania.

Według testów przeprowadzonych przez The Register Asahi, bo tak się nazywa, działa podobno zaskakująco dobrze, jeśli chodzi o wydajność i użycie CPU, i to pomimo nietypowej architektury M1. Oczywiście, sam fakt, że to jest wczesna alpha nowej dystrybucji Linuxa powinien zapalać Wam w głowie lampkę sugerującą, żeby nie instalować całości na głównym komputerze roboczym. Na ten moment są problemy z dźwiękiem, rozdzielczością większą niż 1920×1080, a także z Bluetooth i (tu akurat okazjonalnie) z WiFi.

Po co uruchamiać Linuxa na M1? A kiedy “bo można” przestało być dobrą odpowiedzią?

W całej dyskusji o M1 nie zapominajmy, że Asahi mógł powstać tak (relatywnie) szybko, ponieważ na dobrą sprawę jest w dużej części oparty na Arch Linux w wersji na komputery ARM, a mimo wszystkich swoich “twistów”, M1 pozostaje procesorem z tej rodziny. Dlatego niektórzy próbują przyglądać jak wygląda starcie rozwiązania Apple z innymi nowinkami w tej samej klasie wagowej. Ostatnio trafiłem przykładowo na interesujący benchmark M1 vs Graviton 2 od Amazonu w przypadku aplikacji napisanej za pomocą Node.js. Okazuje się, że o ile Graviton posiada zalety (wielordzeniowe środowisko pracy), to Mac Mini z M1 okazuje się być rozwiązaniem… wyjątkowo ekonomicznym. Tak, dożyliśmy czasów, że w celu obniżenia kosztów warto by było rozważyć zrobienia serwerowni z Maców -pomijając fakt, że nie jestem pewien na ile Mac Mini to wystarczająco “godna zaufania” konstrukcja do tego typu zastosowań.

Apple odbija sobie to oczywiście gdzie indziej

A żeby podsumować temat, to warto wspomnieć jeszcze o ostatnich premierach, o których nie miałem jeszcze okazji pisać. Niedawno zapowiedziany został procesor M1 Ultra, który na dobrą sprawę ma być po prostu kombinacją dwóch M1 Max spiętych w parę. Niesamowita bestia, którą z jakiegoś powodu Apple zdecydowało się pozycjonować jako konkurenta dla Nvidia RTX 3090, czyli hmm… jednego z najpotężniejszych GPU na świecie – tak, dalej mówimy tutaj o integrze na architekturze ARM.

Oczywiście, w takim pojedynku M1 Max nie ma żadnych szans, ale też ta walka nigdy nie należała do uczciwych, biorąc pod uwagę pobór mocy obu sprzętów. Znacznie bardziej interesujące są testy hands-on, z których wynika, że Apple… sztucznie ogranicza możliwości swojego układu. Okazuje się bowiem, że aby (prawdopodobnie) polepszyć kulturę pracy i zapewnić bez głośność sprzętu, M1 Ultra działa tylko przy użyciu części swoich maksymalnych możliwości. Dzięki temu jest w stanie operować przy użyciu mocno ograniczonego chłodzenia.

Software Craftsmanship Saturday vol. 81 – Lapsus$, KRaft i Asahi Linux

1. Grupa Hakerska Lapsus$ atakuje Microsoft, Samsunga, Nvidie i Oktę

Źródła

2. Kafka wyjaśnia, czemu pozbywa się Zookeepera

Źródła

3. Asahi Linux – pierwsza dystrybucja, którą uruchomicie na M1

Źródła:

Odkryj więcej świetnych treści!