W dniu 20.01.2011 23:48, Andrzej Jarzabek pisze:
> Znając numer i inne parametry karty carder może coś kupić, ale gotówki
> sobie nie wypłaci. Jeśli kupuje fizyczne rzeczy, to może być złapany
> przy ich odbiorze. Może sobie nakupić pornoli, ale raczej się w ten
> sposób nie dorobi.
Są ludzie gotowi zapłacić kilkanaście dolarów (a przynajmniej byli 4
lata temu) za jeden zestaw danych - widać coś z nimi potem robią.

--
Pozdrawiam
Michoo

do góry

On 20/01/2011 23:14, Michoo wrote:
> W dniu 20.01.2011 23:48, Andrzej Jarzabek pisze:
>> Znając numer i inne parametry karty carder może coś kupić, ale gotówki
>> sobie nie wypłaci. Jeśli kupuje fizyczne rzeczy, to może być złapany
>> przy ich odbiorze. Może sobie nakupić pornoli, ale raczej się w ten
>> sposób nie dorobi.
> Są ludzie gotowi zapłacić kilkanaście dolarów (a przynajmniej byli 4
> lata temu) za jeden zestaw danych - widać coś z nimi potem robią.

Pewnie że są, ale czy akurat carderzy? Przynajmniej jeśli mówimy o
legalnym zestawie danych, ale carderzy sami chyba nie przyjmują
płatności kartą :)

do góry

On 2011-01-20, Andrzej Jarzabek <a...@g...com> wrote:
>> Ale po prawdzie, tak samo mnie zadziwia że działa dowóz pizzy na
>> telefon. Zabezpieczenia właściwie takie same i analogicznie się opłaca.
>
> Weź pod uwagę, że jak ktoś nie zapłaci, to nie dostanie pizzy, więc
> średnio to się opłaca.

Weź pod uwagę, że to nie jedyny możliwy atak. W szczególności, ktoś może
wymierzyć atak przeciw dowożącej pizzerii.

--
Secunia non olet.
Stanislaw Klekot

do góry

Andrzej Jarzabek pisze:
> On Jan 20, 3:17 pm, "Przemek O." <p...@o...eu> wrote:
>> Jeśli by przyjąć że certyfikat wytwórcy implikuje certyfikat dla
>> produktu, nie mamy takiej gwarancji. Można założyć brak złej woli
>> wytwórcy, ale może się zdarzyć problem/błąd nie wykryty w procesie
>> testowania.
>
> A błąd nie wykryty w procesie testowania przez certyfikujące
> laboratorium nie może się zdarzyć? Według mnie szanse wykrycia błędu w
> oprogramowaniu przy testowaniu laboratoryjnym są znacznie mniejsze niż
> przy podobnym nakładzie środków przy testowaniu przez QA. Bo dział QA
> testuje tylko produkty tej firmy, być może jest zespół, który testuje
> tylko dany produkt, dodatkowo mają wskazówki od developerów gdzie
> należy szukać błędów i mają możliwość testowania produktu we
> wszystkich stadiach produkcji.

Widzisz, w jednej z firm, w której pracowałem, ktoś powtarzał, że "autor
programu jest najgorszym z mozliwych testerów własnego wyrobu". I wiesz
co, po latach doswiadczeń przyznaję mu rację. Oczywiście autor wyłapie
błędy, ale te na które jest przygotowany - czyli fragmenty kodu, co do
których nie miał pewności, czy w rzeczywistym systemie zadziała to
dobrze (tu sobie napisze różne testy, zasymuluje rózne sytuacje i
sprawdzi dokładnie). Niestety w życiu codziennym pojawiają się sytuacje,
których autor programu nie przewidzi (np jakies nawyki osób
obsługujacych program). Dlatego w firmie w której pracowałem były osoby
w dziale testów, które zajmowały się testowaniem produktów w taki
sposób, jaki robia to urzytkownicy, poniewaz było to oprogramowanie
bankowe, toteż były zatrudnione osoby, które wczesniej w banku
pracowały. I wbrew pozorom, tam pojawiało się właśnie najwięcej zgłoszeń
błędów, nie po unit testach.



