Depozyt kodu źródłowego – co to takiego i dlaczego o tym tak mało wiemy?

W tym roku Komisja Nadzoru Finansowego wydała Rekomendację D1 (61 stron bełkotu prawno-informatycznego – chyba nie ma gorszego), w której wprost mówi o konieczności przechowywania i weryfikowania kodów systemów informatycznych przez banki. O co chodzi?

Usługę depozytu kodu źródłowego oprogramowania wymyślono już latach siedemdziesiątych w USA gdzie występuje pod nazwą: software escrow. Usługa ta zadomowiła się w Europie Zachodniej z grubsza dwadzieścia lat temu. Depozyt polega na złożeniu kodu źródłowego u depozytariusza – a tenże depozytariusz to trzecia strona porozumienia obok producenta oprogramowania (np. my) i jego nabywcy (Ci coraz liczniejsi szczęściarze).

Jak się okazuje – nie jest to wcale prawno-informatyczne rocket science.

Depozyt kodu źródłowego polega na złożeniu do depozytu u dedykowanego podmiotu „kodu źródłowego” oprogramowania, który to kod może być wydany z depozytu tylko i wyłącznie w szczególnych okolicznościach ustalonych przez strony. W naszym przypadku była to odpowiednio przygotowana płyta CD zawierająca kod + dokumentację, która to przez depozytariusza (w tym przypadku była to firma Software Escrow Management – softwareescrow.pl) jest nagrywana na odpowiedni nośnik i deponowana w skrytce bankowej. Wszystko odbywa się w kancelarii w obecności stron (i dymu z cygar).

Kiedy ktoś może dobrać się do kodu przez nas wyprodukowanego i zdeponowanego?

Otóż jest to ściśle określone:

  • w przypadku upadłości lub likwidacji dostawy oprogramowania (uspokajam – ta sytuacja nie jest planowana);
  • w przypadku odmowy świadczenia serwisu lub usług utrzymaniowych przez dostawcę oprogramowania (może się zdarzyć jak się posprzeczamy);
  • w przypadku awarii oprogramowania, której nie chce usunąć dostawca oprogramowania (trudna sytuacja);
  • w przypadku zmiany warunków świadczenia usług serwisowych lub utrzymaniowych ponad ustalone dopuszczalne zmiany (to też skomplikowany zapis).

Dopiero zaistnienie jednej z powyżej wymienionych okoliczności może stanowić podstawę do zwrócenia się przez naszego klienta do depozytariusza z prośbą o wydanie kodu źródłowego z depozytu. Zakładamy oczywiście sytuację że zasadniczy produkt jest udostępniony klientowi bądź to w postaci skompilowanej bądź jako usługa bez bieżącego dostępu do źródeł.

Gdzie są korzyści?

  • Przede wszystkim kod źródłowy nie musi być przekazany nabywcy oprogramowania (!), a jednocześnie jest on zabezpieczony.
  • Nie ma ryzyka wycieku czy skopiowania zastosowanych przez nas rozwiązań programistycznych.
  • Dzięki depozytowi pokazuję klientowi, że jestem „po jego stronie” tj. że rozumiem jego obawy i staram się je zaadresować.
  • Deponowanie kodu u profesjonalnego depozytariusza uwiarygadnia moją firmę (trochę jak notariusz przy transakcji na rynku nieruchomości).

Znaczenie ostatniego punktu widać w sektorze bankowym, gdzie polityka bezpieczeństwa dostawcy software’u bardzo często wiąże ręce bankom i nie pozwala im zaprosić do współpracy mniejsze podmioty o krótkim track-record.

No tak – ale kto zweryfikuje czy to co oddajemy do depozytu to nie jest DVD z ostatnim sezonem Big Bankg Theory tylko realny, działający kod?

Nie zrobi tego klient (bo nie chcemy lub nie możemy udostępnić mu tego kodu albo nie ma odpowiedniego do tego know how), nie zrobimy tego my (bo jeśli mieli by nam wierzyć na słowo honoru to po co usługa depozytu). Przekazanie nośnika z kopią kodu źródłowego jest więc dopiero połową sukcesu. Weryfikacja kodu (słowo klucz) – to integralna część usługi „Software Escrow” świadczona przez Depozytariusza. Podstawowy zakres weryfikacji kodu, obejmuje analizę kompletności, która daje odpowiedź na pytanie czy dostarczony kod źródłowy jest wystarczający do zbudowania wynikowej aplikacji.

Drogę na skróty jest ryzykowna.

