mrk's techblog

ChromiumOS + binarne sterowniki NVidia

Sun, 06 Dec 2009 02:16:15 +0100

Po ładnych kilku wieczorach "walki" udało mi się wreszcie zbudować ChromiumOS działający natywnie na moim T61. Przede wszystkim dorzuciłem binarne sterowniki NVidia, dzięki czemu działa Composite i te wszystkie EyeCandy w WM. Zmieniłem też podział na partycje, by system można było zmieścić na nośniku 1GB (700MB/rootfs i 250MB/partycja rw, brak swap zamiast 950MB/rw, 950MB/swap i 950MB/rootfs).

W związku ze zmniejszeniem rootfs wyleciał bootchart + zależności, zwalniając 180MB miejsca, natomiast przybył mój ulubiony edytor joe ;) W xorg.conf dodałem polski układ klawiatury.

Odświeżona została także przeglądarka chromium - przedwczorajszy build r33883

Ponadto został włączony użytkownik pozwalający na zalogowanie offline: testuser, hasło: qwerty - można dzięki temu pogrzebać trochę w systemie:

sudo mount / -o remount,rw

Skompresowany obraz dysku usb dostępny via ~~torrent~~ oraz http (175MB) - ~~czywiście preferowany torrent :)~~

Ściągnięty obraz można zapisać na pendrive (w tym przypadku /dev/sdb) za pomocą:

bzcat usb.img.bz2 > /dev/sdb

contains binary NVidia xorg driver, ver. 185
system is repartitioned, fits on 1GB Flash memory (smaller rootfs, no swap, small rw partition)
fresh build on latest sources (chromium browser: r33883)
local user: testuser, password: qwerty

Download compressed usb flashdisk image (185MB) via ~~torrent or~~ http

Instalation (assuming pendrive device is /dev/sdb)

bzcat usb.img.bz2 > /dev/sdb

Uwierzytelnianie do Apache'a za pomocą certyfikatów kwalifikowanych

Mon, 02 Nov 2009 16:06:01 +0100

Mając do dyspozycji certyfikat kwalifikowany, chciałem użyć go do silnego uwierzytelniania do serwisu www. Nie spodziewałem się większych problemów, jednak okazało się, że sprawa nie jest taka prosta jak się na początku wydawało - i stąd ta notka.

Nie będę pisał o samym uwierzytelnianiu za pomocą certyfikatów klienta - w sieci napisano na ten temat sporo. Skupię się na problemach specyficznych dla polskich certyfikatów kwalifikowanych.

Po pierwsze, apache musi mieć ustawiony certyfikat Narodowego Centrum Certyfikacji za pomocą dyrektywy SSLCACertificateFile lub SSLCACertificatePath w pliku konfiguracyjnym. Certyfikaty można pobrać stąd. Po restarcie apache'a w logach SSL'a na poziomie debug powinniśmy mieć informację:

[debug] ssl_engine_init.c(1092): CA certificate: /C=PL/O=CZiC Centrast SA w imieniu Ministra Gospodarki/CN=CZiC Centrast SA
[debug] ssl_engine_init.c(1092): CA certificate: /C=PL/O=Minister wlasciwy do spraw gospodarki/CN=Narodowe Centrum Certyfikacji (NCCert)
[

Pierwszy problem - na początku żadna ze sprawdzanych przeze mnie przeglądarek nie chciała użyć (zaprezentować) certyfikatu serwerowi, pomimo, że był widoczny dla samej przeglądarki (pod IE jako certyfikat osobisty w Opcje internetowe / Zawartość / Certyfikaty, w FF Opcje/zaawansowane/szyfrowanie/certyfikaty).

W FF sprawa okazała się prosta - wystarczyło zarejestrować w przeglądarce certyfikaty wystawców (CA). W IE niestety to nie pomogło - przeglądarka pokazywała listę wyboru certyfikatu, ale pustą. Przyczyna, dla jakiej IE ignorował certyfikat, okazała się dość poważna i miała mieć jeszcze dość poważne następstwa - mianowicie rozszerzenie KeyUsage, definiujące możliwości użycia klucza, w certyfikacie kwalifikowanym ma ustawiony jedynie bit nonRepudation, i nie ma ustawionego bitu digitalSignature, wymaganego m.in. do uwierzytelniania klienta. Trochę więcej przeczytać o tym można np. tutaj. W skrócie - bit nonRepudation ustawiony w KeyUsage - określa użycie certyfikatu (a dokładniej klucza prywatnego) do typowego podpisu elektronicznego pod dokumentem, czyli w celu potwierdzenia "niezaprzeczalności" Natomiast bit digitalSignature zezwala użycie klucza w pozostałych przypadkach, m.in. w celu uwierzytelnienia w systemie informatycznym. Takie rozdzielenie ma sens, jeśli chodzi o zapewnienie większego bezpieczeństwa użycia naszego podpisu elektronicznego - bez tego mechanizmu można sobie wyobrazić "zły" serwer, który przy okazji uwierzytelniania klienta za pomocą certyfikatu klienta podsyła nam zamiast losowych wartości challenge skróty jakichś dokumentów, które byśmy nieświadomie podpisywali naszym e-podpisem...

Okazuje się, że w IE można jednak wymusić użycie certyfikatu bez bitu digitalSignature w KeyUsage do autoryzacji klienta, aplikując do rejestru:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl]
"FEATURE_CLIENTAUTHCERTFILTER"=dword:00000001