> Jeśli chodzi o błędy polegające na tym, że w bardzo specyficznych
> sytuacjach, przy specyficznej konfiguracji, przy specyficznych danych
> wejściowych pojawiających się w specyficznych relacjach czasowych
> program się wysypuje, to testy laboratoryjne mają bardzo słabe szanse
> na ich wyłapanie, bo są w stanie przebadać jedynie bardzo wąskie
> wycinki całkowitej przestrzeni zdarzeń.

Ale takich błędów też nie wyłapią programiści.




--
Kaczus
http://kaczus.republika.pl

do góry

Andrzej Jarzabek pisze:
> On 20/01/2011 18:39, Wojciech Jaczewski wrote:
>> Andrzej Jarzabek wrote:
>>
>>> Przy czym akurat właśnie w przypadku oprogramowania testowanie
>>> laboratoryjne jest na tyle nieskuteczne, że rzeczywistym winnym awarii
>>> programu certyfikowanego przez laboratorium będzie faktycznie nie samo
>>> laboratorium, bo ono mogło przeprowadzić swoje testy rzetelnie, tylko
>>> debil, który zdecydował, że dla oprogramowanie wymagane są testy
>>> laboratoryjne zamiast certyfikacji procesu.
>>
>> Programowanie posiada zwykle także kod źródłowy, który można by oglądać i
>> oceniać. Może też mieć pomagającą w zrozumieniu kodu dokumentację.
>
> Może, ale:
>
> Jeśli certyfikacja kodu źródłowego ma polegać na tym, że laboratorium
> poświadcza, że "inspektor kodu" przeczytał kod i nie znalazł w nim
> problemów, a "inspektorem kodu" może być każdy, to takie zaświadczenie
> nie jest nic warte.
>
> Jeśli certyfikujemy "inspektorów kodu" to de facto jest to to samo, co
> certyfikacja programistów - bo "inspektor kodu" musi i tak umieć to,
> czego oczekiwalibyśmy od certyfikowanego programisty.

Nie - bo nie każdy kod musi być sprawdzany. W zależności od tego do
czego program ma służyć, jego certifikacja jest na innym poziomie. Np
pisząc biblioteki dla urządzeń szyfrujących pod windows, tak aby
biblioteka pracowała bezproblemowo pod systemem windows musi ona być
podpisana przez Microsoft. Bynajmniej nie wysyłasz tam kodu biblioteki,
tylko gotową binarkę, którą microsoft (jeśli nie znajdzie zagrożenia)
podpisuje. Ponieważ tu istotne jest, czy występuje zagrożenie, czy nie,
czy binarka nie jest przypadkiem zawirusowana, wystarcza jedynie
certyfikacja tej binarki.




--
Kaczus
http://kaczus.republika.pl

do góry

On Jan 21, 9:48 am, Tomasz Kaczanowski
<kaczus@dowyciecia_poczta.onet.pl> wrote:
> Andrzej Jarzabek pisze:
>
> > oprogramowaniu przy testowaniu laboratoryjnym są znacznie mniejsze niż
> > przy podobnym nakładzie środków przy testowaniu przez QA. Bo dział QA
> > testuje tylko produkty tej firmy, być może jest zespół, który testuje
> > tylko dany produkt, dodatkowo mają wskazówki od developerów gdzie
> > należy szukać błędów i mają możliwość testowania produktu we
> > wszystkich stadiach produkcji.
>
> Widzisz, w jednej z firm, w której pracowałem, ktoś powtarzał, że "autor
> programu jest najgorszym z mozliwych testerów własnego wyrobu". I wiesz
> co, po latach doswiadczeń przyznaję mu rację.

W sensie, że lepszym testerem będzie sprzątaczka?

[...]
> sprawdzi dokładnie). Niestety w życiu codziennym pojawiają się sytuacje,
> których autor programu nie przewidzi (np jakies nawyki osób
> obsługujacych program). Dlatego w firmie w której pracowałem były osoby
> w dziale testów, które zajmowały się testowaniem produktów w taki
> sposób, jaki robia to urzytkownicy, poniewaz było to oprogramowanie

No dobra, co według Ciebie oznacza użyty przeze mnie powyżej skrót
"QA"?
Oczywistą sprawą jest, że dział testów wykonuje testy takie, jak
opisałeś, a nir tylko realizuje instrukcje programisty.

