Bug 521911 - qt: list of trusted CA certificates should not be compiled into library
Summary: qt: list of trusted CA certificates should not be compiled into library
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: qt
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ngo Than
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 521902
TreeView+ depends on / blocked
 
Reported: 2009-09-08 16:49 UTC by Tomas Hoger
Modified: 2009-11-04 12:35 UTC (History)
5 users (show)

Fixed In Version: 4.5.3-7.fc10
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 734444 (view as bug list)
Environment:
Last Closed: 2009-09-08 18:12:55 UTC


Attachments (Terms of Use)
proposed patch to use system ca-certificates, using debian's as guide (1.71 KB, patch)
2009-09-08 17:47 UTC, Rex Dieter
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Debian BTS 530532 None None None Never

Description Tomas Hoger 2009-09-08 16:49:56 UTC
Description of problem:
List of trusted certificates used by default by QtSslSocket (ca-bundle.crt from sources) is compiled into the QtNetwork.so library, not allowing users to customize list of trusted CAs without re-compiling Qt.

Separate file with trusted certificates provides better manageability, but may better be added upstream.  Preferably, usage of "system" bundle from ca-certificates may be a reasonable default.

Note: Impact of this problem is lowered by the fact that most KDE applications use certificate bundle shipped with kdelibs, provided as separate file.  However, there reportedly are applications that only use Qt's bundle by default:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530532

According to the bug, Qt had a (broken) support for loading system CA bundle, which was removed in recent Qt version (in between 4.5.2 and 4.5.3, it seems; search path did not include /etc/pki directories used by Fedora).


Steps to Reproduce:
$ strings /usr/lib/libQtNetwork.so.4

Comment 1 Kevin Kofler 2009-09-08 17:07:21 UTC
I think we should patch it to use the system ca-certificates. Nokia is excessively paranoid about backwards compatibility and it seems they want to keep bug-compatibility here (the code was not just broken, it was completely disabled because the #ifdef had a typo). :-( (This is quite silly, as they made some "fixes" in 4.5.0 and even 4.5.1 which actually broke things, but they don't want to make this change which is clearly a bugfix.)

Comment 2 Rex Dieter 2009-09-08 17:17:37 UTC
agreed (provided it's tested to be reliable).

Comment 3 Rex Dieter 2009-09-08 17:47:40 UTC
Created attachment 360112 [details]
proposed patch to use system ca-certificates, using debian's as guide

Comment 4 Rex Dieter 2009-09-08 18:12:55 UTC
included in qt-4.5.2-15 , test away.

Comment 5 Joe Orton 2009-09-09 08:39:19 UTC
Thanks for looking into this Rex!

My reading of that patch is that it's going to load any cert matching:

  /etc/pki/tls/certs/*.crt

and treat them as trusted - is that correct?  If so, that's not desirable - it should really just be the file:

  /etc/pki/tls/certs/ca-bundle.crt

Comment 6 Tomas Hoger 2009-09-09 09:06:43 UTC
Besides Joe's comment, there are 2 possible catches here:

- The part of the code fixed by the patch has been removed upstream completely, as was indicated in the Debian bug report:

http://qt.gitorious.org/qt/qt/blobs/master/src/network/ssl/qsslsocket_openssl.cpp#line483

So if that's way we're going to use, we'll need to carry on that code junk as a whole in future Qt versions (it can possibly be simplified though to just load one file instead of looping through all *.crt)

- I guess this patch will not remove the compiled-in bundle, rather corrects Qt to use system one too.  While this makes it easier to add more trusted CAs, it does not allow removing users consider untrusted from Qt's bundle.  Please correct me if I'm wrong at this point.

Comment 7 Ngo Than 2009-09-09 12:18:39 UTC
> Description of problem:
> List of trusted certificates used by default by QtSslSocket (ca-bundle.crt from
> sources) is compiled into the QtNetwork.so library, not allowing users to
> customize list of trusted CAs without re-compiling Qt.
> 
> Separate file with trusted certificates provides better manageability, but may
> better be added upstream.  Preferably, usage of "system" bundle from
> ca-certificates may be a reasonable default.
> 
> Note: Impact of this problem is lowered by the fact that most KDE applications
> use certificate bundle shipped with kdelibs, provided as separate file. 
> However, there reportedly are applications that only use Qt's bundle by
> default:
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530532
> 
> According to the bug, Qt had a (broken) support for loading system CA bundle,
> which was removed in recent Qt version (in between 4.5.2 and 4.5.3, it seems;
> search path did not include /etc/pki directories used by Fedora).
> 
> 
> Steps to Reproduce:
> $ strings /usr/lib/libQtNetwork.so.4  

it's sadly that there's a typo bug in #ifdef that makes Qt always uses the own bundle which is compiled into library. The obove debian patch fixes the typo bug, so that the systemwide bundle will be used by default. If there's no systemwide bundle found it will fall back to qt bundle.



(In reply to comment #5)

> My reading of that patch is that it's going to load any cert matching:
> 
>   /etc/pki/tls/certs/*.crt
> 
> and treat them as trusted - is that correct?  If so, that's not desirable - it

the obove patches will load only one cert matching. If there're many bundles in the directories the fisrt matching will be loaded.


> should really just be the file:
> 
>   /etc/pki/tls/certs/ca-bundle.crt  

is there any reason we only read the file ca-bundle.crt ?

Comment 8 Ngo Than 2009-09-09 12:24:46 UTC
sorry, the debian patch gives a list of bundle back, not the first maching!
it's wrong. I will fix it.

Comment 9 Rex Dieter 2009-09-09 12:32:24 UTC
I thought it was desirable to have modular loading of CA certs, ie, drop certs into /etc/pki/tls/certs without having to manually modify ca-bundle.crt, akin to other similar stuff like /etc/ld.so.conf.d/  /etc/prelink.conf.d /etc/profile.d/

Comment 10 Ngo Than 2009-09-09 12:45:30 UTC
(In reply to comment #6)
> Besides Joe's comment, there are 2 possible catches here:
> 
> - The part of the code fixed by the patch has been removed upstream completely,
> as was indicated in the Debian bug report:
> 
> http://qt.gitorious.org/qt/qt/blobs/master/src/network/ssl/qsslsocket_openssl.cpp#line483
> 
> So if that's way we're going to use, we'll need to carry on that code junk as a
> whole in future Qt versions (it can possibly be simplified though to just load
> one file instead of looping through all *.crt)
> 

it seems the future qt only loads the own qt-ca-bundle.crt. If we want qt to load the systemwide *.crt, we have to carry on this code.
The question is do we want it? it's really needed? 


> - I guess this patch will not remove the compiled-in bundle, rather corrects Qt
> to use system one too.  While this makes it easier to add more trusted CAs, it
> does not allow removing users consider untrusted from Qt's bundle.  Please
> correct me if I'm wrong at this point.  

this debian patch doesn't remove the  compiled-in bundle, it only correct to use system one

Comment 11 Fedora Update System 2009-10-11 23:49:16 UTC
qt-4.5.3-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/qt-4.5.3-4.fc11

Comment 12 Fedora Update System 2009-11-04 12:03:14 UTC
qt-4.5.3-7.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2009-11-04 12:35:28 UTC
qt-4.5.3-7.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.