Jak nie zainstalowałem Google Hangouts w Debianie Wheezy

Z własnej nieprzymuszonej woli bym z Google Hangouts nie skorzystał, bo jeśli już muszę korzystać z niewolnych wynalazków, to mam Skype od Microsoftu, ale w pracy była potrzeba skontaktowania się grupowo, grupa już ma wybrane rozwiązanie i używa Hangouts, więc… co może pójść źle? System to Debian Wheezy plus backporty, czyli nic nietypowego czy niestabilnego. Skype od Microsoft daje gotową paczkę deb, co prawda multiarch, a nie natywne amd64, ale działa bez problemu, po dodaniu architektury i386. Google ma opinię firmy bardziej przyjaznej Linuksowi, poza tym na rynek weszli później, więc pewnie bardziej się starają.

Oczywiście wszedłem na stronę Google Hangouts z Iceweasel, czyli Firefoksa. Są wersje dla mobilków, jest pobierz na swój komputer. Klikam… i komunikat, że ta przeglądarka się nie nadaje, pobierz sobie Chrome. Czyli nie wersja Hangouts na komputer, tylko jako dodatek do przeglądarki. Pod pewnymi względami może to mieć nawet sens, zresztą mam Chromium (opensource’owa wersja Chrome), co mi szkodzi wrzucić tam Hangouts? Odpalam Chromium, strona Google Hangouts i… link do wersji „stacjonarnej” nie jest aktywny.

No dobrze, wiem, że dają działającą paczkę z Chrome, więc chociaż nie potrzebuję tej przeglądarki, to mogę ją zainstalować i tylko do tego jednego celu mogę jej używać. Instalacja Chrome bez problemu (nie, nie będzie domyślną przeglądarką w systemie…), wchodzę na stronę Hangouts, dodał appkę. Uruchamiam i… chat działa, ale w momencie kliknięcia rozmowy video (znaczy audio/video, samego audio chyba się nie da, choć by wystarczyło…) nie uruchamia jej w Chrome, tylko… próbuje uruchomić w Iceweasel, który jest domyślną przeglądarką. Tym razem jednak proponuje pobranie pluginu w postaci paczki deb. Nie można tak było od razu? Pobieram oferowany plugin, instaluję i…

dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie pakietu google-talkplugin:
google-talkplugin zależy od libc6 (>= 2.14); jednakże:
Wersją libc6:amd64 w systemie jest 2.13-38+deb7u8.

Brawo Google!

Źródło: http://gifrific.com/wp-content/uploads/2012/04/joker-clap-hq.gif

Oczywiście problemu pewnie by nie było, gdyby Chrome był domyślną przeglądarką w systemie, ale nie ze mną te numery, Brunner^HGoogle. Skończyło się odinstalowaniem i Chrome, i nieszczęsnego pluginu na podstawowym systemie. Oczywiście za tydzień problemu pewnie nie będzie, bo najprawdopodobniej Jessie będzie stable, ale póki co – nie da się w rozsądny sposób korzystać z Hangouts pod stabilnym Debianem.

Oczywiście z tym nie zainstalowałem z tytułu lekko przesadzam[1], bo nie kijem go, to pałką i skończyło się szybkim postawieniem osobnej wirtualki (AQEMU, KVM) tylko pod Hangouts. Ale faktem jest, że w podstawowym systemie poległem.