Ale też instrukcje programisty przyczyniają się do wykrywania wielu
błędów, które prowadząc takie testy nie zostałyby wykryte, bo masz np.
sytuację, gdzie został przetestowany build nr 1234, po czym
programista wprowadza pewne drobne zmiany i do testowania idzie build
nr 1235. Jeśli programista wie, na czym polega zmiana i co ewentualnie
może zepsuć, to może napisać notkę wyszczególnuiającą, jakie części
czy funkcje należy w tym momencie szczególnie intensywnie testować i
jakiego rodzaju kombinacje mają szczególnie duże szanse ujawnienia
bugów. To są bardzo cenne wskazówki, których laboratorium testujące
gotowy produkt nigdy nie otrzyma.

> > Jeśli chodzi o błędy polegające na tym, że w bardzo specyficznych
> > sytuacjach, przy specyficznej konfiguracji, przy specyficznych danych
> > wejściowych pojawiających się w specyficznych relacjach czasowych
> > program się wysypuje, to testy laboratoryjne mają bardzo słabe szanse
> > na ich wyłapanie, bo są w stanie przebadać jedynie bardzo wąskie
> > wycinki całkowitej przestrzeni zdarzeń.
>
> Ale takich błędów też nie wyłapią programiści.

Po pierwsze programiści posiadający odpowiednie umiejętności i wiedzę
popełnią takich błędów znacznie mniej dzięki stosowaniu odpowiednich
praktyk.

Po drugie oczywiście, że doświadczony progrramista może wyłapać lub
zmniejszyć szansę takich rzeczy w cudzym kodzie przez code review. Nie
mówimy już tu nawet o zauważeniu, że np. wątki programu używają
dzielonej zmiennej bez lockowania, ale przede wszystkim o tępieniu
złych praktyk, takich jak pisanie nieczytelnego kodu. Bo nie chodzi o
to, czy ten certyfikowany programista będzie w stanie sprawdzić, czy
spaghetti code ma błędy funkcjoalne, tylko że będzie wiedział, że to
jest źle napisany kod, w którym w związku z tym istnieje większa
szansa na błędy, mniejsza szansa na znalezienie błędów i większa
szansa na wprowadzenie błędów w przyszłości: więc nie certyfikuje
takiego kodu niezależnie od tego, czy fanktycznie posiada on błędy
funkcjonalne, czy nie.

do góry

On Jan 21, 10:23 am, Tomasz Kaczanowski
<kaczus@dowyciecia_poczta.onet.pl> wrote:
> Andrzej Jarzabek pisze:
>
> > Jeśli certyfikujemy "inspektorów kodu" to de facto jest to to samo, co
> > certyfikacja programistów - bo "inspektor kodu" musi i tak umieć to,
> > czego oczekiwalibyśmy od certyfikowanego programisty.
>
> Nie - bo nie każdy kod musi być sprawdzany. W zależności od tego do
> czego program ma służyć, jego certifikacja jest na innym poziomie. Np

To jest oczywistość.

Ale mówiliśmy o czym innym: że czasem testowanie gotowego produktu, w
szczególności w przypadku oprogramowania, bywa mało skuteczne, bo
takie testy mogą objąć tylko drobny wycinek przestrzeni zdarzeń: bo
np. dwa komunikaty wchodzące w odstępie 200 nanosekund i te same
komunikaty wchodzące w odstępie 100 nanosekund to już są dwa różne
scenaruisze: nie jest wcale wydumaną sytuacją, że program w jednym z
tych przypadków działa prawidłowo, a w drugim błędnie.

> pisząc biblioteki dla urządzeń szyfrujących pod windows, tak aby
> biblioteka pracowała bezproblemowo pod systemem windows musi ona być
> podpisana przez Microsoft. Bynajmniej nie wysyłasz tam kodu biblioteki,
> tylko gotową binarkę, którą microsoft (jeśli nie znajdzie zagrożenia)
> podpisuje. Ponieważ tu istotne jest, czy występuje zagrożenie, czy nie,
> czy binarka nie jest przypadkiem zawirusowana, wystarcza jedynie
> certyfikacja tej binarki.

Ale mówiliśmy o systemach mission critical, gdzie bardzo istotnym
parametrem jest niezawodność. Microsoft nie certyfikuje takiej
biblioteki na niezawodność.

do góry