Po zaaplikowaniu powyższego wpisu do rejestru IE powinien pozwolić na wybranie certyfikatu kwalifikowanego do uwierzytelniania.

Niestety, pomimo że zarówno FF jak i IE pozwalały wybrać certyfikat, Apache dalej odmawiał posłuszeństwa. Dalsze śledztwo wykazało, że z dwóch powodów. Po pierwsze - brak bitu digitalSignature w KeyUsage - Apache honoruje to rozszerzenie i odrzuca certyfikaty klienta nie mające ustawionego bitu digitalSignature. Po drugie - Apache odrzuca certyfikaty mające nieznane rozszerzenia oznaczone jako "krytyczne" - a posiadany przeze mnie certyfikat kwalifikowany takowe posiadał. Rozwiązanie - poniższy patch, powodujący ignorowanie powyższych błędów.

--- apache2-2.2.8/modules/ssl/ssl_engine_kernel.c.orig  2006-07-12 05:38:44.000000000 +0200
+++ apache2-2.2.8/modules/ssl/ssl_engine_kernel.c       2009-10-28 17:19:26.000000000 +0100
@@ -1285,6 +1285,16 @@
     /*
      * And finally signal OpenSSL the (perhaps changed) state
      */
+
+    if(errnum == X509_V_ERR_UNHANDLED_CRITICAL_EXTENSION || errnum == X509_V_ERR_INVALID_PURPOSE) {
+      ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, "ignoring unhandled critical extension or invalid certificate purpose");
+      sslconn->verify_error = NULL;
+      ctx->error = X509_V_OK;
+      SSL_set_verify_result(ssl, X509_V_OK);
+      ok = TRUE;
+    }
+
+
     return ok;
 }

Powyższy patch nie jest chyba zbyt dużym gwałtem na bezpieczeństwo apache'a - powyższy kod wywoływany jest tylko dla certyfikatów klienta, ignorowane są jedynie nieznane rozszerzenia w certyfikacie i rozszerzenie KeyUsage

Konkluzja - certyfikatów kwalifikowanych niestety nie powinno używać się do uwierzytelniania klienta via SSL ale jak ktoś się wyjątkowo uprze to się da :)

I na koniec KONKURS. Tutaj stoi sobie poprawiony j.w. apache, wpuszczający tylko za okazaniem certyfikatu kwalifikowanego. Pierwszej osobie która powie w komentarzu co znajduje się na podanej stronie stawiam piwo :)

GParted - zmiana rozmiaru partycji NTFS zawierającej bad sektory

Sat, 24 Oct 2009 15:28:21 +0200

Podczas próby zmniejszenia partycji ntfs, gparted zaskoczył mnie komunikatem:

Jak widać współpracy odmówił program ntfsresize, ponieważ znalazł 'zamarkowane' bad sektory. Rozwiązanie - mały wrapper na ntfsresize, który wywoła oryginalną binarkę z opcją "--bad-sectors":

#!/bin/bash
if test "$#" -gt 0; then
  exec ntfsresize.orig --bad-sectors "$@"
