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.)

agreed (provided it's tested to be reliable).

Created attachment 360112 [details]
proposed patch to use system ca-certificates, using debian's as guide

included in qt-4.5.2-15 , test away.

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

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.

> 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 ?

sorry, the debian patch gives a list of bundle back, not the first maching!
it's wrong. I will fix it.

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/

(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

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

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.

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.