Strona domowa GDR!a

Pisałem jakiś czas temu o wysyłaniu wiadomości do wszystkich podłączonych zasobów w Openfire. Od tego czasu wyszła nowa wersja, 3.8.1. Łatka nałożyła się na nią bez problemu, zbudowałem więc pakiet DEB.

Gdyby komuś się chciało samodzielnie zbudować openfire, trzeba zainstalować JDK oraz Anta i wykonać w podkatalogu build/ następującą komendę:

JAVA_HOME=/usr/lib/jvm/java-6-openjdk-amd64/ ant installer.debian

Pomysl na aplikacje na smartfona. Target: mlodziez, wiec sprzeda sie dobrze. Do sprzedania w wiekszosci krajow. Technologicznie - w ciagu roku wiekszosc telefonow sie bedzie nadawac.

Jestes mlodym ruchaczem w barze/klubie. Przechodzisz kolo stolikow co atrakcyjniejszych osobnikow przy przeciwnej, przykladajac przy tym dyskretnie w okolicach ich torebek telefon z NFC. Nie nawiazujac specjalnego kontaktu przechodzisz dalej.

Twoj telefon w tym czasie czyta ze zblizeniowych kart platniczych dane dziewczyn, zapamietujac imie i nazwisko. W miedzyczasie laczy sie z Facebookiem i G+ w poszukiwaniu zdjecia. Kiedy masz czas spojrzec na ekran, widzisz liste imion, nazwisk i zdjec profilowych. Klik, i pokazuje sie streszczenie: zdjecia, ostatnie checkiny i ostatnio dodane zainteresowania. Jeszcze jeden klik i wchodzisz na profil. Podchodzisz do stolika wiedzac jaki bedzie najlepszy temat rozmowy, pytasz: "Czy ty przypadkiem nie jestes Romualda? Chyba pamietam cie z wakacji w Hurgadzie, 2009." Tanie, nie?

Cala niezbedna technologia juz istnieje i jest w sprzedazy, a karty zblizeniowe sa tak mocno wmuszane przez banki, ze w ciagu roku-dwoch pewnie beda zdecydowana wiekszoscia.

Acha, no i zeby bylo jasne: masowy podryw w barach to nie moje klimaty, po prostu naogladalem sie sporo.

Byłem dziś w ulubionej instytucji przedsiębiorców - Zakładzie Ubezpieczeń Społecznych - i z nudów oglądałem ekrany informacyjne. Bardzo mi się spodobało logo na jednym ze slajdów:

Dla uwierzytelnienia, udało mi się zrobić jeszcze zdjęcie całego ekranu.

(uwaga, wyjaśniam na czym polega dowcip) Zdjęcie posiada watermark serwisu iStock Photo. Jest to firma która sprzedaje przez internet zdjęcia do zastosowań biznesowych. Na ich stronie umieszczone są podglądy zdjęć ze znakiem wodnym, których nie wolno legalnie wykorzystywać - zresztą, wyglądają nieprofesjonalnie. Po zakupie, za kilkadziesiąt-kilkaset złotych dostaje się dostęp do pełnych zdjęć oraz prawa do ich dowolnego wykorzystania.

EDIT: Zdjęcia z watermarkiem mogą być legalnie wykorzystywane, jak zauważył na wykopie ciepol

EDIT2: "An iStockphoto comp does not include any licensing so if you publish a watermarked file, you do not have the rights to use it" - czyli jednak nielegalnie.

Własny serwer XMPP nie dorasta do pięt Google Talk. Przynajmniej w normalnych, codziennych zastosowaniach - mam kilka komputerów, telefon i chcę najzwyczajniej w świecie dostawać wiadomości na wszystkie urządzenia. Nie jestem chyba jedyny, bo wyszukanie "ejabberd send messages to all resources", albo to samo tylko dla openfire, zwraca znaczną ilość pytań na forum zamykanych przez developerów odpowiednim cytatem z XEP, zawierającym dużą ilość SHOULD i żadnego MUST. Openfire niby posiada opcję route.all-resources, ale ta działa tylko jeśli nadawca pisze do user@server.com, nie podając nazwy zasobu. Ćwiczenie: odpal konsolę XML i zobacz jak często zdarza się to w rzeczywitej komunikacji.

