Wszyscy piszą dziś o Facebooku, to my też. Ale jeśli jesteście znudzeni tematem wczorajszej awarii (do tej wrócimy sobie w sobotę, jak opadnie kurz po bitwie), to mamy dla was facebookowy linter. A także informacje o zmianach w WildFly oraz zmianie domyślnego kodowania Javy.
1. “Rów Mariański” – linter security od Facebooka 🚓
Zacznijmy od Facebooka. Jego wczorajszą wielką awarią zajmiemy się w najbliższą sobotę (już powoli zbieramy materiały tłumaczące, co tak naprawdę się wydarzyło), a w międzyczasie chcielibyśmy powiedzieć o firmie Marka Zuckerberga coś pozytywnego (nie kopie się w końcu leżącego). Ot, choćby to, że podzieliła się ze społecznością nowym narzędziem do analizy statycznej kodu pod względem luk bezpieczeństwa.
Mariana Trench, bo tak nazywa się owy tool, nie powstawał w próżni. Jest on kontynuatorem linii podobnych narzędzi przeznaczonych odpowiednio do Hacka i Pythona, a jego celem jest wsparcie procesu review kodu źródłowego pod względem potencjalnych podatności ukrytych w sposobach, w jakich dane przepływają przez aplikację.
Wspomniany przepływ danych w MT jest opisany przez źródło (source) oraz ujście (sink). Zadaniem “rowu mariańskiego” (jak pięknie spolszcza się nazwa narzędzia) jest wykrycie wszystkich możliwych kombinacji takowych (używa on do tego metody zwanej interpretacją abstrakcyjną). Trochę jak w narzędziach typu ArchUnit, twórcy aplikacji określić mogą, w jaki sposób np. dane osobiste trafiają do systemu i gdzie ostatecznie mogą się znaleźć (np. baza danych), a gdzie nie (np. logi albo data lake). Wadą procesu jest to, że powoduje na ten moment spore ilości “fałszywych pozytywów”, ale autorzy narzędzia zarzekają się, że po odpowiednim tuningu można dojść do rozsądnego poziomu. Zysk z szybkiego wykrycia wycieków danych w tym przypadku znacznie przewyższa, według nich, pewnie manualne kroki.
Co prawda, inżynierowie z Facebooka “reklamują” użycie Mariana Trench głównie w zastosowaniach mobilnych, ale samo narzędzie jest mocno elastyczne – można je stosować w większości aplikacji javowych. I chyba warto – sam Facebook chwali się, że ponad połowa luk bezpieczeństwa wykrytych w 2021 wyłapana została właśnie przez analizę statyczną.
Źródła
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. Duże zmiany w serwerze aplikacyjnym WildFly 🪳
To teraz czas na obowiązkowy kącik Javy EE. W dzisiejszym odcinku – WildFly.
Twórcy tego jednego z najważniejszych serwerów aplikacyjnych zapowiedzieli duże zmiany dla projektu. Tak jak JDK 17 dokonał deprekacji wsparcia dla Security Managera, tak twórcy WildFly chcą, aby w jego 25. wersji domyślną warstwą bezpieczeństwa stał się WildFly Elytron, czyli wprowadzona kilka lat temu (w WildFly 11) nowocześniejsza warstwa bezpieczeństwa. Co prawda Elytron od dawna był rozwiązaniem zalecanym, o tyle do tej pory zapewniana była pełna kompatybilność ze starszymi metodami, mającymi swoje korzenie jeszcze w pierwszych wydaniach JBossa. Okazuje się jednak, że usunięcie Security Managera namieszało również w świecie WildFly i niemożliwym jest utrzymanie wsparcia dla starego rozwiązania, opartego właśnie na zdeprawowanej funkcjonalności Javy. Po raz kolejny objawia się, jak dużym problemem dla kompatybilności wstecznej (a może szansą na pozbycie się jej?) były zmiany przyniesione przez ostatnie wydanie JDK.
Oprócz powyższego, zapowiedziano również przymiarki do wsparcia Jakarty EE 10. To ma nastąpić prawdopodobnie początkiem przyszłego roku, a twórcy ostrzą sobie zęby już, aby “dziesiątka” była główną gwiazdą wydania WildFly 28. Co jednak nawet ważniejsze, prawdopodobnie oznaczało to będzie całkowitą rezygnację ze wsparcia Jakarta EE 8. Wyrok jeszcze nie zapadł, ale możliwość pozbycia się całego historycznego namespace javax.* jest czymś nad wyraz kuszącym.
To jednak nie jedyna “ósemka”, której wsparcia twórcy chcą się pozbyć, Rozważają też powoli odcięcie się od JDK 8. Jeżeli zdecydowaliby się na ten krok, mielibyśmy do czynienia z kolejnym kluczowym dla ekosystemu projektem, który postawił krzyżyk na Java SE 8.
Źródła
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. Wraz z JDK 18, UTF-8 staje się domyślnym kodowaniem znaków ⌨️
A na koniec – JEP o bardzo ładnym, okrągłym numerze 400. Wprowadza on wreszcie UTF-8 do Javy domyślny sposób kodowania znaków.
Pewnie młodsi stażem programiści czytający to opracowanie mogą nie pamiętać tych czasów, ale kiedyś kwestia kodowania znaków w dokumentach nie była oczywista. Dwa standardy, walczyły o dominację rynkową. Do tego wszystkiego dokłada się jeszcze Windows, który to posiadał własny, osobisty “standard”. W tym świecie, używanie np. polskich znaków nie było czymś oczywistym, a Grzegrzółka była najlepszym przyjacielem dewelopera.
Dzisiaj żyjemy w trochę innych czasach – dekodowanie znaków wydaje się być rozwiązanym problemem. Globalizacja (i po części też rozwój hardware) sprawiły, że zamiast wielu lokalnych standardów mamy obecnie jeden – Unicode Transformation Format, czyli popularny UTF, potrafiący reprezentować znaki z wszystkich języków i dialektów, a dodatkowo wiele więcej, jak kochane przez wszystkich emoji. W związku z faktem, że wiele języków programowania postanowiło już dawno uczynić go rozwiązaniem domyślnym, na podobny krok zdecydowała się również Java. Od wydania 18 (które to zobaczymy w marcu), domyślną wartością kodowania znaków będzie UTF-8, a nie (jak dotychczas) default systemowy.
Opublikowany z tej okazji artykuł na inside.java przeprowadza czytelnika przez potencjalne problemy, jakie mogą z tego powodu nastąpić i pokazuje, w jaki sposób dokonać udanej migracji. Jeśli chcecie się upewnić, czy wspomniana zmiana nie wpłynie na Was negatywnie – zachęcam do lektury.
Źródła
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
