Re: [SyncEvolution] SSL support in Maemo package
Patrick Ohly skrev:
On Mo, 2010-02-15 at 12:55 +0000, Ove Kaaven wrote:
> They can disable the certificate verification from the config file, I'm
> not sure I see a reason to explicitly compile out the checking code.
--disable-ssl-certificate-check only disables the default, the check is
still in the code. The main reason is that it helps that class of users
who will never figure out why SSL connections fail.
OK, could do that if you think it's a good idea, though it's supposedly
less secure or something.
> I don't really know how to import certificates, I haven't
needed to.
> It's probably necessary for people to change the config file to point at
> it.
The point of --with-ca-certificates is again that it changes the
platform-specific default location, ideally saving users from having to
figure out how to solve SSL problems.
I know. I meant it's necessary for people to do that until someone
actually tells me about a good default path which I can set in the
package. Since nobody has, then for now, people do need to change the
config...
The talk.maemo.org hints that changing that location together with
importing the SSL certificates via the Maemo settings GUI might work.
I'm not sure about it, because libcurl and libsoup expect a single file,
whereas the location mention apparently contains them as single files.
Pretty sure at least libcurl can take a path (CURLOPT_CAPATH) in lieu of
the single-file approach (CURLOPT_CAINFO), when built against OpenSSL.
(Don't know about libsoup.) Probably the standard Maemo libcurl package
hasn't been compiled with a default builtin path (though at least it is
compiled against OpenSSL), so the app would need to provide one.
I'm not sure what such a path should be. There seem to be some
predefined certs in /etc/certs/common-ca and /etc/certs/trusted, but if
the user needs to install certs, I don't know where that would be saved.
Also not sure if CAPATH can even take multiple directories.
> I'm wondering if it wouldn't be better to link against
libsoup rather
> than libcurl after all, though I'm not too sure what difference it would
> make.
Not much, I'm afraid. With libsoup it's actually even worse, the CA file
*has* to be specified by each app, whereas libcurl has a builtin
default. Some libsoup version also failed with certificates like the one
from Google (v1 root certificate, if I remember correctly).
Right.