Tag: program

Opublikowane w

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.

Opublikowane w

Mumble, czyli alternatywa dla TeamSpeak

Powody dla powstania wpisu są dwa. Po pierwsze, pogrywam sobie czasem w World of Tanks, ostatnimi czasy niekoniecznie sam, a częściej w plutonie. Oczywiście można grać przy pomocy porozumiewania się wbudowanym chatem, czyli pisząc i używając wbudowanych komend i tak długi czas z K. graliśmy, ale przyszedł M. i namówił nas na zorganizowanie mikrofonów i słuchawek. I faktycznie, w przypadku komunikacji głosowej fun jest nieporównywalnie większy.

Korzystaliśmy z wbudowanego w grę mechanizmu, który wymaga wciśnięcia klawisza, jeśli chce się coś powiedzieć. Wykonalne, ale palców jest ograniczona ilość i w czasie gry mają lepsze zajęcia, niż obsługa głosu. Zdarza się, że się zapomni o wciśnięciu klawisza czy po prostu nie ma czasu go wcisnąć. I komunikat ginie.

Trochę zaczęliśmy myśleć o alternatywach. Ostatecznie gracze z jakiegoś powodu korzystają z TeamSpeaka… W klanie K. jako system komunikacji głosowej obowiązywał nie TeamSpeak, ale Mumble, którego nazwa zupełnie nic mi nie mówiła.

Logo Mumble

Źródło: https://en.wikipedia.org/wiki/File:Icons_mumble.svg

Rzuciłem okiem i okazało się, że jest natywna wersja linuksowa, a software to open source. I tu drugi powód powstania wpisu: TeamSpeak jest dostępny (zarówno klient, jak i serwer) na Linuksa, ale nie jest open source i dostarczana jest binarka. Tylko dla architektur i386 oraz amd64 w Debianie. Niedawno na kanale IRC ktoś pytał o tego typu chat grupowy z możliwością uruchomienia serwera na procesorze ARM. Mumble jako open source oczywiście jest dostępne także na architektury armel oraz armhf. Poza tym, lubię testować alternatywy.

Zainstalowałem serwer (można ograniczyć dostęp hasłem, domyślna konfiguracja jest prosta i wystarczająca do uruchomienia…), choć można skorzystać z serwerów publicznych. W konfiguracji serwera można też zgłosić swój serwer do katalogu publicznych.

Instalacja klienta jest równie prosta, jedyne co trzeba zrobić, to wyskalować dźwięk przy pomocy wizarda. Klient ma trzy metody włączania nadawania: non-stop (mikrofon cały czas „zbiera” – średnio wygodne dla reszty uczestników), znana z WoT aktywacja klawiszem oraz tryb najlepszy, czyli aktywacja głosem. I po to jest kalibracja, żeby przy odpowiednim natężeniu dźwięku (czyli gdy coś mówimy) klient zaczynał transmisję, ale nie zbierał cały czas tła.

Najważniejsze cechy Mumble:

  • szyfrowana komunikacja (domyślnie)
  • niskie opóźnienie
  • open source
  • wieloplatformowość (Linux, Windows, OS X)
  • niskie wymagania zasobów (serwer; jest nawet wersja serwera dla OpenWrt)
  • usuwanie echa
  • pozycjonowane audio (słychać z którego kierunku mówi osoba)
  • in-game overlay (jest wyświetlane, kto mówi)

Z ostatnich trzech nie korzystam, bo – kolejno – gramy na słuchawkach, nie ma potrzeby/nie zauważyłem, zupełnie nie mam potrzeby. Jeśli chodzi o jakość dźwięku i opóźnienie jestem bardzo zadowolony (póki co testowane na dwóch osobach na kanale, większą ilością się nie zebraliśmy). Jakość dźwięku lepsza zarówno niż w WoT, jak i na Skype (skoro VoIP porównujemy). Nie wiem na ile w tym zasługi łącz, a na ile klienta, ale jeśli tylko wszyscy w plutonie mają zainstalowanego klienta Mumble, to korzystamy z tego rozwiązania. Polecam.

Więcej o Mumble można poczytać na angielskiej stronie Wikipedii. Ale nie ma co czytać, trzeba instalować. 😉

Opublikowane w

Wybory – sytuacja, pomysły

