Administrace komentářů

Vzal jsem to z opačné strany a mám nástřel implementace knihovny v C (libcurl, libxml2) a začínají na povrch vyplavávat problémy nebo alespoň otázky:

Autentizace klienta je přípustná čtyřmi různými způsoby, prakticky se jedná o dva (vzájemně se nevylučujícíc se) způsoby: HTTP basic a klientský SSL certifikát.

První způsob je jasný, jediná otázka je ohledně cachování hesla, protože SSL spojení se může kdykoliv rozpadnout a co pak? Vyhodit aplikaci chybu, ať poskytne znovu heslo, nebo si heslo při přihlášení schovat a potichu jej znovu použít (respektivě cookie, na který se autentizace deleguje)? S tím souvisí ochrana před odswapováním hesla. Máme mlock(3), ale knihovna pro HTTP si heslo kopíruje pro sebe. Tohle se dost blbě ošetřuje.

Autentizace certifikátem má z vyhlášky povinnost mít klíč schovaný nevydolovatlným způsobem v kryptografickém zařízení, které dle provozního řádu ISDS musí implementovat MS CryptoAPI nebo PKCS#11 prostřednictvím knihovny libp11(?). Ví někdo o kryptografickém zařízení, které v linuxu funguje, splňuje tyto podmínky (mimo jiné 2048b RSA a SHA-2) a dá se za rozumné peníze koupit? Bude tento způsob autentizace povinnou součástí zadání?

Další problém je s ověřováním digitálních podpisů obálek. Dle provozního řádu byl XMLSec opuštěn kvůli výpočetně drahé kanonizaci XML a místo toho se podepisuje konkrétní serializovaný bitový proud XML podstromu a podpis se ukládá do PKCS (#7 ?) struktury.

Z toho vyplývá, že záleží na fyzické struktuře XML a z HTTP těla SOAP odpovědi bude nutné patřičný XML dokument zpřístupnit vyšším vrstvám jako prostý řetězec. Opakovanou serializací by se mohla porušit fyzická struktura a podpis by neseděl. Nevíte jak je na tom libxml2? Jestli umí zachovat fyzickou strukturu i po deserializaci? Ve své knihovně zatím vracím rezebraný XML strom (přesněji řečeno seznam uzlů (xmlNodeList) z těla SOAP), takže možná bude nutné vracet i dokument jako blob (ať paměťová složitost roste).

Další problém je s licencí. Rád bych do knihovny zahrnul XML schémata, abych mohl příchozí a třeba i odchozí zprávy validovat. Na to bych rád do knihovny začlenil XSD soubory z provozního řádu. Jenže podle českého autorského zákona podléhají úplně normální licenci, kromě výjimky (úřední dílo), že dílo mohu rozmnožovat a šířit. Mám ale dojem, že už nemám právo jej pozměňovat. To by pak ale bylo v rozporu třeba s licencí LGPL, protože ta uživateli dává právo cokoliv měnit. Jaký je váš názor, bude nutné schémata přepsat, šířit samostatně nebo požádat o lepší licenci Českou poštu, nebo se mýlím?

Další problém nastane, až se knihovnu někdo pokusí použít z aplikace. Spousta grafických knihoven si uzurpuje proces pro sebe, některé mají problémy s vícevláknovými procesy. Knihovně by asi slušelo asynchronní rozhraní, aby aplikace mohla oznámit, že byl zahájen přenos zprávy, pak ukazovat indikátor postupu a uživateli dát kdykoliv možnost přenos přerušit. (Vezmete na vědomí, že velikost zprávy může být až 10 MB, což na 128kb/s uplinku ADSL telecomu představuje nezanedbatelnou dobu.) Bude zadání tedy požadovat asychnronní vláknově bezpečné rozhraní, nebo ne? Problém může být s vláknovou bezpečností, protože třeba libcurl může být slinkovaná proti kryprografickým knihovnám, které nejsou připraveny na vlákna.