haladtam egy kicsit a core feature-okkel, es most a levelek integritas ellenorzese van soron. Ez a hsz amolyan hangosan gondolkodas, ill. brainstormingra felhivas.
Az egyes levelekhez kulonfele metaadatok tartoznak, pl. meret, felado, datum, digest, stb. Minden levelhez eltarolok egy ellenorzo digest-et, ami az elobbi adatokbol all elo. Ennek az a funkcioja, hogy ellenorzi, hogy a level valoban ugyanaz-e, mint ami a beerkezeskor es archivalaskor volt.
Ez a paranoia fokatol fuggoen lehet eleg vagy eppen keves. Egy rosszindulatu es elszant rendszergazdatol ennyi meg nem fog megvedeni, aki full root hozzaferessel akar modosithatja is a leveleket, majd az ellenorzo hash-eket is az algoritmus birtokaban (ami egy nyilt forrasu termek eseten nem titok).
Egy masik topikban mar toprengtem egyet a probleman, es az alabbi 2 megoldas johet szoba:
a) minden egyes levelhez tartozo ellenorzo digest-et nem csak az adott level metaadataibol allitom elo, hanem beleveszem az elozo 2 levelhez tartozo ellenorzo digest-et is. Igy egy adott levelet nem lehet ugy modositani, hogy az utana kovetkezo leveleknel ez ne bukjon ki.
b) minden oraban kigyujtom a levelek ellenorzo osszegeit, egy digest-et keszitek belole, majd alairatom egy kulso 3. fellel.
Az a) hatranya, hogy nagyobb forgalmu site-on race condition allhat elo, azaz mivel tobb processz is irja a metadata tablat, ezert siman elofordulhat, hogy az x-dik level ellenorzo osszegenek elkeszitesehez meg eppen fut az sql select, amikor mar beesik az x+1-dik level is, es lekerdezi az x-dik level ellenorzo osszeget a sajatja eloallitasahoz, de az x-dik levelnel meg NULL van, igy az x+1-dik level ellenorzo osszege hibas adaton alapul, ami boritja a koncepciot.
Megoldas lehet az, ha egy kulso processz kesziti el az ellenorzo osszegeket, igy nincs race condition, de ez nem valami elegans, es bonyolitja a kepletet. Bar egy pl. 5 percenkent futo cron script akar meg beleferhet.
Viszont tovabbra is kerdes, hogy a gyakorlatban hany levelnyit kell visszamenni, es ellenorizni, hogy meg ott is jo-e az ellenorzo osszeg (emlekszel: lancban vannak az ellenorzo osszegek).
A b) megoldas hatranya, hogy egy "korrekt" TSA szolgaltato nem puszira adja a belyegeket, hanem azert bizony penzt kell csengetni, ami egy koltseghatekony helyen szempont lehet. Mondjuk kerdes, hogy nekik valoban kell-e ilyen foku paranoia. Mert pl. egy penzugyi cegnel sanszos, hogy igen, de ott valoszinuleg meg van ra a penzugyi keret is.
Szinten a b) megoldas ellen szol, hogy egy adatcsere a TSA szolgaltatoval (protokoll szinten) azert nem trivialis. Az openssl tamogatja ezt (de csak az 1.x-tol kezdve) ugy, hogy cmd line kell ugyesen felparameterezni (mert API-bol nem tamogatja ezt a feature-t), es hadd szoljon, ami azert finoman szolva nem ugyes megoldas egy C-ben irt program eseten. Itt is ugy lehet ezen a banto ponton enyhiteni, ha pl. egy cron script vegzi az orankenti belyegzest.
Viszont nem csak kereskedelmi TSA-k vannak, hanem free "belyegzok" is, pl. http://ecrive.net/. Ezeknel a koltseg nem szempont, viszont cserebe semmit nem garantalnak (pl. SLA, az idobelyeg idejenek pontossaga, megvesztegethetetlenseg, stb.)
Szoval azon tunodok, melyik utat valasszam: a), b) esetleg c)? Egyelore a b) megoldas tunik szimpatikusnak az ecrive (vagy mas) free TSA szolgaltatoval. Az is megfordult a fejemben, hogy csinalok en magam egy "free TSA"-t, de a felmerult dilemmak vs. garanciak ebben az esetben sem tunnek el, sot egy fokkal tan meg erosebbek is lennenek...
Ne bohockodjatok nagyapaval! Avagy az alkotmicsoda asztalara