Do wczoraj używałem ejabberd i na nim próbowałem bezskutecznie osiągnąć zamierzony efekt. Próbowałem nawet zrobić forka który zachowuje się tak, jakbym chciał, ale ponieważ nie znam erlanga, wyszedł mi twór który co prawda umie routować wiadomości, ale za to kiedy jestem offline zwraca moim rozmówcom błędy.

Miałem wolny wieczór, więc spróbowałem tego samego z Openfire. Ma wszystkie wady i zalety Javy - zjada dużo ramu, używa dużo XMLa, nie integruje się dobrze z systemem, ale za to rozumiem co się dzieje w kodzie. Hackety hackety hack i powstał deb i patch które zamieniają Openfire w coś dla normalnych użytkowników, gwałcąc przy tym SHOULD w rozdziale 11.1 specyfikacji. Ojej.

A najlepsze w tym wszystkim jest to, że nie ma sensu robić porządnego konfigurowalnego patcha i wysyłać go do upstreamu, bo z punktu widzenia developerów taka opcja jest całkowicie zbędna i przecież lepiej czekać aż samo się zaimplementuje (bo nikt nad tym nie pracuje) w serwerach i klientach XEP-313 niż mieć działające rozwiązanie teraz.

W internecie można znaleźć wiele poradników pod w/w tytułem, teraz - dla odmiany - to samo, tylko że działające. Sprawa jest prosta: wchodzimy na java.com, ściągamy plik "Linux" (nie RPM, zwykły tar.gz) i rozpakowujemy gdzieś na dysku. KONIEC. Pliki wykonywalne znajdują się w podkatalogu bin.

Bonus: komenda do uruchomienia Yugmy, fajnego programu do oglądania ekranu klientów:

/home/gdr/Downloads/jre1.7.0_09/bin/java -XX:+PrintGCDetails \
-classpath Yugma.jar -Dsun.java2d.noddraw=true -Dsun.java2d.ddforcevram=true \
-Dsun.java2d.translaccel=true -Djava.library.path=lib \
-Djavax.net.ssl.trustStore=properties/client.keystore \
-Djavax.net.ssl.keyStore=properties/client.keystore -jar Yugma.jar

Taki żarcik zrobiłem w pół godziny. Jak ktoś nie wie o co chodzi, to o to.

Brakuje mi serwisu z wiadomościami dla ludzi, którzy mają swoje życie. Chciałbym być poinformowany o rzeczach ważnych dla mnie, a nie o tym że Kaczyński powiedział że Tusk mieszka z matką i nie ma konta w banku. Natężenie naprawdę istotnych dla mojego życia wiadomości oceniam na maksymalnie jedną-dwie w miesiącu.

W idealnym serwisie mógłbym zapisywać się do podkategorii - polityka, Polska, świat, motoryzacja, dzieci, firma. W dziale politycznym byłyby jedynie przełomowe wydarzenia: samolot wleciał w WTC, połowa rządu zginęła w Smoleńsku, za dwa tygodnie wybory do Sejmu, podwyższono wiek emerytalny do 80. W motoryzacji jedynie istotne zmiany - od jutra przez całą dobę należy jeździć na długich a dzieci w samochodzie należy wozić wyłącznie w kojcach. W dziale firma - że podniesiono ZUS, albo że co miesiąc jest od teraz obowiązkowo kolejny papierek do wypełnienia.

Jestem tragicznie nie na bieżąco z wydarzeniami, bo mając do wyboru przekopywanie się przez tony ciekawostek polityczno-showbusinessowych albo bycie nie na bieżąco, wybieram to drugie. Mam swoje życie, nie mam czasu czytać informacji które są mi zbędne a przy tym zupełnie nieinteresujące. Ale czuję potrzebę dostępu do ważnych informacji, więc jestem w stanie raz na tydzień przeczytać RSS lub email ze skrótem tego, co naprawdę ważne. Jestem w stanie potwierdzić powyższe gadanie kasą na kickstarterze albo piwem dla tego, kto mi wskaże już istniejący serwis tego typu.

