Qt bude používat engine z Chromia namísto WebKitu

Poté, co projekt Chromium vytvořil fork WebKitu pod názvem Blink, řešili vývojáři Qt otázku, který z těchto enginů by se měl používat v Qt. Nakonec se rozhodli pro Blink, který bude v Qt k dispozici pod názvem Qt WebEngine.

12.9.2013 14:27 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[Jakub Lucký]

Takže Google udělal fork Webkitu a všichni teď přejdeme na Blink a necháme Webkit umřít?

[Rezza]

Pak se zase pripoji Apple a budou na zacatku .

[kavol]

s/Apple/KDE e.V./

[Rezza]

Myslim ted Apple - je to o tom, ze Apple s Google spolecne na WebKitu nedokazou spolupracovat (a chvili jsem byl ve WebKit security teamu). Ale rozumim tve KDE historii.

[Anon]

Kdyby radši ty idioti přispěli k fungování Gecka pod Qt...

[jiri.one]

Přesně tak, to bych taky ocenil.

[tom]

V KDE3 byla Gecko KPart, mozna by stacilo to ozivit.

[Jardík]

Webkit je naho*no, vždyť webkit ani nemá api na správu ssl certifikátů a používá to systémové certifikáty (tuším) přes curl a je to hardcodovaný a nejde to změnit.

[Jardík]

BTW chromium používá webkit1, který není multiproces a řeší si multiproces po svým, webkit má 2 api, webkit1 a webkit2, webkit2 je multiproces a async api, znamená to, že blink bude jen jedno sync api a bude zdržovat?

[Vladimír Čunát]

Možnost zvolit odkud se berou systémové certifikáty? To zní spíš jako otázka pro tvůrce balíčků.

[Jardík]

Co má s tím společného tvůrce balíčků? Ano, čte se to ze systémového adresáře, jde to změnit pro celý systém, ale to je prd platné uživateli, který systémové certifikáty nepovažuje za důvěryhodné a chce si to nastavit pro sebe jinak.

[Lol Phirae]

Používání nativní správy certifikátů v systému je jediná správná možnost. Na ten nespravovatelný mrdník zcela mimo systém, co si vyrobila Mozilla, opravdu není nikdo příčetný zvědavý.

[Jardík]

Proč by to měla být jediná správná možnost? Proč by měl správce systému nutit uživatele věřit nějaké CA, které nevěří? Např. taková NSA by ráda, abyste věřili Google CA, zaplatí např. Frantovi Vopršálkovi, aby dával na svoje systémy Google CA certifikáty, aby mohli MITM Jardíka, který pracuje na tom systému. Ano?

Navíc, pokud mi program umožňuje přidat výjimku a věřit tak certifikátu (to webkit dělá), proč mi neumožní přidat výjimku a nevěřit CA? Jediný důvod je, aby byl usnadněn MITM, protože důvěřováním každému certifikátu přidáním výjimky si o MITM říkáte, ale odebíráním důvěry o MITM přicházíte.

[Lol Phirae]

Ano, a Mozilla je ráda, když budeš věřit soudruhům z CNNIC. Jak již bylo napsáno výše, pokud tvoje distribuce neumí konfigurovat certifikáty pro jednotlivé uživatelské účty, běž si zafňukat ke správcům balíčků.

[Jardík]

To není o tom, že to neumí distribuce, ale o tom, že je v nějakým openssl či gnutls hardcódovaná jedna cesta na systémový adresář a vůbec se to nedívá na konfiguraci uživatele. Pak se to řeší hackama v aplikacích typu "ignorovat rozhodnutí openssl/gnutls a přijmout certifikát". Chyba není v distribuci, ale již v samotných knihovnách.

[Jardík]

... a pak tedy taky v té aplikaci, co dané knihovny používá, přesto že to její vývojář ví a nezvolí lepší alternativu (napsat si to sám )

[Honza Jaroš]

No nevím jak u gnutls, ale v openssl to evidentně hardcodované není:

jerry@tom ~ $ OPENSSL_CONF=/pokus.cnf openssl
WARNING: can't open config file: /pokus.cnf
OpenSSL> ^C

(testováno na aktuálním Gentoo)

[Jardík]

Hmm, urobil jsem tedy ~/.config/ssl/openssl.cnf, pak ~/.config/ssl/certs, zkopíroval jsem do .config/ssl skript update-ca-certificates, změnil v něm cesty, aby generoval do .config/ssl/certs a četl nastavení z .config/ssl/ca-certificates.conf, nechal na zkoušku jeden CA, spustil update-ca-certificates, vygenerovalo mi to příslušné soubory v .config/ssl/certs, v openssl.cnf mám nastavenu cestu do toho adresáře.

A teď hlaví problém ... jak přesvědčím třeba Qupzillu, co používá QtWebKit, co používa Qt, co používá OpenSSL pro SSL ... aby četla z .config/ssl/openssl.cnf. OPENSSL_CONF to ignoruje.

[Honza Jaroš]

Jo, tak v tomhle vám neporadím, reklamace byla na hardcodované cesty v openssl. V tomhle případě to vypadá spíš na hardcodované cesty v Qt (ani přejmenování systémového openssl.cnf to nerozhází), takže bych dotaz směroval spíš tam. Nebo zkusit prošťourat zdrojáky a zjistit, jestli se to v konfiguráku Qt nedá nějak přepsat...

[Honza Jaroš]

Uau!

$ cat qt-everywhere-opensource-src-4.8.4/src/network/ssl/qsslsocket.cpp

...
QList<QByteArray> QSslSocketPrivate::unixRootCertDirectories()
{
    return QList<QByteArray>() <<  "/etc/ssl/certs/" // (K)ubuntu, OpenSUSE, Mandriva, MeeGo ...
                               << "/usr/lib/ssl/certs/" // Gentoo, Mandrake
                               << "/usr/share/ssl/" // Centos, Redhat, SuSE
                               << "/usr/local/ssl/" // Normal OpenSSL Tarball
                               << "/var/ssl/certs/" // AIX
                               << "/usr/local/ssl/certs/" // Solaris
                               << "/var/certmgr/web/user_trusted/" // BlackBerry
                               << "/opt/openssl/certs/"; // HP-UX
}
...

[Lol Phirae]

No, co na to říct...

??? ??? Dafuq???

[Jardík]

No jsem slepej. V Qupzille jsem to pořešil. Zrušil jsem systémové certifikáty, vytvořil je v uživatelském profilu sestry, nastavil jsem jí v Qupzille v Preferences - Privacy - Certificate manager, záložka Settings a tam je tlačítko na přidání adresáře, kde to má hledat certifikáty. Bohužel nejdou blacklistovat systémové, takže to musím udělat takto. Firefox jí fungovat bude, ten si to tahá s sebou extra built-in v libnss, stejně jako thunderbird pro s/mime (asi stejně nepoužívá).

Pro sebe si whitelist dělat nemusím a ve Firefoxu to můžu blacklistovat všechno.

Kdyby tak v Qupzille bylo zaškrtávátko "nenačítat certifikáty ze systémovejch (čti hardcódovaných) adresářů.

Bohužel zatím sestře nebude fungovat akregator, pokud tam má nějaký https (jestli o vůbec používá), nebo něco jiný, co čte certifikáty jen z hardcódovaných adresářů.