Migrace z kwalletmanager na KeePassX

17.8.2014 22:42 | Přečteno: 2486× | programování | | poslední úprava: 17.8.2014 22:50

Kwalletmanager je už jistý čas nedoporučován, protože starší verze de-facto používali ECB mód šifry Blowfish. KeePassX je mnohem lépe navržen a napsán, ale migrace z kwallet není už dlouho podporována, protože kwallet změnil export formát. Návod s krátkým skriptem na migraci.

Jádro problému

Už nějaký čas jsem chtěl odejít od kwalletmanageru, protože až na nějaké poslední verze používá na šifrování Blowfish v ECB módu. To není úplně tragické a až tak lehce zneužitelné, ale od doporučovaných praktik to má taky daleko. KeePassX má v menu možnost importovat password xml, který byl exportován z kwalletmanageru - ale podporuje jen nějaký velmi starý formát. Šlo by to řešit přes XSLT, ale debugovat XSLT je čirý masochizmus, raději jsem si na to napsal krátký pythoní skript. Naimportuje skupinu pod "Passwords", ale podle fór je to právě ta skupina, která většinu lidí zajímá.

Export, import a skript

V kwalletmanageru zvolíme File-Export, uložíme např. do export.xml, pustíme na to skript. Ten nám vyplivne import.xml, který již lze naimportovat do KeePassX přes File-Import From-KWallet XML File. Na exportovaném XML z kwalletmanageru pustíme:

kwallet2keepassx_kwallet.py export.xml import.xml

Skript

#!/usr/bin/env python
import sys
from lxml import etree

"""
Transformation according to https://www.keepassx.org/forum/viewtopic.php?f=4&t=1892
"""

if len(sys.argv) < 3:
    print >> sys.stderr, "Usage: kwallet2keepassx_kwallet.py source_kwallet.xml dest_keepass_kwallet.xml"
    sys.exit(1)

srcFname = sys.argv[1]
dstFname = sys.argv[2]

doc = etree.parse(file(srcFname))
root = doc.getroot()
newRoot = etree.Element("wallet")
newRoot.attrib["name"] = root.attrib["name"]

passwords = root.xpath("/wallet/folder[@name='Passwords']")[0]
maps = passwords.xpath("map")

for map in maps:
    name = map.attrib["name"]
    folderElem = etree.Element("folder")
    folderElem.attrib["name"] = name
    newRoot.append(folderElem)

    entries = map.xpath("mapentry")
    for entry in entries:
        passwordElem = etree.Element("password")
        passwordElem.attrib["name"] = entry.attrib["name"]
        passwordElem.text = entry.text
        folderElem.append(passwordElem)

with file(dstFname, "w") as fout:
    fout.write(etree.tostring(newRoot, pretty_print=True))

KeePassX backendy

Dost by mně zajímalo, jestli lze jednoduše doplňovat do KeePassX backendy pro ukládání/šifrování dat. Z googlení ani ze zdrojáků mi odpověď na tuto otázku není příliš jasná. Chtěl bych použít Trezor jako šifrovací backend, ale zatím to vypadá, že k tomu budu muset napsát kompletní password manager.

Bonus: hraní s ECB

Vyšlo nové číslo časopisu PoC||GTFO 0x05, které ukazuje mnohem lépe úskalí ECB než známý Tux obrázek na Wikipedii. Jinak všimněte si, že to PDF je zárověn PDF, flash, ZIP, ISO 9660 filesystem a další formáty.

       

Komentáře

[xkucf03]

Tady máš to XSLT ty masochisto

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:output method="xml" indent="yes" encoding="UTF-8"/>

		<xsl:template match="/">
			<wallet name="{wallet/@name}">
				<xsl:for-each select="/wallet/folder[@name='Passwords']/map">
					<folder name="{@name}">
						<xsl:for-each select="mapentry">
							<password name="{@name}"><xsl:value-of select="text()"/></password>
						</xsl:for-each>
					</folder>
				</xsl:for-each>
			</wallet>
		</xsl:template>

</xsl:stylesheet>

[mirec]

Až toto je pravý masochizmus.

import sys
from lxml import etree
from lxml.builder import E