else
  exec ntfsresize.orig
fi

Zmieniamy nazwę oryginalnego ntfsresize na ntfsresize.orig, a powyższy kod umieszczamy w tym samym katalogu w pliku ntfsresize, nadając mu oczywiście atrybuty wykonywania. Przed operacją zmiany rozmiaru warto jeszcze wykonać spod Windows "chkdsk /r /p", jak zresztą ntfsresize lojalnie nas uprzedza.

Skryptozakładka do logowania via Google OpenID

Mon, 13 Jul 2009 11:47:19 +0200

Jak wiadomo, implemetacja OpenID google nie jest najłatwiejsza w użyciu. Google używa tzw. "Directed Identity" z OpenID 2.0 - do logowania używany jest ten sam dla wszystkich url, właściwy identyfikator OpenID użytkownika ustalany jest po uwierzytelnieniu u dostawcy OpenID. Identyfikator OpenID dla google to https://www.google.com/accounts/o8/id - jak widać średnio wygodny do zapamiętania i wpisywania. I właśnie dlatego powstała niniejsza skryptozakładka - szuka na stronie formularza logowania, ustawia identyfikator OpenID i wysyła formularz. Oczywiście można użyć dla dowolnego innego dostawcy OpenID, zmieniając URL.

Tutaj gotowa skryptozakładka: Google OpenID

A tak wygląda w bardziej strawnej postaci:

{geshi lang=javascript} (function() { var inputs=document.getElementsByTagName('input'); for(i=0;i=0) { var f = inputs[i]; f.value = 'https://www.google.com/accounts/o8/id'; while(f && f.tagName!='FORM') f=f.parentNode; if(f) f.submit(); return; } } alert('Brak formularza OpenID'); })(); {/geshi}

Skryptozakładka sprawdzona w FF3.5 i Chromium.

Zasilanie dysku SATA 2.5 ze złącza mini ATA - (44 pin)

Thu, 11 Jun 2009 16:28:19 +0200

Jakiś czas temu kupiłem uniwersalną "przejściówkę" ATA / mini ATA / SATA na usb. W komplecie znajduję się także zasilacz +5/+12V do zasilenia dysków 3.5" oraz dysków SATA - dyski ATA 2.5 cala nie potrzebują oddzielnego zasilania, ponieważ 4 dodatkowe piny na złączu mini ATA dostarczają zasilanie. I stąd pomysł, by zasilić 2.5" dysk sata ze złącza mini ATA

Uwaga - wskazana najwyższa ostrożność. Pomyłka grozi spaleniem dysku, przejściówki, portu USB w komputerze ew. puszczeniem z dymem całego komputera

Przerabiamy standardową przejściówkę do zasilania SATA: (przepraszam za niską jakość zdjęć - e51 nie nadaję się stanowczo do zdjęć makro)

Podłączamy ją do pinów 41 (+5V) i 43 (masa): (wyprowadzenia ATA 44)

Uwagi:

Najlepiej by było użyć pełnego złącza mini ATA 44pin, co uniemożliwiło by odwrotne podłączenie zasilania - niestety takim nie dysponowałem i dlatego podwójny gold-pin - trzeba mocno uważać by nie podłączyć zasilania dysku odwrotnie !
Dobrze zwrócić uwagę na zapotrzebowanie na prąd dysku - mój chce 0.6A, co nie jest wielkim nadużyciem w stosunku do standardu (0.5A / port) i nie powinno grozić przepaleniem ścieżek zasilających USB, ale zasilenie w taki sposób dysku 3.5" może skończyć się źle

Avatary na joggerze za pomocą mikroformatu hCard

Fri, 24 Apr 2009 13:37:55 +0200

Co to jest hCard? Jest to jeden z mikroformatów służący do publikowania informacji osobistych (wizytówki), między innymi fotografii (avatara) użytkownika. Mikroformat ten definiuje po prostu sposób zapisu informacji z popularnego standardu vCard za pomocą tagów HTML.

Listę site'ów które używają różnych mikroformatów można zobaczyć tutaj - znajdziemy tam takich potentatów jak digg, google, flickr, linkedin czy twitter.

Zgodną ze standardem wizytówkę można przygotować za pomocą generatora , minimalna, zawierająca tylko avatar wygląda tak:

