Dzisiaj mamy mamy naprawdę fajną, inżynierską edycję – nowe Go z generykami i detale architektoniczne Fuchsia OS z pewnością spodobają się wszystkim tym lubiącym wertować dokumenty designowe. Ale oczywiście, żeby nie było tak różowo, mamy dla Was bardzo interesujący atak typu Supply Chain.
1. Go 1.18 wprowadza Generyki (i testy fuzzowane)
Jeżeli chodzi o języki programowania, Go z pewnością należy do największych sukcesów ostatnich lat. Od swojego debiutu w 2009 roku, regularnie obserwować możemy jego coraz szersze użycie, zwłaszcza w środowisku dev- i sys-opsowym. Pomimo niewątpliwych osiągnięć i zalet, ciągle znaleźć można było ogrom ludzi, którzy uważali, że nie należy traktować go jako “prawdziwy” język programowania. Powodem ku temu był brak jego wsparcia dla typów sparametryzowanych, potocznie zwanych “generykami”. Z przyjemnością chcę ogłosić więc, że ten argument nay-sayerom można wybić z rąk wraz z premierą Go 1.18, który przez samych twórców określany jest jako “największe wydanie Go od czasu jego premiery”.
To, że generyki pojawią się w Go było wiadome już od pewnego czasu – oryginalny proposal dla tej funkcjonalności pojawił się jeszcze w zeszłym roku. W tym też długim dokumencie znajdziecie pełną specyfikację tego, co pojawiło się wraz z nowym wydaniem. Nie będę tutaj zanudzał Was tym, do czego generyki służą – dla tych którzy nie kojarzą konceptu, za pomocą typów ogólnych (bo tak to się powinno chyba tłumaczyć) można deklarować i używać funkcje, które są napisane do pracy z dowolnym zestawem typów dostarczonych przez wywołanie kodu (np. kolekcja dowolnych elementów, niezależnie od tego czy przechowywany jest w niej String czy Int, zawsze należy istnieć możliwość dodania nowego elementu). W składni języka wygląda to zaś następująco:
func Print2Same[T any](s1 []T, s2 []T) { ... }Oczywiście, koncept jest bardzo zniuansowany (jak w każdym języku), także jeśli realnie myślicie o pobawianiu się całością, zachęcamy do zapoznania się z min. oficjalnym tutorialem.
Go 1.18 to jednak nie tylko generyki, ale także tak zwany fuzzing, którego Go (jak chwalą się twórcy) zaimplementowało w “standardzie” jako pierwszy duży język programowania. Fuzzing to rodzaj automatycznego testowania, który w sposób ciągły manipuluje danymi wejściowymi programu w celu znalezienia błędów. Można je rozumieć jako rodzaj “chaos testów” dla kodu źródłowego – ponieważ fuzzer może dotrzeć do skrajnych przypadków, które ludzie często przeoczają, testy fuzz mogą być szczególnie cenne przy znajdowaniu min. luk w zabezpieczeniach. Fuzzing w Go jest inteligentny i został zaimplementowany tak, aby inteligentnie przejść przez fuzowany kod i nie zgłaszać nadmiarowych błędów. Oczywiście, magii nie ma, i żeby całość mogła działać niezbędne jest napisania odpowiedniego przypadku testowego – przykład znajdziecie poniżej:
Dobra, to kto się przekwalifikuje na programistę Go?
Źródła
- Go 1.18 Release Notes – The Go Programming Language
- Type Parameters Proposal
- Go Fuzzing – The Go Programming Language
- Tutorial: Getting started with generics – The Go Programming Language
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
2. node-ipc przeprowadza atak typu Supply-Chain na programistów z Rosji i Białorusi
Ja już naprawdę nie chciałem dzisiaj wprowadzać tematów związanych z wydarzeniami za naszą wschodnią granicą, ale trochę się nie da – kazus modułu peacenotwar jest zbyt niezwykłym zjawiskiem, żeby o nim nie napisać. Rozważałem umieszczenie go już w ramach pisanego przeze mnie w tym tygodniu (gościnnie) Frontendowego Czwartku, ale stwierdziłem, że choć temat dotyczy JS, to jednak należy mu się trochę szersza publika.
W zeszłą środę doszło bowiem do ataku typu supply-chain na użytkowników jednego z największych frameworków JavaScript – Vue.js. Vue używa zależności na pakiet node-ipc, a jego twórca postanowił wyrazić swoje “niezadowolenie” z sytuacji na świecie poprzez dorzucenie do kodu pakietu peacenotwar. Ten po zaimportowaniu jako zależność i uruchomieniu przez projekt, sprawdzał, czy komputer hosta miał adres IP w Rosji lub na Białorusi, a jeśli tak, nadpisywały każdy plik, jaki mógł, symbolem serca. Wersja żyła wyjątkowo krótko, a kolejna tworzyła już tylko dodatkowe pliki na dyskach użytkowników z przekazem antywojennym. Jak donosi portal snyk.io, który stworzył timeline całego incydentu, lista zaatakowanych aplikacji raczej nie należy do długich. Nadal mieliśmy jednak do czynienia z incydentem, który w skali CVE otrzymał prawie maksymalną ocenę 9.8.
Autor zarzeka się w dokumentacji, że pakiet peacenotwar był podobno stworzony w celu uświadomienia wszystkim, jak bardzo niebezpieczny potencjał mają ataki Supply Chain (stąd też od początku sam ograniczał jego skuteczność). Społeczność nie doceniła jednak tej formy edukacji, wręcz zalewając projekt zgłoszeniami, sukcesywnie teraz czyszczonymi przez autora, któremu cała sytuacja wybuchła chyba trochę w twarz. Ciężko jest naprawdę bronić jego decyzji – od dawna mówi się bowiem, jak niestabilny jest tak zwany łańcuch dostaw współczesnego oprogramowania, a tego typu działania tylko dodatkowo podkopują jego wiarygodność, rzutując na całą społeczność programistyczną.
Źródła
- peacenotwar – npm
- Malicious Package in node-ipc | CVE-2022-23812 | Snyk
- Alert: peacenotwar module sabotages npm developers in the node-ipc package to protest the invasion of Ukraine | Snyk
- https://github.com/RIAEvangelist/node-ipc/issues?q=is%3Aissue+is%3Aclosed
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Fuchsia OS publikuje model komunikacji międzyprocesowej
A na koniec będzie o Fuchsii, czyli jednym z ciekawszych projektów technologicznych ostatnich lat.
Ciągle pamiętam, jak parę lat temu (Wikipedia przywołuję tu datę Sierpnia 2016, a ja im wierzę), nagłówki prasowe obiegła informacja o tym, że Google pracuje nad nowym systemem operacyjnym, który w przyszłości zastąpić ma Androida. Obok Chrome OS był to już drugi eksperyment tego typu ze strony Alphabetu, ale to, co rozbudza wyobraźnie to porzucenie kernela Linuxowego, na rzecz Zircona, który należy do tak zwanych mikrokerneli – rodzajem projektu jądra, kontrastującym z jądrem monolitycznym. W jądrze monolitycznym, jak sama nazwa wskazuje, całe jądro jest pojedynczym programem, który implementuje wszystkie niezbędne API (np. wywołania systemowe Unix, wątki, procesy, system plików itp.). W mikrokernelach bazą jest zaś bardzo małe jądro, które implementuje minimalne API (np. bardzo podstawową koncepcję wątków wykonania, uprawnień i przekazywania wiadomości), do którego dokładane są kolejne API, których potrzebują aplikacje – rzeczywisty system plików, procesy czy wywołania systemowe. Dzięki temu zdaniem Google nadają się idealnie jako lekki, uniwersalny system operacyjny dla sprzętów napędzanych przez Google Assistant.
Fuchsia od tamtej pory trafiła na Google Nest (próbowałem, trochę ¯\_(ツ)_/¯, jak jesteście ciekawi jak to wygląda w praktyce – nagranie z testów od 9to5Google), dostała zapowiedź wsparcia dla Fluttera, a początkiem marca tego roku ogłoszono też, że system operacyjny jest w stanie odpalać przeglądarkę Chrome – ogólnie dzieje się. Bezpośrednią zaś motywacją zrobienia Wam aktualizacji w tym temacie było zaś udostępnienie standardu komunikacji międzyprocesowej o nazwie FIDL (Fuchsia Interface Definition Language). W FIDL dostępna jest zarówno synchroniczna, jaki asynchroniczna komunikacja między procesami (jej różne tryby zostały dokładnie opisane w linkowanym standardzie), a interoperacyjność między różnymi językami programowania zapewniona została przy użyciu plików .fidl, które definiują protokół – ich format przypomina mi trochę Smithy’ego od Amazona. Na podstawie rzeczonych plików, generowane mają być odpowiednie klienckie biblioteki do języków programowania – na ten moment wspierane jest C, C++, Go, Dart i Rust, ale zapowiedziano już wsparcie choćby dla Javy i JavaScripta (bo jakżeby inaczej).
A jak już przy systemach operacyjnych jesteśmy – mam dla Was świetny podcast od CoRecursive na temat powstawania Serenity OS. Jest to system operacyjny pisana przez jedną (!) osobę, łącząca estetykę lat 90-tych i nowoczesne podejście do tego typu oprogramowania. Jeśli zaś ciekawi Was, jakie motywacje mogą kierować kimś, kto chce stworzyć własny system operacyjny, to okazuje się, że jednym z nich może być choćby… walka z uzależnieniem od narkotyków. Serenity OS to naprawdę fascynująca historia, dlatego jeszcze raz polecam odsłuchanie tego, oraz innych odcinków CoRecursive – jest to mój ulubiony podcast o programowaniu.
Z jakiegoś powodu mój mózg dostaje szału, gdy widzę powyższego screena
Źródła
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