in_root = etree.parse(sys.stdin).getroot()
out_root = E.wallet(
	name=in_root.attrib['name'],
	*(E.folder(name=el.attrib['name'],
		*(E.password(entry.text, name=entry.attrib['name']) for entry in el.iter('mapentry'))
	) for el in in_root.iterfind(".//folder[@name='Passwords']/map"))
)

sys.stdout.write(etree.tostring(out_root, pretty_print=True))

[xkucf03]

jj, masochismus – sice je to o čtyři řádky kratší, ale o poznání méně čitelnější. V tom XSLT je krásně vidět struktura výsledku.

[pavlix]

Když jsem si naposled hrál hodiny s vypilováním XSLT, tak jsem to taky nakonec splácal v Pythonu za deset minut a to, že v kódu nevidím strukturu výsledku mi bylo úplně jedno.

P.S.: Ten sraz jsem fakt nedával, snad příště.

[mirec]

Keď sa to dá je to fajn. Ja mám ešte doteraz nočné mory z toho keď som musel nútene používať xslt na importné / exportné filtre z / do openoffice. Nikomu nepreajem riešiť tak hnusné veci ako opakovanie riadkov / stĺpcov v libreoffice calc tabuľkách (v xslt sa to rieši rekurziou a to v prípade že sa opakujú riadky aj stĺpce tak pekne vnorenou). Čitateľnosť 0 bodov pričom v normálnom jazyku by sa do dalo poriešiť 3 riadkanmi namiesto tej 50-riadkovej príšery ktorú som do každého filtra pastoval.

[mirec]

Inak offtopic práve ten lxml.builder je na to aby bolo vidieť štruktúru, akurát je som to šialene skombinoval s funkcionálnym zápisom čo je síce krátke ale málo čitateľné. Inak samotný zápis pomocou builderu mi pripadá ľahší než čisté xml (požičané z oficiálnej dokumentácie):

page = (
    E.html(
        E.head(
            E.title("This is a sample document")
        ),
        E.body(
            E.h1("Hello!", CLASS("title")),
            E.p("This is a paragraph with ", B("bold"), " text in it!"),
            E.p("This is another paragraph, with a ",
                A("link", href="http://www.python.org"), "."),
            ...
        )
    )
)

[xkucf03]

Jak do toho zakomponuješ třeba cykly nebo nějaké větvení?

[mirec]