Początkowo z wyborami było trochę śmiesznie (no dobrze, śmiech przez łzy), zrobiło się trochę strasznie (okupacja PKW, nie ma zgody na kwestionowanie wyników przez miłościwie nam panującego, wygrana PSL). Pojawiły się też głosy o konieczności stworzenia otwartego, wolnoźródłowego systemu i inicjatywy w tym temacie. Cieszy, bo oznacza, że to nie moje paranoje i pomysł ma sens.

Trochę na FB pisałem, ale to znika, więc dla pamięci (i szerszego grona). Do głowy przyszedł mi wariant minimum. Zaznaczam, że bazuje na starych procedurach ręcznych (ale cóż więcej trzeba?) i starych, sprawdzonych technologiach, choć korzystając z nowych warunków.

Wystarczyłoby, żeby komisje wysyłały proste tekstowe dokumenty o ustalonym formacie (formatkę, czyli odpowiednik protokołu powinny dostać wcześniej) przy pomocy emaila (stara sprawdzona technologia, dobrze się skalująca). W ramach ustalenia autentyczności i tajności[1] podpisanego/zaszyfrowanego GPG. Oczywiście członkowie komisji (a przynajmniej 2-3 z każdej komisji) musieli by mieć potwierdzone klucze, ale z tym nie ma problemu – i tak są na szkoleniu dla członków komisji. Maila każdy w dzisiejszych czasach ma (wystarczą 2-3 osoby z komisji, powtórzę) i wysłać umie. Czyli tak, wysyłali by wyniki podpisane GPG z dowolnych, nawet prywatnych, darmowych kont. Potwierdzenie dostarczenia jest opcjonalne (delivery notification), ale dostępne w programach pocztowych, czyli komisja wie, czy/kiedy protokół dotarł do serwera poczty PKW. Z nowoczesnych dodatków i zwiększania wiarygodności – można załączyć „skany” papierowego protokołu. Wystarczy smartfon z aparatem (znaczy: smartfon)…

Po stronie serwera email PKW nic specjalnego się nie dzieje. Jeśli chodzi o dalszą część serwerową, to program do liczenia łączy się do serwera poczty, odbiera maila, na podstawie tematu przypisuje do komisji (albo z treści formularza…). Następnie weryfikuje autentyczność podpisu GPG i w przypadku zgodności parsuje plik tekstowy.

Gdyby pliki były wysyłane w dokładnie określonym formacie, to całość jest do naklepania w Perlu w parę godzin. No ale pewnie nie będą, bo maile umożliwiają dość dużą dowolność formatu wysyłki pliku i co program, to wynalazki… (szczególne ukłony w stronę Microsoft). Można się bawić oczywiście w napisanie prostego klienta poczty dla komisji. Zaleta rozwiązania jest taka, że po wyborach PKW może udostępnić publicznie wyniki. Albo wręcz przeforwardować wyniki z danej komisji wszystkim zainteresowanym, którzy np. wcześniej zgłoszą takie zapotrzebowanie.

W kontekście wysokiego wyniku PSL i ponownie sporej ilości głosów nieważnych dla przypomnienia kawałek historii:

wybory 2010 głosy nieważne

Źródło: http://uczciwe-wybory.pl/analiza-glosow-niewaznych-wyborach-parlamentarnych-2005-2007-2011-samorzadowych-2010/

W odpowiedzi na to kolejny pomysł – kamery w komisjach i albo streaming online, albo przynajmniej rejestracja i udostępnienie obywatelom bezpośrednio po wyborach[2]. Jeśli jest podejrzenie fałszowania głosów przez członków komisji (a właśnie o dostawianiu krzyżyków mowa), to powinno to rozwiązać problem. Plus obowiązek przebywania głosów „na oczach kamer” od momentu wyjęcia ich z urny do czasu sporządzenia protokołu przez komisję.

W ten sposób obywatele mieliby możliwość prostego zweryfikowania wyborów ze swojej komisji i nadzorowania pracy (przypomnę, po zamknięciu lokali poza członkami komisji i mężami zaufania obywatele nie mają dostępu do lokali).

[1] Tajność wygląda na zbędną. Wysyłki są dokonywane już po zamknięciu lokali, więc nie ma potrzeby utajniać wyniku.

[2] Zdaję sobie sprawę, że danych jest sporo i nakłady na infrastrukturę (kamery plus streaming) nie są małe. Być może wystarczyłaby możliwość montowania kamer (z publicznym streamingiem) przez obywateli.