Bug 521911 - qt: list of trusted CA certificates should not be compiled into library
qt: list of trusted CA certificates should not be compiled into library
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks: 521902
  Show dependency treegraph
 
Reported: 2009-09-08 12:49 EDT by Tomas Hoger
Modified: 2009-11-04 07:35 EST (History)
5 users (show)

See Also:
Fixed In Version: 4.5.3-7.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 734444 (view as bug list)
Environment:
Last Closed: 2009-09-08 14:12:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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


External Trackers
Tracker ID Priority Status Summary Last Updated
Debian BTS 530532 None None None Never

  None (edit)
Description Tomas Hoger 2009-09-08 12:49:56 EDT
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 13:07:21 EDT
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 13:17:37 EDT
agreed (provided it's tested to be reliable).
Comment 3 Rex Dieter 2009-09-08 13:47:40 EDT
Created attachment 360112 [details]
proposed patch to use system ca-certificates, using debian's as guide
Comment 4 Rex Dieter 2009-09-08 14:12:55 EDT
included in qt-4.5.2-15 , test away.
Comment 5 Joe Orton 2009-09-09 04:39:19 EDT
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 05:06:43 EDT
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 08:18:39 EDT
> 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 08:24:46 EDT
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 08:32:24 EDT
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 08:45:30 EDT
(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 19:49:16 EDT
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 07:03:14 EST
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 07:35:28 EST
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.