Z jakiegoś powodu, Facebook nie stosuje się do protokołu blokowania botów, znanego bardziej jako robots.txt. Każdy link do mojego contentu wstawiony na Facebooka skutkuje odwiedzinami od "facebookexternalhit/1.0" pomimo tego, że robots.txt wyraźnie zabrania botom dostępu do tej strony. FB nawet nie sprawdza pliku robots.txt, więc niby skąd miałby wiedzieć że nie powinien. Jakby tego było mało, trzymają u siebie kopię mojego contentu (część tekstu, obrazki) i co jakiś czas odświeżają sobie, sprawdzając czy aby nic nowszego nie mogą ukraść (nie piszę tu o tej stronie, która oczywiście jest publicznie dostępna).

Wstyd, duża firma, a praktyki jak u rosyjskich crackerów. Ponieważ nie stać mnie na bastion prawników większy niż ma do dyspozycji Zuckerberg, pozostaje rozwiązać problem społeczny za pomocą techniki. Ktoś już przede mną wykonał analizę źródeł niepożądanego ruchu, ja zdecydowałem się na razie zablokować jedynie user-agenty, nie zakresy adresów IP. W skrócie, wystarczyło dodać trzy linijki do configa lighttpd:

$HTTP["useragent" TARGET="_BLANK"> =~ "^(facebookexter|facebookplat)" {
url.rewrite-once = (".*" => "/copyright.html")
}

#firstworldproblems

Kilka dni temu dotarło do mnie w końcu zamówione w okolicach marca Raspberry Pi. Okazało się jednak, że nie pobawię się nim bez klawiatury USB i przejściówki HDMI - DVI. Na szczęście jednak okazało się, że w prosty sposób można na nim włączyć serwer SSH.

Po włożeniu do komputera karty SD z pobranym ze strony obrazem Debiana, pokazują się dwie partycje: mała /boot wielkości 75 MB i większa z głównym systemem plików. Na tej pierwszej znajduje się plik o nazwie boot_enable_ssh.rc - wystarczy zmienić jego nazwę na boot.rc, włożyć kartę do Raspberry, podłączyć go do sieci i połaczyć się. Proste.

Wszyscy znamy ten schemat: tabela z użytkownikami, user ID, username, hash hasła. Ostatnia z tych kolumn przechodziła powolną ewolucję: wpierw zamiast MD5 zalecano SHA(5)1(2), potem niezbędne okazywało się solenie hashy, następnie - okazało się, że skróty kryptograficzne są be i należy używać bcrypt lub podobnej funkcji przeznaczonej specjalnie do haseł. Ogólny schemat pozostawał jednak ten sam.

Jeremy Spilman w swoim artykule "A better way to store password hashes?" proponuje inny sposób przechowywania haseł. Zamiast łączyć informację o haśle z informacją o użytkowniku, można przechowywać hashe w osobnej jednokolumnowej tabeli (lub w innej strukturze danych o semantyce zbioru, np. Set w Redisie), posolone user ID bądź inną informacją specyficzną dla użytkownika.

Już sama taka operacja - rozdzielenie danych o użytkownikach i danych o hasłach - nastręcza trudności atakującemu który przejął dane z bazy. Spilman proponuje jednak dodatkowo wzbogacić nasz zbiór hashy o kilka miliardów losowych wartości o długości hasha. Pierwsze co nasuwa się na myśl to zwiększone prawdopodobieństwo kolizji, ale na przykład, przy wstrzyknięciu miliarda hashów i 128-bitowej długości hasha, zmienia się ono z 1:340282366920938463463374607431768211456 do 1:340282366920938463463374607431. Na pierwszy rzut oka, można przeżyć z takim ryzykiem.

Trzeba poczekać jeszcze miesiąc-dwa na odzew ze strony ludzi od security i w zasadzie można będzie zacząć stosować takie rozwiązanie. Może w ramach julython ogarnę jakiś moduł autoryzacji do Django?

Kontynuując wieloletnią tradycję opisywania najbardziej kozackich wyskoków w historii informatyki, dzisiaj zwracam uwagę szanownych czytelników na pay card reader. Jest to aplikacja na Androida, jeszcze kilka godzin temu podobno dostępna za darmo w markecie play, która potrafi sczytywać numery kart kredytowych typu PayPass oraz dane odnośnie wykonanych nimi transakcji.

Wyczyn Thomasa Skory uważam za godny podziwu ponieważ:

• udostępnił aplikację za darmo, jako Open Source
• pokazał szerokiej publiczności, że żeby ukraść dane z karty wcale nie potrzeba podejrzanie wyglądającego sprzętu z zielonymi literkami na ekranie i wystającymi przewodami, tylko telefon z obsługą NFC
• dał solidnego kopa w dupę bankom które, jak zawsze, bezpieczeństwo użytkowników stawiają na dalekim miejscu

Pozostaje życzyć sobie więcej akcji wykonanych z taką fantazją.

Całkiem niedawno napisałem aplikację na Androida, bo nie było żadnej która umożliwiałaby współdzielenie (Share/Send to) linków czy innej treści z kontaktami komunikatora Google Talk. Postanowiłem nie wypuszczać jej od razu za darmo tylko poczekać aż Google dopuści polskich developerów do sprzedaży aplikacji w Play. Minęły dwa miesiące i doczekałem się: Share to Talk w Play/Markecie.

Dostępny jest kod źródłowy (GPLv3), na zasadzie "zbuduj sobie sam albo płać jeśli nie umiesz".

Od czasu napisania aplikacji używam ją regularnie i wszystkie problemy które były, poprawiałem na bieżąco.

OTR to protokół kryptograficzny który ma właściwości powodujące, że nadaje się doskonale do rozmów przez komunikatory w czasach kiedy władza raz po raz debatuje nad obowiązkowym nagrywaniem ruchu w internecie przez dostawców. Wiele popularnych programów (Pidgin, Adium, Miranda i inne) ma obsługę OTR. Ja używam Psi, istnieje do niego wtyczka, ale konia z rzędem temu kto skompiluje ją z jakąś współczesną wersją komunikatora. Oszczędzę wam szczegółów i przejdę do rozwiązania.

sudo apt-add-repository ppa:psi-plus/ppa

sudo apt-get install psi-plus

Okazało się, że developerzy psi-plus przejęli rozwój wtyczki i w swoim oficjalnym PPA publikują pakiet psi-plus ze zbudowanym libotrplugin.so. Wersja psi-plus z repozytoriów Ubuntu nie dostarcza tego pakietu, podobnie jak większość innych repozytoriów w których szukałem. Najciemniej jest pod latarnią.

Istnieje alternatywny system DNS o nazwie Namecoin, w którym nie ma centralnych serwerów DNS, a każdy z klientów posiada kopię wszystkich rekordów. Wszystko działa w oparciu o P2P i silną kryptografię, żeby sfałszować wyniki należałoby przejąć 51% sieci, więc rząd USA chcąc zdjąć domenę musiałby działać nieco aktywniej niż tylko ustawami. Domeny mają rozszerzenie .bit - na przykład gdr.bit czy massivescale.bit. Oczywiście używa tego nie więcej niż kilkaset - kilka tysięcy no-life'ów, więc inwestowanie w tę technologię czasu jest całkowicie zbędne, bo i tak się nie przyjmie.

Dlatego właśnie w ramach projektu-hobby stworzyłem program który usuwa małą wadę - ponieważ nie ma registarów, nie ma kto poinformować cię że twoja domena niedługo wygaśnie. Program obserwuje domeny i wysyła maile jeśli wykryje że jedna z twoich domen wkrótce wygasa. 15 użytkowników takiego serwisu byłoby już dużym sukcesem ;)

No, ale miałem wymówkę żeby w praktyce napisać coś używając bazy Redis. Panie i panowie, poznajcie Name Alert, najmniej użyteczny kawałek softu mojego autorstwa od czasu monopole.prv.pl

Namęczyłem się co niemiara żeby ustawić IPv6 na serwerze według śmieciowej instrukcji OVH, ich support też nie wie, więc może zachowam dla potomności trzy polecenia które zadziałały (a w zasadzie, nie tyle o polecenia chodzi co o adresy).

ifconfig vmbr0 inet6 add 2001:4120:1:aa12::1/64

ip -6 route add 2001:4120:1:AA00::/56 dev vmbr0

route -A inet6 add default gw 2001:4120:1:AAFF:FF:FF:FF:FF