W praktyce transakcji nabycia oprogramowania przyjmuje się rozwiązania, które są jedynie namiastką profesjonalnego depozytu tzn. takie, które nie zabezpieczają nabywcy w sposób kompleksowy. Częstym rozwiązaniem jest powierzenie płyty CD z niezabezpieczonym kodem źródłowym oprogramowania wartego grube dziesiątki tysięcy złotych szufladzie „Pani Krysi”, która między szminką a drugim śniadaniem trzyma płytkę CD z naszym kodem źródłowym(sic!). Jak dalece wydaje się takie rozwiązanie humorystyczne, nie stanowi ono problemu o ile satysfakcjonuje obie strony transakcji. Takie przechowywanie kodów źródłowych traci jednak na swoim anegdotycznym wymiarze gdy uświadomimy sobie, że niejednokrotnie są to kody źródłowe oprogramowania dotyczącego bezpieczeństwa naszych danych osobowych, fizycznego bezpieczeństwa czy tajemnic przedsiębiorstwa.

Bardziej wyrafinowaną próbą depozytu jest przechowywanie CD w skrytce bankowej czy w depozycie notarialnym. Oba te rozwiązania czerpią z zaufania publicznego w/w instytucji. Niestety, żaden z tych podmiotów nie jest w stanie podjąć się weryfikacji kodu źródłowego z zasady odpowiadając jedynie za wartość materialną złożonego do depozytu przedmiotu tj. wyprodukowanego w jakimś azjatyckim kraju błyszczącego plastikowego krążka w papierowym etui. Co więcej, trudność sprawia precyzyjne zdefiniowanie warunków zwolnienia kodów źródłowych oraz odpowiedzialności cywilnej takiego depozytariusza za przedwczesne czy niewłaściwe przekazanie kodów.

W końcu, w każdym ze stosowanych rozwiązań niezaadresowanym pozostaje ryzyko przypadkowego wycieku informacji o zastosowanych przez nas rozwiązaniach programistycznych. A zatem przyjmowane na rynku rozwiązania w rzeczywistości nie zaspakajają potrzeb ani nas – developer’ów ani naszych klientów wystawiając tym samym obie strony na ogromne ryzyko biznesowe i utratę prestiżu.

Pierwsze koty za płoty (no ten śródtytuł akurat tu nie pasuje sensu stricte ale dobrze brzmi)

Udało nam się przetrzeć szlaki usługi depozytu kodu przy współpracy z firmą Software Escrow Management. Nic strasznego. Cały proces jest przygotowany – a My (dostawca oprogramowania) oraz nasz klient (odbiorca oprogramowania) mamy zapewnione wsparcie w przygotowaniach. Nie ma tu tajemnic, zmów, spisków i zielonych stolików. Właściwie usługa prawna z częścią merytoryczną IT.

Niezwykle rzadko spotykany w naturze miks ludzi znających się na prawie, informatyce i zarządzaniu (wydaje się, że nawet potrafią ze sobą rozmawiać ;) . Swoją drogą zastanawiam się czy depozytariusz, chowając głęboko kod źródłowy, może użyć usługi skrytek bankowych banku dla którego oprogramowanie było pisane? Stack overflow ;)

Słów kilka o zachodniej netykiecie, kulturze i rozsądku panującej w internecie na przykładzie aplikacji facebook-owych.

800px-Male_Moose

Przez wiele lat mieliśmy okazję „tłuc” aplikacje na Facebook-a na polski rynek. Głównie konkursy, zabawy, fotozabawy, głosowania, rankingi itp…. Typowa szybka rozrywka oparta na mechanizmach socialowych. Za każdym razem właściciel aplikacji (właściciel marki) oczekiwał, aby aplikacja działała tak, żeby przed jej uruchomieniem użytkownik był „zmuszany” do polubienia danego FanPage-a. Również w celu dalszej zabawy aplikacja wymagała zgody na dostęp co najmniej do adresu e-mail a czasem na bardziej zaawansowany dostęp do like-ów, zdjęć, historii itp… Wszystko po to aby aplikacja była po pierwsze motorem do napędzania liczby like-ów na FP a po drugie żeby zebrać w bazie maksymalnie możliwy materiał marketingowy do dalszej komunikacji (maile, imiona, płeć, wiek itp…).

Narodził się z tego właściwie taki standard aplikacji FB, która zanim można się nią pobawić najpierw przymusza do like-a a potem na poprawkę wali po głowie potrzebą dostępu do danych wrażliwych. Czytaj dalej

Konfiguracja prostego środowiska deweloperskiego – tutorial dla naszego wakacyjnego teamu develoerskiego

Rozpoczęliśmy współpracę ze Szkołą Główną Gospodarstwa Wiejskiego z Wydziałem Zastosowań Informatyki i Matematyki.

Za nami już warsztaty rekrutacyjne z dziesięcioma studentami (w tym trzema uroczymi studentkami). Spośród nich wybraliśmy piątkę fantastycznych adeptów programowania (w tym jedną osobę płci przepięknej!!!!).

