Johnny_Bit

Wczoraj we wpisie Wykrywanie błędów w zabezpie... mówiłem o tym jak się nie powinno robić przy znajdowaniu błędów zabezpieczeń. Dziś znalezione na wykopie prezentuje jak się należy zachować: http://www.contextis.co.uk/resources/blog/hacking-canon-pixma-printers-doomed-encryption/

Ogólnie: od razu po znalezieniu błędu producnet został poinformowany, a publikacja informacji nastąpiła po omówieniu problemu osobiście przez przedstawicieli producenta i znalazcy błędu... Tak jakieś pół roku po znalezieniu problemu :)

Wykrywanie błędów w zabezpieczeniach jest fajne. Jeśli jesteś "dobrym" to informujesz twórcę, czekasz ileśtam na fix, a później publikujesz. Masz wówczas bonus od twórcy i samozadowolenie. Jeśli jesteś "złym" to nie informujesz nikogo i wykorzystujesz błąd dla swoich własnych celów (albo sprzedajesz 0-day albo coś takiego). Jeśli jesteś po prostu dupkiem publikujesz błąd od razu, bez informowania twórców ani czerpania zysków, najpewniej na swoim (mało) popularnym blogu z komentarzem w stylu "lol, jakie ciołki, jaki bug dali. Daje publicznie bo błąd oczywisty i żałosny".

Przykład "dupka": https://vexatioustendencies.com/wordpress-plugin-vulnerability-dump-part-2/

Kolejny przykład z serii "oprogramowanie mozna robić dobrze, źle lub Enterprise":

System templatkowy bez cache - źle.

System templatkowy dla przyśpieszenia działania powinien miec cache renderów, żeby nie robić niepotrzebnie co chwila generowania strony która jest właściwie statyczna. To jest akurat dobre podejście.

Ale jesli to cache jest robione per klient i zamiast cache jest nazwane "customization" i do tego łączy w sobie cechy micro-customizacji templatek oraz cahce - to jest to rozwiązanie enterprise. A później mamy folder customization zajmujący 20GB+ pełny html/xml w którym są łącznie 3 faktyczne micro-customizacje.

Z przygód w świecie Enterprise z ruskim STL: do skompilowania szkieletu wtyczki (czyli jakby działająca wtyczka w metodach mająca tylko return) potrzebny jest przynajmniej 4-rdzeniowy komp z minimum 4GB ramu. Вот это техника... Do tego zamiast autotools normalnego czy CMake - waf. waf oczywiście w wersji antycznej... Super. Ale przynajmniej jedna wtyczka zrobiona, jedna do zrobienia.

Faile lokalizacji (i jej obsługi) w oprogramowaniu klasy enterprise to coś co zdarza się raczej rzadko, ale akurat mam teraz przyjemność z tym się "babrać", więc sie wypowiem i może dam parę wskazówek dla innych:

1 Jeżeli aplikacja potrafi łatwo wyświetlić kwotę w formacie poprawnym lokalnie, niech też przyjmuje kwotę w formacie lokalnym i niech nie nad-interpretuje separatorów tysięcznych. Przykład: kwota 10 000,99 PLN wyświetlana jest OK. Przekopiowanie jej do pola przyjmującego kwotę skutkuje czymś idiotycznym: 1000099000.00 PLN. Inne pole z kolei nie przyjmuje spacji ani przecinka. Co sprowadza nas do:
2 Używaj jednego modułu lokalizacyjnego do całej aplikacji. Jeżeli w jednym miejscu data jest wyświetlana w formie 2014/08/29, w innym 29-08-2014 a w jeszcze innym 08.29.2014 znaczy że coś jest nie tak. To samo się tyczy zapisu cen - zł10000 wygląda dziwnie. $10000 wygląda OK. Prefix/postfix i separacja symbolu waluty od kwoty różnią się i to bardzo.
3 Edycja nazw lokalizacyjnych w gui to dobry pomysł. Templatki wykorzystujące nazwę w danym języku to dobry pomysł. Brak spójności w tym co można wprowadzić do templatki a co nie to zły pomysł.
4 Powiązane z powyższym - Jeżeli w jednym miejscu są templatki a w drugim, bardzo podobnym nie ma, to znaczy że masz niespójny system. Przykład: Mgę definiować nazwę dla samochodu w PL "Samochód" w EN "Car" itp ale w jego częściach już nie (czyli mam "Engine" "Tires" itp)
5 Stosuj stałe identyfikatory lokalizacyjne. en_US jest różne od en_GB, więc nie są równoznaczne. Mają inne formaty dat, kwot itp. Różnice Color/Colour tez są. Okropnym niedociągnięciem jest także gdy jedne moduł używa pełnej specyfikacji (en_US) a inny spodziewa się dwu znakowego określenia (en)
6 Liczebniki są skomplikowane. Polecam zajrzeć tu: http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html Głupio wygląda np "5 Swetry" albo "3 Swetrów".

I ostatnie: L10N i I18N nie są tym samym (ale są powiązane). I to na tyle ważny element systemu że lepiej nie wysyłać go do Klepaczstanu gdzie znajdzie się programista za $1/dzień.

Yay! pobiłem swój życiowy rekord! Ponad tysiąc lini kodu, 30 metod, 6 klas. Compile -> 0 warnów, Run -> 0 problemów! Valgrind -> brak wycieków! Jak tak mi dobrze dziś poszło, znaczy że pewnie mi się jutro samochód zepsuje albo coś. Cudów nie ma.