Den 27. juni 2011 18:53, skrev Patrick Ohly: > Isn't there a combined file of all certs already? Debian maintains such > a file as part of installing individual certs.
No. This isn't Debian, this is heavily customized embedded system, with quite limited rootfs disk space (256MB). There's no ca-certificates package, there's just maemosec. It looks like Nokia have opened the sources to that, http://gitorious.org/maemo-5-certificate-manager If you check out that, you'll see in the etc/ directory roughly what the CA cert store looks like. In actual deployment there also seems to be a *.0 symlink for every *.pem file, e.g. Nokia-N900:/etc/certs/common-ca# ls -l ... -rw-r--r-- 1 root root 2106 Dec 8 2009 e7cec64ffc166796fa4aa307c104a7cb6adeda47.pem ... lrwxrwxrwx 1 root root 44 Sep 10 2010 f80cc7f6.0 -> e7cec64ffc166796fa4aa307c104a7cb6adeda47.pem ... Perhaps the built-in Maemo apps somehow uses libmaemosec to load all the needed certs into OpenSSL, instead of using OpenSSL's default paths. It looks like libmaemosec has an API to create a X509_STORE, which you can then probably feed to OpenSSL. But it does not appear to bother to actually physically create a combined CA cert file that OpenSSL could use by default (possibly due to the limited disk space). Other third-party programs have apparently also suffered from this stuff: https://bugs.maemo.org/show_bug.cgi?id=9355 Of course, actually using libmaemosec is no option (curl and neon is compiled against gnutls, libmaemosec against openssl), which leaves, as the only apparent alternative, manually loading all the PEM files from the directories I would specify with --with-ca-certificates. >> Otherwise, I suppose I'd have to make the GUI disable SSL checks... > > That might be the best short-term solution. > >>> Attached is a patch which might solve the problem. It passes all of my >>> tests here, but I don't have a setup where the code is relevant. Please >>> let me know if it works for you. >> >> Well, didn't seem to work correctly, I sent logs in separate mail. > > The patch did update the UID, but it set an empty value. This might be > due to a different bug that I introduced recently in the whole > UID/revision string tracking. I'm not at all happy with the solution > that I arrived at now. I'll probably rip it out and replace it with > something simpler. May I ask you to try again in a day or two? Sure. Ove _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