Razem stworzymy team, który zacznie, w ramach swoich praktyk wakacyjnych, produkcję narzędzia wspomagającego pracę dziekanatu.
Czytaj dalej

Moduły w ZF2 a ograniczenie dostępu do nich per domena dla aplikacji

Dzisiejsza zagwostka programistyczno-konfiguracyjna ma genezę w dobrodziejstwie i elastyczności jakie niesie za sobą nowa wersja framework-a Zend (ZF2). Otóż to co w wersji 1.x było nieużywalnym i nieskalowalnym klocem – czyli moduły – stało się lekkim łatwym i przyjemnym elementem w wersji 2, który to jednakoż wpędził nas w małe kłopoty :)
Czytaj dalej

Fanpage Pracowitych na Facebook-u

https://www.facebook.com/pages/pracowici-programiscipl/374000416050262?fref=ts
Wystartowaliśmy ze swoim fanpage-em na FB. Co się tam będzie działo? Standardowo – jak to na fanpage-ach bywa – pisać będziemy co ciekawego robimy akurat, albo co fajnego zrobiliśmy lub co fajnego robią inni programiści gdy tymczasem nas zżyma z zazdrości. Trochę o Zend Framework, php lub PostgreSQL. Czasem o systemie Debian. Czasem strawnie dla wszystkich ludzi a czasem niestrawnie dla tych półbogów, którzy to akurat zrozumieją ;) Czasem opublikujemy jakieś absurdy z życia firmy.

Generalnie bardziej z przymrużeniem oka niż napinaniem się. Na razie jest jeden lubiący – pierwszy cel – okrągła liczba 64 :)

Zapraszamy: https://www.facebook.com/pages/pracowici-programiscipl/374000416050262?fref=ts

Dostęp do helperów widoku w obiektach Zend_Form

Zazwyczaj zachodzi potrzeba dostępu do routera i helpera url. Ot choćby w celu umieszczenia odnośnika w opisach lub label-ach elementu formularza. Szybka i prosta droga to odwołanie się do viewHelper-a przez Zend_Controller_Action_HelperBroker:

$viewBroker = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
$viewBroker->view->url();
...

Przekierowanie .htaccess starej domeny na nową

Z cyklu dyrektywy w .htaccess lub vhost w apache, które zawsze wypadają z głowy. Jest kilka z nich, które warto sobie zapisać bo często do nich wracamy.

Zdarza się, że migrując serwis (lub np. zmieniając jego adres url) musimy przekierować wszystkie stare odwołania na nowe (ze starej domeny na nową) i to najlepiej tak, żeby nie zagniewać google-a tą zmianą – złe przekierowanie może skutkować spadkiem page rank lub zniknięciem chwilowym z google-a. Przy założeniu że struktura adresów wewnątrz jest taka sama zmienie ulega tylko część domenowa adresu. W przykładzie poniżej dbamy też o to czy jest czy nie ma prefix-u www na początku domeny (co nie zawsze może mieć zastosowanie).


<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^stara-domena.pracowici-programisci.pl$ [OR]
    RewriteCond %{HTTP_HOST} ^www.stara-domena.pracowici-programisci.pl$
    RewriteRule (.*)$ http://nowa-domena.pracowici-programisci.pl/$1 [R=301,L]
</IfModule>

O dobre samopoczucie silnika wyszukiwarek/indexerów dba rodzaj przekierowania w protokole http o kodzie 301 (Moved Permanently).

//TODO: Uzupełnimy notatkę o zagadnienie http z ssl gdy trafimy na taki przypadek w pracy.

Szybki sposób na mailsender-a dla php w środowiskach developerskich / testowych

Nie trzeba konfigurować wielkiego serwera poczty. Na potrzeby prac developerskich np. na Debianie starczy jak zainstalujesz postfix-a i dla porządku rzeczy ustawisz domyślne wartości dla nagłówków mailer-a php:


apt-get install postfix

I w /etc/php5/conf.d/ tworzymy jakiś plik konfiguracyjny, np: ‚mail.ini’ z zawartością:


sendmail_from = hello@dev1.pracowici-programisci.pl
sendmail_path = /usr/sbin/sendmail -t -i -f hello@dev1.pracowici-programisci.pl

Nowy vhost stara skleroza – rekurencyjne ustawianie praw oddzielnie dla plików i dla katalogów


find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

Pamiętaj jeszcze adminie młody, że część katalogów/plików aplikacji może chcieć mieć nieco większe prawa zapisu/odczytu (np. storage na upload itp…). I upewnić się, że odpalasz z odpowiedniego poziomu katalogów – bo się serwer wyłoży ze śmiechu.