Pozytyw całej akcji jest taki, że przetestowałem instalator Jessie (rc2). Jest parę fajnych opcji, choćby wybór, które dokładnie środowisko chcemy zainstalować (jest LXDE i działa w zasadzie od kopa – jedyna rzecz, która wymagała interwencji to wyciszony mikrofon – musiałem doinstalować jakiś xfce4-mixer, który chyba zresztą jakoś nie zapamiętuje ustawień. Potem się przyjrzę dokładniej, podobnie jak udostępnieniu wbudowanej kamery do wirtualki…

[1] Pierwotnie w tytule nie było nic o wersji Debiana.

Jakość niektórych narzędzi security Linuksie

Był sobie ciekawy wpis dotyczący siły haseł i narzędzi do automatycznego jej sprawdzania. Szykowałem się do dokładniejszej zabawy i testów, ale jakoś się rozeszło po kościach, więc krótko o tym, co zauważyłem.

Wnioski na temat jakości narzędzi do generowania haseł i automatycznego sprawdzania nie są zbyt optymistyczne. Narzędzia do haseł mają błędy. Smutne błędy. Spójrzmy na następujące wynik dotyczące haseł wygenerowanych przez pwgen i sprawdzanych cracklib-checki. Za każdym razem generowane było 100 tys. haseł, o zadanej długości (poczynając do 10 i kończąc na 20). Liczba podaje, ile nie było OK wg cracklib-check.

LANG=C pwgen -s -1 10 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
79LANG=C pwgen -s -1 11 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
122LANG=C pwgen -s -1 12 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
16LANG=C pwgen -s -1 13 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
27LANG=C pwgen -s -1 15 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
59LANG=C pwgen -s -1 16 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
98LANG=C pwgen -s -1 17 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
141LANG=C pwgen -s -1 18 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
215LANG=C pwgen -s -1 19 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
275LANG=C pwgen -s -1 20 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
373

Jak widać, ilość słabych haseł spada, osiągając minimum w okolicy dwunastoznakowych, by następnie systematycznie rosnąć. Rzut oka na generowane hasła i… wszystko jasne:

HiGFYedy6gHG: it is too simplistic/systematicnowuTUtOon4W: it is too simplistic/systematicO4rstUX43Bef: it is too simplistic/systematic1mMTsIHZyHIH: it is too simplistic/systematicSeVw3MnMnOpp: it is too simplistic/systematic

Domyślnie(?) cracklib-check uznaje powtórzenie znaków za oznakę słabego hasła. Kurtyna.

Kolejne narzędzie, które znam, lubię i którego używam często (zwykle modyfikując wynik, jednakowoż) to gpw. Okazuje się, że posiada ono brzydki błąd, który powoduje, że czasami hasło nim wygenerowane jest krótsze, niż planowaliśmy, tj. niż podane w stosownym parametrze. Przykład: 100 tys. haseł szesnastoznakowych (niby!):

gpw 100000 16 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -v ': OK' | grep -i shortaqs: it is WAY too short

I hasło typu aqs. Jest nawet zgłoszony błąd w Debianie w tej sprawie. Też mam mieszane uczucia co do poziomu istotności błędu, ale… sprawdzanie długości otrzymanego wyniku to przecież trywialna sprawa, więc jakie inne błędy może mieć soft?

Ogólnie: mam wrażenie, że nie warto zbytnio ufać gotowym narzędziom. Może nawet nie to, żeby od razu pisać coś własnego, ale warto sprawdzić gotowce (bezpieczne! wolnoźródłowe!), nim się z nich skorzysta.

Powtarzalne budowanie pakietów w Debianie

Dyskusji nt. zgodności pakietów binarnych z dostarczanymi źródłami teraz nie znajdę (podrzucenie mile widziane), ale Półtora roku temu pisałem o braku weryfikacji, czy kod źródłowy jest zgodny z wersją binarną. Pamiętam, że w różnych dystrybucjach wyglądało to różnie, a chyba w żadnej dobrze. IIRC na testowanym pakiecie różnice w Debianie były minimalne, bo dotyczyły tylko timestampu ale… były. W praktyce dla użytkownika końcowego oznacza to brak możliwości łatwego zweryfikowania, czy dostarczony (bardziej: deklarowany) kod źródłowy odpowiada dostarczonej wersji binarnej pakietu[1].

Implikacje są oczywiste: możemy uruchamiać co innego, niż sądzimy, że uruchamiamy. Z jednej strony może dojść do naruszenia licencji (zwł. GPL) i użytkownik może mieć problemy z modyfikacją oprogramowania, z drugiej, bardziej praktycznej: mogą pojawić się problemy z bezpieczeństwem. Nie tylko developer może dołożyć coś od siebie (developerom ufamy),. Także atakujący może w wyniku włamania przejąć klucze jakiegoś developera i wprowadzić zmodyfikowaną wersję binarną pakietu do repozytorium.

Wiadomo, że dokładna i systematyczna kontrola podstawą zaufania, w związku z tym w Debianie ogłoszono projekt Reproducible Builds. Ma on na celu dostarczenie narzędzi i środowisk do kontroli. Oraz poprawę pakietów tak, aby można było w prosty sposób sprawdzić zgodność pakietu binarnego ze źródłem. Czyli każdy będzie mógł łatwo odpowiedzieć na pytanie: czy dany pakiet powstał z deklarowanego źródła?

Projekt dotyczy raczej przyszłych wersji Debiana, ale na pewno jest krokiem w kierunku zwiększenia wolności użytkowników i bezpieczeństwa.

Wg danych projektu Reproducible Builds w chwili obecnej udało się potwierdzić powtarzalność budowy ponad 83% pakietów z repozytorium main dla Debiana unstable.

[1] Nie miejsce na dyskusję nad wyższością dystrybucji pakietów w źródłach nad wersją binarną i odwrotnie.