On Jan 20, 11:30 pm, "Stachu 'Dozzie' K."
<d...@g...eat.some.screws.spammer.invalid> wrote:
> On 2011-01-20, Andrzej Jarzabek <a...@g...com> wrote:
>
> > Weź pod uwagę, że jak ktoś nie zapłaci, to nie dostanie pizzy, więc
> > średnio to się opłaca.
>
> Weź pod uwagę, że to nie jedyny możliwy atak. W szczególności, ktoś może
> wymierzyć atak przeciw dowożącej pizzerii.

Neal Stephenson opisał ciekawe rozwiązanie tego problemu w powieści
"Snow Crash" (po polsku wyszło jako "Zamieć").

do góry

Andrzej Jarzabek pisze:
> On Jan 21, 9:48 am, Tomasz Kaczanowski
> <kaczus@dowyciecia_poczta.onet.pl> wrote:
>> Andrzej Jarzabek pisze:
>>
>>> oprogramowaniu przy testowaniu laboratoryjnym są znacznie mniejsze niż
>>> przy podobnym nakładzie środków przy testowaniu przez QA. Bo dział QA
>>> testuje tylko produkty tej firmy, być może jest zespół, który testuje
>>> tylko dany produkt, dodatkowo mają wskazówki od developerów gdzie
>>> należy szukać błędów i mają możliwość testowania produktu we
>>> wszystkich stadiach produkcji.
>> Widzisz, w jednej z firm, w której pracowałem, ktoś powtarzał, że "autor
>> programu jest najgorszym z mozliwych testerów własnego wyrobu". I wiesz
>> co, po latach doswiadczeń przyznaję mu rację.
>
> W sensie, że lepszym testerem będzie sprzątaczka?

Zależy od programu i od rodzaju testu, dodatkowo nie napisałem, że nie
może być to inny programista, ale nie autor.




--
Kaczus
http://kaczus.republika.pl

do góry

Andrzej Jarzabek pisze:
>> pisząc biblioteki dla urządzeń szyfrujących pod windows, tak aby
>> biblioteka pracowała bezproblemowo pod systemem windows musi ona być
>> podpisana przez Microsoft. Bynajmniej nie wysyłasz tam kodu biblioteki,
>> tylko gotową binarkę, którą microsoft (jeśli nie znajdzie zagrożenia)
>> podpisuje. Ponieważ tu istotne jest, czy występuje zagrożenie, czy nie,
>> czy binarka nie jest przypadkiem zawirusowana, wystarcza jedynie
>> certyfikacja tej binarki.
>
> Ale mówiliśmy o systemach mission critical, gdzie bardzo istotnym
> parametrem jest niezawodność. Microsoft nie certyfikuje takiej
> biblioteki na niezawodność.

no ale właśnie takie programy zazwyczaj są w urządzeniach i działają w
jakimś środowisku. Łatwiej jest jednak sprawdzić, czy rzeczywiście
całość działa dobrze, niż, czy kod jest przejrzysty i zrozumiały.
Właśnie to można sprawdzić w laboratorium, jak na błędy (bądź sytuacje
ekstremalne) generowane przez środowisko i sprzęt, czy oprogramowanie
zareaguje właściwie. Czy przy przepięciu zadziałają zabezpieczenia, i
czy uda się zapisać gdzieś informację o takim zdarzeniu, tudzież wysłać
odpowiednią informację do centrum nadzoru. Tu nawet najpiękniej i
najlepiej napisany kod nic nie pomoże. System mission critical musi być
i tak brany właśnie jako całość, gdyz najczęściej problemy nie pojawiają
się w kodzie danego systemu, tylko na styku dwóch systemów. Pamiętam
nawet (w mniej critical system) sytuację, gdy łączylismy dwa systemy, by
współdziałały ze sobą jednocześnie. Każdy z tych systemów osobno działał
poprawnie, jednak na styku okazało się, że muszą mieć 1) inaczej
skonfigurowane środowisko 2) konieczny był dostęp do jednej z tabel
jednej z baz i tu wyszła druga rzecz, w obu systemach stosowano inne
rodzaje transakcji (bo system tamten pozwalał na rózne podejścia do tego
problemu) i tu systemy się pięknie zakleszczały.... Oczywiście problem
był do rozwiązania, ale widzisz, oba kody napisane zgodnie z zasadami,
oba kody samodzielnie działają dobrze, ale gdy potrzebna jest współpraca
już nie jest tak wesoło.

--
Kaczus
http://kaczus.republika.pl

do góry