{geshi lang=html4strict}

{/geshi}

Klasę "vcard" można odpowiednio udekorować za pomocą CSS, np. ukryć, jeżeli nie chcemy zdjęcia widocznego na stronie.

Na GAE powiesiłem małą usługę która szuka na podanej stronie pierwszej wizytówki w formacie hCard i przekierowuje do wyspecyfikowanego tam avatara, w przypadku braku do obrazka domyślnego. (keszując oczywiście dane, na razie tylko w memcache)

Potem wystarczy tylko odpowiednio udekorować komentarze pod wpisem, przykład w jQuery:

{geshi lang=javascript} $(document).ready(function() { $('.commentlist li').each(function(k,v){ url = $('cite a',v).attr('href') || 'anonim'; $(v).prepend('') }) }) {/geshi}

Zalety takiego rozwiązania? Zgodność z popularnym standardem, jest szansa, że tak przygotowaną wizytówkę będą w stanie automatycznie wykryć inne serwisy.

TODO:

Przeskalowywanie obrazków po stronie serwera, generowanie kilku rozmiarów miniatur

Ukrywanie niepożądanej historii w FF

Sat, 18 Apr 2009 20:44:04 +0200

Zaglądasz codziennie na pudelka, plotka czy inną naszą-klasę ;) i musisz tłumaczyć się potem kumplom z kompromitującej historii w firefoksie (eh ten awesome bar) ?

Rozwiązanie: trigger w sqlite o takiej postaci:

{geshi lang=sql} CREATE TRIGGER history_guard_trigger BEFORE INSERT ON moz_places WHEN new.url in ('http://pudelek.pl/', 'http://www.plotek.pl/') BEGIN select RAISE(ROLLBACK,'bez takich mi tu'); END {/geshi}

Wrzucić można za pomocą świetnego rozszerzenia SQLite Manager, baza 'places.sqlite', polecenie Execute SQL.

P.S. Tak, wiem, że jest niejedno rozszerzenie które daje podobną funkcjonalność, ale tak jest na pewno bardziej geekowsko ;) Poza tym takie rozwiązanie jest prawdopodobnie lżejsze niż instalowanie kolejnego rozszerzenia...

Zabawy blip api

Tue, 14 Apr 2009 19:52:28 +0200

Tutaj lekko zmodyfikowany Blip_er muzzy'iego - za pomocą kilku regexp'ów wstawiam linki do użytkowników, tagów, statusów i shortlinków. Aha, wymagane jQuery zamiast prototype. Demo po prawej.

Serwer OpenID dla Google Apps for Your Domain

Sun, 29 Mar 2009 17:39:47 +0200

Od jakiegoś czasu chodziło mi po głowie, żeby dodać sobie do Google Apps własny serwer OpenID - korzystając oczywiście z dobrodziejstw Google AppEngine. Podstawowa zaleta w stosunku do serwera zewnętrznego - jedno hasło do pamiętania mniej, uwierzytelniamy się bowiem za pomocą naszego konta w Google Apps.

Okazało się, że sprawa jest prostsza niż na początku się wydawało - w przykładowym kodzie źródłowym do appengine są źródła providera openid, które praktycznie bez zmian można uruchomić na appengine (pamiętając tylko o ustawieniu uwierzytelniania tylko dla swojej domeny). Niestety - kod ten jest od prawie roku nie rozwijany i użyta tam biblioteka openid jest delikatnie mówiąc archaiczna (obsługa tylko openid 1.0).

Wziąłem się więc do roboty i po dwóch dniach poznawania python-openid, kodowania i debugowania udało się uruchomić provider'a na ostatniej wersji python-openid (2.1.1)

Funkcjonalność na razie jest tylko podstawowa - można się logować :) W podstawowy sposób obsługiwane jest także rozszerzenie Simple Registration - pola nickname i email

Źródła do pobrania na stronie projektu.

Tutaj natomiast gotowa do testowania aplikacja id-provider, z uwierzytelnianiem ustawionym dla wszystkich kont google.

Zapraszam do testowania i zgłaszania uwag / błędów i patchy.

W planach dorobienie funkcjonalności typowej dla dostawców openid - edycja profilu użytkownika (danych przesyłanych podczas Simple Registration), pamiętanie po stonie serwera decyzji w sprawie automatycznego logowania (na razie używane są ciasteczka), itd.

