Wieści ze świata Open Source: 9  – 15 października 2012

Czy wiecie, że mamy Firefoksa 16? Ja, szczerze mówiąc przestałem już liczyć kolejne wydania tej przeglądarki. Ciągle uważam, że przyspieszenie cyklu rozwojowego było świetnym krokiem z strony Mozilli, ale… Po prostu kiedyś kolejne wydania były wielkim świętem, teraz to zmiana numeracji. Niestety, tym razem Mozilla zaliczyła falstart.

Mozilla Firefox 16

Na początek dobre wieści – zgodnie z zapowiedziami nowy Ognisty Lisek ma znacznie mniejszy apetyt na pamięć operacyjną. Deweloperom udało się znacznie zredukować ilość alokowanego RAM-u. Najbardziej jest to widoczne przy dużym użyciu przeglądarki (wiele okien, wiele kart). Ciągnące się od czasów wersji 4 wycieki pamięci potrafiły doprowadzić do kuriozalnych sytuacji, gdzie przeglądarka wykorzystywała ponad jeden gigabajt RAM-u bez wyraźnej przyczyny tego stanu rzeczy.

Zaraz po wydaniu wersji 16 odkryto dosyć poważny błąd w zakresie zachowania prywatności. Odpowiednio spreparowana strona internetowa mogła wyciągnąć z przeglądarki całą historię odwiedzanych stron. Dla „szpeców” od SEO i spamerów jest to wiedza na wagę złota. Lukę odkryto wkrótce po premierze  szesnastki i wycofano tę wersję z serwerów. Obecnie dostępna jest już wersja 16.0.1, w której załatano tę podatność.

Źródła
Mozilla.org (1,2)

Plany Linux Fundation co do Secure Boot

Secure Boot to fajna technologia. Gorzej ze sposobem jej promowania i końcową implementacją. O problemach z tym ostatnim pisałem już wielokrotnie na łamach Poniedzielnika. Od ponad roku trwają prace nad sensownym (czyli strawnym dla zwykłego użytkownika) sposobem na zainstalowanie Linuksa na nowym sprzęcie. Do tej pory wyglądało na to, że wszyscy postawią na tak zwane „rozwiązanie Fedory”. Zarówno Red Hat jak i Canonical zamierzało wykupić klucz od Microsoftu (zgodnie z obecną polityką to osiemdziesiąt kilka dolarów) i dodać go do GRUB-a ochrzczonego kilkoma patchami.

Temu rozwiązaniu daleko do idealnego. Działa, ale tylko na systemach z wykupionym kluczem. Wszystkie inne mini dystrybucje pozostałyby na lodzie, nie wspominając już o wszystkich ludziach pałających szczerą nienawiścią do GRUB-a, w szczególności jego nowych wydań (a powody mają słuszne). I tych, co kompilują własne kernele.

Parę dni temu Fundacja Linuksa zaproponowała własne rozwiązanie. Też wykupią klucz od Microsoftu i tez umieszczą go w własnym mini-bootloaderze o nazwie efitools. Ten będzie startował i współpracował z firmware urządzenia w dziedzinie Secure Boot. Kiedy wszystko będzie w porządku przeskoczy do przodu i zbootuje docelowy bootloader – czy to GRUB, czy to LILO czy jakiś inny.

Zaletą tego rozwiązania jest to, że efitools jest naprawdę mini i nie stwarza żadnych problemów. Można go użyć w dystrybucjach typu live-cd / rescue cd. Nie będzie obciążeniem dla deweloperów stojących za miniaturowymi dystrybucjami, takimi jak Tiny Core Linux. Nie będzie stwarzał problemów przy zastosowaniu niestandardowych kompilacji kerneli czy własnych modułów jądra.

Jest jednak jedna zasadnicza wada. Używanie takiego bootloadera wypacza stosowania mechanizmu Secure Boot. Nie będzie on sprawdzał, czy kolejny bootloader nie został skompromitowany. Nie zabezpieczy także przed podmianą kernela w trakcie pracy systemu (tzw. kexec) czy załadowaniem niepodpisanych modułów do jądra. W skrócie, jest to obejście mechanizmu Secure Boot. Systemy tak pracujące będą działały tak jak SB było wyłączone. Rozwiązania proponowane przez Fedorę i Ubuntu pozwalają w pełni korzystać z Secure Boot, bez pozostawiania otwartej luki.

Chociaż nie zrozumcie tego źle – nie używanie Secure Boot nie oznacza, że nagle wszystkie komputery zostaną „zhakierowane”. Tak naprawdę, aby skorzystać z takiej „dziury” trzeba jakoś zdobyć uprawnienia roota (przynajmniej pod Linuuksem i różnymi Uniksami). A z tym, bez zastosowania socjotechnik, nie jest już tak różowo.

Matthew Garrett (jeden z głównych deweloperów linuksowego kernela, pracuje dla Red Hat) ostro skrytykował takie podejście Linux Fundation. Jego własne rozwiązanie (Shim) umożliwia także mniejszym dystrybucjom podpisywanie swoich systemów używając klucza wykupionego przez Red Hat. Z tą różnicą, że dla przeciętnego użytkownika ta metoda jest znacznie mniej przyjazna. Efitools poinformuje użytkownika o wyłączeniu Secure Boot i poprosi o potwierdzenie. Shim wymaga aby użytkownik wskazał w systemie plików plik z kluczem, następnie zrestartował komputer i dopiero wtedy prawidłowo zbootował swój system. Oczywiście dotyczy to tylko niszowych dystrybucji, gdyż główne (Fedora, Suse, Ubuntu) pozbawione będą takich niedogodności.

Źródła:
Ogłoszenie Linux Fundation
Blog Garreta

W skrócie

Ubuntu 32 czy 64 bit? Oto kilka powodów za wersją 64-bitową. A jednocześnie kilka przeciw.

Pojawił się ciekawy patch dla kernela: Boottime. Ma on umożliwić lepszą kontrolę nad tym co się dziele w czasie bootowania systemu (zamiast mocno nieczytelnego Bootchart).

Ministerstwo Edukacji Narodowej potwierdza – e-podręczniki będą darmowe i udostępnione na wolnej licencji.

Źle się dzieje w świecie MySQL. Bardzo ciekawy felieton na dobrychprogramach.