Michal Čihař - Archive for 2/2008

Na co vůbec je SSL a podepisování?

Když dnes kolegovi přišel nepodepsaný email od UPC s žádostí o posílání peněz na jiný účet, tak jsme se začali zabývat jak to vlastně v Česku funguje s elektronickým podepisováním. Napsat mezitím email všem klientům UPC s žádostí, aby peníze posílali na můj účet, je lákavá možnost :-).

Po asi pěti minutách člověk zjistí, že i jinde se jaksi na zabezpečení moc nehraje. Chcete vědět jak nainstalovat certifikát certifikační autority, kterým je podepsaný certifikát elektronického bankovnictví? Stačí si přečíst návod na stránkách banky :

Certifikát lze stáhnout a nainstalovat zde: http://www.ica.cz/RootCERT_NewSica.cer a následně jej nainstalovat dvojklikem.

Prostě nic nezkoumejte, všechno odklikejte a bude to. Ale třeba to má ona certifikační autorita popsané lépe, tak se podíváme na její stránky. Omyl, instalaci certifikátu nám provede jakýsi program pro Windows , který vše automaticky bez jakékoliv možnosti ovlivnění uživatelem provede.

U České spořitelny je certifikát pro bankovnictví podepsán Verisignem, takže aspoň má člověk celkem slušnou jistotu, že už tuto certifikační autoritu má ověřenu. Ovšem emaily jimi posílané už jsou podepsané certifikáty od jejich vlastní certifikační autority a přes veškerou snahu se mi nepodařilo najít jak by si její certifikát podle banky měl člověk nainstalovat. Nicméně po přepsání URL z http na https má člověk možnost získat tento certifikát celkem bezpečnou cestou.

Další instituce se mi už ani nechtělo zkoumat...

Jak na debianí balíčky?

Tak jsem se nechal přemluvit k napsaní seriálu o tvorbě balíčků pro Debian. Protože je přeci jen dělám už nějaký ten pátek, tak už jsem asi zapomněl na některé věci, na které jsem v začátcích narazil. A proto jsem se rozhodl napsat tento zápisek :-). Pokud jste měli (nebo máte) s něčím problémy při vytváření balíčku pro Debian, napište to do diskuze, za odměnu se vám pokusím nabídnout co nejlepší odpověď ve vznikajícím seriálu.

PS: Když mi Robert poprvé napsal, tak jsem moc netušil co psát. Teď už se blížím třinácti dílům, takže si myslím, že se máte na co těšit :-).

Znakové sady v MySQL a phpMyAdminovi

MySQL od verze 4.1 podporuje nativně práci s různými znakovými sadami. Bohužel mnoho aplikací a dat v databázích vzniklo dříve a tuto podporu nevyužívají. Pak se uživatel může potýkat s mnoha problémy. Dnes se podíváme na to, jak ty nejčastější vyřešit.

MySQL a znakové sady

Ve verzi 4.1 přibyla v MySQL podpora pro znakové sady a řazení. Ty se nastavují v několika úrovních – výchozí pro server, databázi a tabulku a nastavení pro jednotlivé sloupce. Pokud máme databáze ze starší verze MySQL, nemají přiřazen žádný způsob řazení a použije se výchozí pro server. Výchozí pro MySQL je latin1_swedish_ci , což je pro české podmínky poněkud nevhodné. Jméno řazení se skládá ze tří částí oddělených podtržítkem – první určuje znakovou sadu, druhá jazyk a třetí variantu porovnáván. Varianty porovnávání jsou tři:

ci
case insensitive – nerozlišuje velikost písmen
cs
case sensitive – rozlišuje velikost písmen
bin
binary – řadí podle hodnoty znaku a ne lexikograficky

Pro češtinu máme k dispozici tyto varianty: ucs2_czech_ci, utf8_czech_ci, cp1250_czech_cs, latin2_czech_cs.

Podpora znakových sad v phpMyAdminovi

Do phpMyAdmina přibyla podpora tyto vlastnosti MySQL ve verzi 2.6.3. Nastavit můžete výchozí porovnání pro databázi , tabulku a stejně tak i pro jednotlivé sloupce, které vidíme na přehledu tabulky .

Na úvodní stránce si také můžeme vybrat porovnávání použité pro zobrazování výsledů, ale použitá znaková sada bude vždy utf-8, protože stránky phpMyAdmina jsou v utf-8.

Co dělat když je něco špatně?

Pokud se nám některé znaky zobrazují v phpMyAdminovi špatně, je chybně nastavená jejich znaková sada. Znakovou sadu není možné měnit v přímo, protože MySQL server pak provede konverzi dat mezi těmito znakovými sadami a data budou nejspíš nenávratně poškozena! Pokud chceme jen změnit znakovou sadu sloupce, musíme ho nejprve převést na binární hodnotu (tedy na pole typu BINARY/VARBINA­RY/BLOB odpovídající CHAR/VARCHAR/TEXT) a pak zpět na původní typ jen s jinou znakovou sadou. Takto zůstanou data v nezměněné podobě a jen se změní znaková sada.

Po této změně je ale možné, že používané starší aplikace budou mít problém zobrazit správně data. Aplikace totiž bez explicitního určení znakové sady dostávají data ve výchozí znakové sadě serveru (což je latin1). Pokud k aplikaci máme zdrojové kódy, stačí hned za připojení k MySQL přidat SQL příkaz SET NAMES 'znaková sada' . Ten zajistí, že MySQL server bude posílat data ve znakové sadě, kterou aplikace používá. Pro češtinu máme opět čtyři možnosti: utf8 , latin2 , cp1250 a ucs2 .