Python má kľúčové slová for (teda na rozdiel od xslt kde sa to rieši rekurziou), if, else ... V príklade som naschval použil funkcionálny zápis, ale v pythone nie je problém kombinovať rôzne spôsoby zápisu. Tu je čistý imperatívny zápis (rozsekané na funkcie tak aby to pripomínalo xsl:apply-templates:

Wallet = E.wallet
Folder = E.folder
Password = E.password

def apply_mapentry(in_node):
    password_elements = []
    for entry in in_node.iter('mapentry')
        password = Password(entry.text, name=entry.attrib['name'])
        password_elements.append(password)
    return password_elements

def apply_map(in_node):
    folder_elements = []
    for map_element in in_node.iterfind(".//folder[@name='Passwords']/map"):
        folder = Folder(name=map_element.attrib['name'], *apply_mapentry(map_element))
        folder_elements.append(folder)
    return folder_elements

root = Wallet(name=in_root.attrib['name'],
    *apply_map(in_root)
)

Kombinovaný zápis:

Wallet = E.wallet
Folder = E.folder
Password = E.password

def apply_mapentry(in_node):
    entries = in_node.iter('mapentry')
    return [Password(entry.text, name=entry.attrib['name']) for entry in entries]

def apply_map(in_node):
    entries = in_node.iterfind(".//folder[@name='Passwords']/map")
    return [Folder(name=entry.attrib['name'], *apply_mapentry(entry)) for entry in entries]

root = Wallet(name=in_root.attrib['name'],
    *apply_map(in_root)
)

No a pomerne hustý skôr funkconálny zápis

Wallet = E.wallet
Folder = E.folder
Password = E.password

maps = in_root.iterfind(".//folder[@name='Passwords']/map")
root = \
    Wallet(name=in_root.attrib['name'],
        *(Folder(name=entry.attrib['name']
            *(Password(m.text, name=m.attrib['name']) for m in entry.iter['mapentry']
        for entry in maps)
    )

[xkucf03]

Python má kľúčové slová for (teda na rozdiel od xslt kde sa to rieši rekurziou)

XSLT má FOR cyklus – viz příklad výše: #1, stejně tak má IF, ELSE…

Ano, rekurze se taky dost používá a stylem se to podobá spíš funkcionálnímu programování, ale to neznamená, že by tam chyběly FOR cykly a podobné věci.

Tu je čistý imperatívny zápis … Kombinovaný zápis: … No a pomerne hustý skôr funkconálny zápis

Sorry, ale rozluštit tohle a zjistit, co to vlastně dělá (kdybych neviděl ty předchozí příklady, neznal zadání) je o hodně těžší než u toho XSLT, u kterého prostě koukneš a vidíš. To už i ta implementace v zápisku výše je srozumitelnější.

To, že stačí napsat E.názevElementu( a na konci jen závorku místo <názevElementu></názevElementu>, tak najednou nějak bere za své a ztrácí se v ostatním kódu. To už mi spíš přijdou zajímavější jazyky, které umí XML literály.

To Password = E.password a pak jeho opakované použití Password(entry.text, name=entry.attrib['name']) působí, jako by to byla spíš jen nějaká funkce, která escapuje vstup a produkuje text. Proč je funkce jednou malými písmeny, pak velkými a malými je zase název proměnné…?

A co jsem koukal na podporu jmenných prostorů v té knihovně, tak to už je dokonalé zatemnění a odstínění programátora od podstaty věci, tak aby na první pohled nebylo vůbec zřejmé, co se děje uvnitř, o několik vrstev níž. A to tu někteří vyčítali Javě, že prý se tam používá moc vrstev a abstrakce!

[mirec]

V príklade je for-each. Ja myslím niečo typu:

for i in 1..10:
    zapisPrazdnyTag

Tu je príklad v xslt:

<xsl:template name="repeatcol">
    <xsl:param name="current"/>
    <xsl:param name="from"/>
    <xsl:param name="to"/>
    <xsl:apply-templates select="table:table-cell[position()=$current]">
        <xsl:with-param name="current" select="$from - 1"/>
    </xsl:apply-templates>
    <xsl:if test="$from < $to">
        <xsl:call-template name="repeatcol">
            <xsl:with-param name="current" select="$current"/>
            <xsl:with-param name="from" select="$from + 1"/>
            <xsl:with-param name="to" select="$to"/>
        </xsl:call-template>
    </xsl:if>
</xsl:template>

<xsl:template name="processnextcol">
    <xsl:param name="nextCol"/>
    <xsl:param name="colNum"/>
    <xsl:if test="table:table-cell[position()=$nextCol]">
        <xsl:choose>
            <xsl:when test="table:table-cell[position()=$nextCol]/@table:number-columns-repeated">
                <xsl:variable name="colSkip" select="table:table-cell[position()=$nextCol]/@table:number-columns-repeated" />
                <xsl:call-template name="repeatcol">
                    <xsl:with-param name="current" select="$nextCol"/>
                    <xsl:with-param name="from" select="$colNum + 1"/>
                    <xsl:with-param name="to" select="$colNum + $colSkip"/>
                </xsl:call-template>
                <xsl:call-template name="processnextcol">
                    <xsl:with-param name="nextCol" select="$nextCol + 1"/>
                    <xsl:with-param name="colNum" select="$colNum + $colSkip"/>
                </xsl:call-template>
            </xsl:when>
            <xsl:otherwise>
                <xsl:apply-templates select="table:table-cell[position()=$nextCol]">
                    <xsl:with-param name="current" select="$colNum"/>
                </xsl:apply-templates>
                <xsl:call-template name="processnextcol">
                    <xsl:with-param name="nextCol" select="$nextCol + 1"/>
                    <xsl:with-param name="colNum" select="$colNum + 1"/>
                </xsl:call-template>
            </xsl:otherwise>
        </xsl:choose>
    </xsl:if>
</xsl:template>

A ešte ako sa to používa:

<xsl:template match="table:table">
    <xsl:for-each select="table:table-row">
        <object>
            <xsl:call-template name="processnextcol">
                <xsl:with-param name="nextCol" select="1"/>
                <xsl:with-param name="colNum" select="1"/>
            </xsl:call-template>
        </object>
    </xsl:for-each>
</xsl:template>

Často to je potrebné pre filtre v openoffice kde prázdne bunky v tabuľkách zlučuje do jednej a prihodí do atribútu počet opakovaní. Potom treba v xslt podľa toho atribútu opakovať prázdny tag niekoľko krát.

Takže aby som to zhrnul áno xslt je na niektoré veci jednoduché. Ale na zložitejších úlohách si jednoducho človek zodrie prsty alebo sa zblázni kým napíše čo potrebuje.

Proč je funkce jednou malými písmeny, pak velkými a malými je zase název proměnné…?

Password je čiastočne aplikovaný konštruktor triedy Element. Používa sa ako trieda a tie majú názvy veľkými písmenami aby sa dali ľahko odlíšiť of funkcií).

[xkucf03]

Trochu mi to připomíná situaci u ORM frameworků používaných lidmi, kteří mají ze SQL strach (čti: nikdy se ho nenaučili) a považují ho za „příliš nízkoúrovňové“ a „potřebují“ ho zabalit do dalších vrstev a schovat se před ním. Nejlépe pomocí nějakého frikulínského hipsterského frameworku, který jim vygeneruje vše od HTML formulářů po CREATE TABLE skript a oni s tím „ošklivým SQL“ nebudou muset přijít do styku. Používat ORM bych doporučil jen lidem, kteří napsali několik aplikací s čistým SQL a ovládají ho – pak je ORM (nebo podobná abstrakce) dobré, ale i tak je potřeba pečlivě volit framework a používat ho s mírou.

[mirec]

Otázka je čo získam vyhodením ORM? Nedávno som pár aplikácií prepisoval z čistého SQL do ORM pretože sme potrebovali robiť pomerne zložité joiny nad tabuľkami a všetky dotazy boli písané na MySQL. Prepisom sa na výkone nezmenilo nič (dotazy sú približne rovnaké ako keby ich písal človek), ale umožnilo nám to migrovať z smerom mysql -> postgresql (potenciálne) -> oracle

A nie nepatrím medzi ľudí ktorí by sa báli SQL. Písal som pár vecí s MySQL (vcelku výkonných) a potom veľa veľa vecí na postgrese (nedávno som dopisoval stemmer na sk jazyk pre fulltext vyhľadávanie). Keď potrebujem rýchlo získať nejaké výsledky tak to riešim priamo cez SQL dotazy v postgresql konzole. Takže rozhodne sa SQL nebojím, ale keď ide o možnosti migrovať na iný typ db tak je ORM neprekonateľné.

Nejlépe pomocí nějakého frikulínského hipsterského frameworku, který jim vygeneruje vše od HTML formulářů po CREATE TABLE

Nevidím nič čo je na tomto zlé. Framework v ktorom píšem aplikáciu musí poznať model, prečo by teda nemohol rovno vygenerovať CREATE TABLE? DRY považujem jeden z najdôležitejších princípov pri programovaní. Generovanie formulárov ... zase DRY, prečo by som mal mať definovanú štruktúru tabuľky na 3 miestach (sql, kontroler a prezenter keď je to možné mať na jednom mieste?

[pavlix]

Otázka je čo získam vyhodením ORM?

Vzhledem k tomu, že Franta navrhoval jen seznámit se s SQL, tak tím získáš především znalost toho, co se na pozadí děje. Ta je v SQL aplikacích naprosto klíčová a důsledky neznalosti potkáš na každém rohu, když na triviální výstup z databáze na nějakém cizím webu čekáš dlouhé minuty.

[mirec]

To neodpovedá na otázku. SQL ovládam na veľmi dobrej úrovni, písal som veľa vecí v RAW SQL, veľa procedúr, veľa šialených selectov, ale ORM používam kvôli flexibilite. Teraz nehovorím, že utekajme sa všetci učiť ORM, SQL treba ovládať, treba rozumieť explain analyze, treba vedieť logike ktorá je za tým, treba vedieť ako z ORM vypísať RAW query ktorú robí, treba vedieť akým spôsobom sú query skladané, aké to má výhody, nevýhody ... lebo zlými selectmi nad veľkou databázou si človek kľudne zostrelí server.

Ako príklad uvediem ORM z djanga (robím aj s inými ORM ale toto je také nablbšie a asi ho mám aj najradšej). Ak mám nejakú tabuľku s foreign key tak môžem kľudne urobiť objekt.fk_tabuľka.atribút a ORM za mňa urobí selekt. Ak to urobím v cykle tak si koledujem o pekný prúser lebo pre každý záznam urobí select. Ak ale urobím ZakladnaTabulka.objects.select_related("druha_tabulka") tak ORM za mňa urobí left join (teda v tomto prípade, ak je to many to many alebo niečo iné tak iný join) a môžem kľudne hrabať na atribúty spojenej tabuľky bez ďalších selectov. Na prvý pohľad znie ako dobrý nápad ... lenže joiny sú pri veľkých offsetoch so stránkovaním dosť neohrabané. Takže Django ORM má na to ešte jednu peknú metódu a to prefetch_related("druha_tabulka") čo mi pri výpise ak dám zobraziť povedzme 20 riadkov z offsetom 1 000 000 selektne len prvú tabuľku a z druhej tabuľky urobí select ... where id in(...) a spojenie prebehne len na vybraných 20 riadkoch v knižnici. Aj s ORM treba mať základy databáz a algoritmov ktoré za tým sú aby človek vedel vybrať správny spôsob prístupu k dátam. No a samozrejme ak to nejde inak tak tie kritické časti prepísať do RAW query.

Osobne som toho názoru že každý programátor by mal ovládať rôzne paradigmy a rôzne jazyky. Nezameriavať sa na jeden konkrétny pretože je najpoužívanejší a má najelpšie toto / tamto. Nie je jediná správna(tm) cesta. Ja sám píšem aktívne v asi 5 jazykoch a ďalších možno 10 ovládam ako-tak.

[pavlix]

Otázka samotná byla mimo kontext a vypadalo to, že jsi Frantu jen špatně pochopil.

[mirec]

No celé to o ORM je úplne mimo kontext , vlastne ani neviem prečo sa to tu objavilo keďže ja ovládam xslt, sql a dokonca aj javu, snažím sa len korigovať bezdôvodné kydanie nezmyslov na účet pythonu a ignorovanie nedostatkov javy (napr. nekompletná typová kontrola, ukecanosť ...) / xslt (neohrabanosť v niektorých situáciách) / sql (neflexibilita v niektorých situáciách) ...

[Bedňa]

Keď sa rozhodujem nasadiť databázu, tak je to rýchlosť. Netuším čo je to ORM (ORgasM?), keď som niekedy bol v koncoch snažil som sa hľadať nástroje ktoré mi uľahčia prácu a dokážu za mňa vypľuť SQL ktorý vložím do kódu. Či už išlo o klikátka, alebo to z "čitateľného" kódu vypľulo SQL, nakoniec som nikdy nič také nepoužil a Google dáva asi najlepšie výsledky :) Teda pre mňa SQL=rýchlosť a neviem si predstaviť, že by som tam pchal nejakú medzivrstvu.

[mirec]

Na rýchlosti medzivrstvy málokedy záleží. Osobne píšem webové aplikácie v jazyku rádovo 100x pomalšom než C a rozdiel oproti iným jazykom je takmer 0 pretože väčšinu času aplikácia len čaká na dokončenie dotazu. Len pre zaujímavosť mám tu teraz jednu peknú pár GB veľkú databázu a skúsil som selectnúť 500 000 záznamov pomocou ORM a pomocou obyčajného selectu cez psql. Pre postgresql je čas:

Time: 371,725 ms

a django ORM

937 ms

Takže s jazykom s fakt mizerným výkonom (dokonca bez použitia JIT) dokážem po odrátaní času selectu spracovať 900k záznamov čo za predpokladu že na zobrazenie bežne webovej stránky stačí tak 100 záznamov postačuje na približne 9 000 requestov za sekundu na worker.

[mirec]

Ešte doplním že ORM sa nepoužíva ako náhrada SQL tam kde sa mi to nechce písať. Je to nástroj pomocou ktorého sa dajú robiť veci, ktoré by sa inak realizovali ťažko. Pred 5 minútami som napr. migroval databázu na iný stroj (iný typ databázy). Prešlo to hladko a bez problémov pretože rozdiely medzi databázami vyriešilo ORM. Ak by som išiel cez raw query musel by som teraz polovicu aplikácie prepisovať.

[xkucf03]

Tak jsem to myslel. Obecně jsem spíš pro ORM. Ale je třeba ho chápat jako nástroj, který ti zrychlí a zefektivní vývoj¹, ne jako nástroj, který má umožnit práci s databází lidem, kteří neumí SQL. Pokud SQL umíš a víš/tušíš, co se uvnitř ORM děje, tak ho klidně použij – v opačném případě je to dost nebezpečná zbraň, kterou se spíš střelíš do nohy.

_{[1] vývoj, ne běh programu – celé to může být o trošku pomalejší než ručně psané a precizně optimalizované SQL, ale měl bys mít méně kódu a flexibilnější systém, takže bys měl rychleji nasazovat změny, nové požadavky}

[Ivan]

Zrovna JPA (Hibernate popr. EclipseLink) je extremne nebezpecna zbran. Entity framework nedela jen SELECTy. Staci napsat: b=a; b.append('X'); a=b; A EclipseLink vyhodi naprosto kryptickou vyjimku, protoze EntityManager nechape o co mi jde, zatimco Hibernate smaze tisice radek z databaze protoze "a" byla child collection. ORM micha dobromady deklarativni SQL s imperativni Javou. Relacni model s objektovym, a navic pridava princip "vlastnictvi" do jazyka, krety ma GC a ve kterm se nikdy predtim vlastnictvi objektu neresilo.

[Marián Kyral]

Takový problém opravit zdrojáky a poslat patch?

[xkucf03]

Důležitá vlastnosti Kwalletmanageru je integrace s desktopem, přejít jinam bez ztráty pohodlí moc nejde, takže bych se spíš snažil o vylepšení tohoto programu než migraci jinam.

Hlásil jsi to jako chybu? Není to už v jejich bugzille nahlášené? Stejně se o to šifrování nebude starat Kwalletmanager sám, ale bude používat nějakou knihovnu, kde ta lepší šifra s velkou pravděpodobností bude – takže oprava může být klidně jen na pár řádků nebo změna jedné konstanty + je potřeba udělat jednorázovou proceduru pro převod stávající klíčenky do nového formátu.

[Václav "Darm" Novák]

Dulezita veta v blogpostu byla "az na posledni verze". Kdyz se v poslednich verzich KDE poprve spusti kwallet, umoznuje uz i GnuPG backend a blowfish oznacuje jako deprecated. Takze mi duvod exportovat ho do keepasx z duvodu slabe sifry unika :)

[Václav "Darm" Novák]

Teda, "protoze starsi verze"

[limit_false]

Ne všechny distra mají k dispozici opravenou verzi kwalletmanageru, např. Scientific Linux 6.

[Václav "Darm" Novák]

Pak bych si asi našel repo s posledním KDE, nabídl patch, nebo alespoň otevřel v bugzille feature request na backport GnuPG backendu.

[Bedňa]

Ako píšu aj predrečníci, dopísanie soli k heslu bude otázka pár riadkov kódu. Inak za toto by si autori zaslúžili ...

V KeePassX vidím že to šifruje AES 256bit, ale niekde nevidím či nieje použitý ECB, alebo CBC, takže môžeš skončiť tam kde si.

[Šangala]

Je potřeba soubor(y) od KeePassX dát do EncFS a ten mít na LUKS partition a přístupný na serveru jen z localhost-u, ke kterému se z venku dostaneš jen přes dva SSH tunely realizovatelné jen přes klíč…

[Šangala]

A kuk: The block ciphers are used in the CBC (cipher-block chaining) block cipher mode. In CBC mode, plaintext patterns are concealed.

[Šangala]

A vidím, že jsem se už jako několikrát spletl - sorry (špatný odkaz na jiný SW).

[Bedňa]

Sa stane :) Mno tento aspoň transparentne používa CBC.

[Šangala]

On asi KeePassX taky, bo v repozitáři-testech se zmiňuje CBC.

[Šangala]

A pokud by neměla tak zpět ke správnému zabezpečení.

[lertimir]

O jakých verzích se tu vlastně mluví? KDE 4.11 v openSUSE 13.1 má kwalletmanager 1.10. Je "stará verze" nebo "až na poslední verze"?

[Václav "Darm" Novák]

Ve 4.13 je určitě. Osobně používám 5.1

[lertimir]

5.1 je poměrně zvláštní číslo, když odkaz na kwalletmanager obsahuje něco zcela jiného. Není to číslo nějaké knihovny?

[Václav "Darm" Novák]

Ano, pardon balíček kwallet (kwallet framework)