Podpis kwalifikowany

Mon, 22 Sep 2008 12:27:35 +0200

Dzisiaj miałem okazję pomagać w procedurze uzyskania certyfikatu kwalifikowanego (wysyłka dokumentów do ZUS). Jako centrum certyfikacji wybraliśmy CERTUM. Przez internet został zamówiony zestaw "CERTUM Standard" - zawierający czytnik kart (podłączany przez USB), kartę kryptograficzną i oprogramowanie.

Mając niejakie pojęcie o kryptografii asymetrycznej, spodziewałem się procedury generowania CSR (Certificate Signing Request), połączonego z generowaniem klucza prywatnego na karcie. Nic z tego jednak - okazuje się, że dostajemy kartę z już wygenerowanym kluczem prywatnym. Na rewersie karty jest 16-cyfrowa liczba, która służy do identyfikacji karty przez CERTUM - i jak zrozumiałem na jej podstawie są w stanie wygenerować mi certyfikat - czyli już znają mój klucz publiczny. I teraz pytanie najważniejszsze: jaką mam gwarancję że nikt nie zna mojego klucza prywatnego? Konsultant CERTUM zapewniał mnie co prawda, że klucz jest co prawda generowany u nich, jednak następuje to na karcie i karta nie umożliwia exportu tego klucza - pozostaje wierzyć na słowo.

Dlaczego klucz nie jest generowany w momencie wypełniania wniosku o certyfikat - jak chyba nakazuje dobra praktyka w takich przypadkach? Ucięło by to możliwość spekulacji na temat prywatności klucza prywatnego...

Ciekawy jestem jak sprawa wygląda u pozostałych dwóch dostawców certyfikatów kwalifikowanych? Jak macie jakieś informacje na ten temat dajcie znać w komentarzach...

PS. Na koniec jeszcze ciekawostka - byłem w tzw. Punkcie Sprawdzania Tożsamości CERTUM w moim mieście - człowiek zapytany o klucz prywatny stwierdził, że nie ma tam żadnego klucza prywatnego tylko certyfikat. Nazwy firmy przez grzeczność nie wymienię :)

Wirusy na pendrive'ach - akcja edukacyjna.

Mon, 05 May 2008 20:45:45 +0200

Z racji że pracuję w kafejce internetowej, mam okazję zajrzeć na pamięci USB klientów. Z moich obserwacji wynika, że jakieś 90% pendrive'ów przeciętnych zjadaczy chleba zawiera dodatki, o których zainteresowani niestety nie wiedzą. Staram się uświadamiać jak tylko potrafię, ale to kropla w morzu... Ale dzisiaj wpadłem na szatański pomysł. Jak dotrzeć szybko do milionów posiadaczy zainfekowanych pendrive'ów? Puścić edukacyjny łańcuszek na gg :) Jestem oczywiście przeciwnikiem tego typu tworów, ale cel uświęca środki. Mam nadzieję, że pomożecie w komentarzach w edycji formy i treści tego "edukacyjnego łańcuszka". A może mnie po prostu odwiedziecie od tego pomysłu...

Łańcuszek edukacyjny

Wytoczmy wojnę zawirusowanym pendrive'om

Otwórz "Mój komputer"
Wybierz z menu "Narzędzia/Opcje folderów", potem zakładkę "Widok"
W oknie "Ustawienia zaawansowane" włącz "Pokaż ukryte pliki i foldery" oraz koniecznie odznacz "Ukryj rozszerzenia znanych typów plików"
Zajrzyj na swojego pendrive'a. Jeżeli znajdziesz tam jakieś pliki z końcówką exe lub com, których sam tam nie nagrałeś(aś) i dodatkowo masz plik autorun.inf, jesteś NOSICIELEM !!! Możesz spróbować skasować te pliki, ale nie zdziw się jak magicznie pojawią się ponownie. Bardzo możliwe, że potrzebna będzie wizyta u specjalisty :(
Tak więc zrób co uważasz za słuszne. Wyślij tą wiadomość do wszystkich znajomych, a więcej nie ugoszczą Cię wirusem. Nie przesyłaj wiadomości tym, których sam byś chętnie zaraził :)
--
Życzliwy Informatyk