7:59 p.m.
Hello all,
I'm trying to set up calendar synchronization over SSL, however it
seems that syncevolution on my Nokia N900 is not able to verify the
server's certificate.
Connecting to the same server via openssl from elsewhere works fine.
On the N900, I do have the maemosec-certman-common-ca package
installed, and after symlinking /usr/lib/ssl/certs to /etc/certs
/common-ca , wget (on the N900) is correctly able to verify
certificates.
However, syncevolution isn't.
Judging from the error message, syncevolution seems to use curl:
[INFO] CurlTransport Failure: SSL certificate problem, verify that the CA cert is OK.
Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
In order to further track the problem, I ran syncevolution under
strace, and I noticed that it doesn't apparently even *try* top open CA
certificate files from anywhere...
(I searched for strings ssl, cert and crt in the strace log, and nothing
apart from openssl's library name turned up)
I doesn't seem to open any curlrc files either, but just to be sure, I
tried adding the following into /home/user/.curlrc :
--capath = /etc/certs/common-ca
... but that didn't help either.
Unfortunately, there is no longer a command-line curl client on the
N900, which I could use to tell whether this is a problem with libcurl
or with syncevolution itself...
Nokia-N900-51-1:~# dpkg -l syncevolution | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version
Description
+++-===================================================-==========================================-==================================================
ii syncevolution 1:1.1.99.6-1
SyncEvolution - a SyncML and CalDAV/CardDAV client
Any ideas?
Thanks,
Alain
8:25 p.m.
Hello again,
Oops, found it:
syncevolution does have a SSLServerCertificates setting in
.config/syncevolution/default/peers/<peer>/config.ini
After pointing this to the file for the CA certificate (StartSSL), as
found out by stracing wget, everything works fine:
SSLServerCertificates = /etc/certs/common-ca/33815e15.0
Pointing it to the CA certificate directory does not work though:
[INFO] CurlTransport Failure: error setting certificate verify locations:
CAfile: /etc/certs/common-ca/
CApath: none
Maybe syncevolution could check whether the setting points to a file or
to a directory, and set CApath rather than CAfile if it is a directory?
Also, wouldn't "SSLCACertificates" be a more appropriate name (it is
supposed to point to a CA certificate rather than a server certificate,
or does it accept both?)
Regards,
Alain
11:32 p.m.
On Tue, 2011-11-01 at 10:25 +0100, Alain Knaff wrote:
syncevolution does have a SSLServerCertificates setting in
.config/syncevolution/default/peers/<peer>/config.ini
After pointing this to the file for the CA certificate (StartSSL), as
found out by stracing wget, everything works fine:
SSLServerCertificates = /etc/certs/common-ca/33815e15.0
Pointing it to the CA certificate directory does not work though:
[INFO] CurlTransport Failure: error setting certificate verify locations:
CAfile: /etc/certs/common-ca/
CApath: none
Maybe syncevolution could check whether the setting points to a file or
to a directory, and set CApath rather than CAfile if it is a directory?
"CURLOPT_CAPATH" - "This option is OpenSSL-specific and does nothing if
libcurl is built to use GnuTLS." - how is libcurl built on the N900?
I don't mind adding such a feature, I just don't know whether it'll
help.
Also, wouldn't "SSLCACertificates" be a more
appropriate name (it is
supposed to point to a CA certificate rather than a server certificate,
or does it accept both?)
That depends a lot on the underlying transport and/or platform.
SyncEvolution just passes that value through.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:44 a.m.
Well, this stuff has been discussed before, and is a known problem. The
easiest solution is to just disable the SSL certificate checking...
Den 01. nov. 2011 13:32, skrev Patrick Ohly:
"CURLOPT_CAPATH" - "This option is OpenSSL-specific
and does nothing if
libcurl is built to use GnuTLS." - how is libcurl built on the N900?
It seems to be built against OpenSSL. (Then I should consider also
linking against the OpenSSL version of libneon instead of the GnuTLS
version of it, I suppose, but that's another matter...)
3:46 a.m.
On 2011-11-01 13:32, Patrick Ohly wrote:
[...]
"CURLOPT_CAPATH" - "This option is OpenSSL-specific
and does nothing if
libcurl is built to use GnuTLS." - how is libcurl built on the N900?
I don't mind adding such a feature, I just don't know whether it'll
help.
Nope, just tried to set CURLPOPT_CAPATH (and unset SSLServerCertificates
in .config again...): doesn't work
ltrace also shows that the only environment variable accessed by
syncevolution is SYNCEVOLUTION_DEBUG
> Also, wouldn't "SSLCACertificates" be a more appropriate name (it is
> supposed to point to a CA certificate rather than a server certificate,
> or does it accept both?)
That depends a lot on the underlying transport and/or platform.
SyncEvolution just passes that value through.
What call does does it use to pass that variable?
Thanks,
Alain
3:48 a.m.
On 2011-11-01 15:44, Ove Kåven wrote:
Well, this stuff has been discussed before, and is a known problem.
The
easiest solution is to just disable the SSL certificate checking...
Even easier is to just use http, and not bother with SSL at all. Which
is not a problem in my local Wifi LAN at home
However, I wanted to also be able to (securely) synchronize my calendars
while "on the road", hence the desire to use SSL.
Regards,
Alain
6:24 a.m.
On Tue, 2011-11-01 at 17:46 +0100, Alain Knaff wrote:
On 2011-11-01 13:32, Patrick Ohly wrote:
[...]
> "CURLOPT_CAPATH" - "This option is OpenSSL-specific and does nothing
if
> libcurl is built to use GnuTLS." - how is libcurl built on the N900?
>
> I don't mind adding such a feature, I just don't know whether it'll
> help.
Nope, just tried to set CURLPOPT_CAPATH (and unset SSLServerCertificates
in .config again...): doesn't work
ltrace also shows that the only environment variable accessed by
syncevolution is SYNCEVOLUTION_DEBUG
That's a bit surprising. The 1.2 binaries from syncevolution.org (with
D-Bus daemon) check quite a few env variables even for a simple
operation running inside the daemon:
$ ltrace syncevolution --version 2>&1 | grep getenv
getenv("SYNCEVOLUTION_DEBUG") = NULL
getenv("http_proxy") = NULL
getenv("HOME") = "/home/pohly"
getenv("PATH") =
"/home/pohly/bin:/usr/local/sbin:"...
getenv("SYNCEVOLUTION_BACKEND_DIR") = NULL
getenv("SYNCEVOLUTION_DEBUG") = NULL
getenv("SYNCEVOLUTION_GNUTLS_DEBUG") = NULL
getenv("SYNCEVOLUTION_TEMPLATE_DIR") = NULL
getenv("SYNCEVOLUTION_XML_CONFIG_DIR") = NULL
getenv("SYNC_EVOLUTION_EVO_CALENDAR_DELA"...) = NULL
getenv("XDG_CACHE_HOME") = NULL
getenv("XDG_CONFIG_HOME") = NULL
getenv("XDG_DATA_HOME") = NULL
>> Also, wouldn't "SSLCACertificates" be a more
appropriate name (it is
>> supposed to point to a CA certificate rather than a server certificate,
>> or does it accept both?)
>
> That depends a lot on the underlying transport and/or platform.
> SyncEvolution just passes that value through.
>
What call does does it use to pass that variable?
That depends on the transport.
libsoup: g_object_set SOUP_SESSION_SSL_CA_FILE
libcurl: curl_easy_setopt CURLOPT_CAINFO
libneon (WebDAV backend): ne_ssl_trust_default_ca for system
certificates, ignores SSLCACertificates setting
In all cases SyncEvolution never deals with the content of the setting
itself. Instead it relies on the library that it calls to do something
sensible with it.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
9:15 a.m.
On 2011-11-01 20:24, Patrick Ohly wrote:
On Tue, 2011-11-01 at 17:46 +0100, Alain Knaff wrote:
[...]
> ltrace also shows that the only environment variable accessed by
> syncevolution is SYNCEVOLUTION_DEBUG
That's a bit surprising. The 1.2 binaries from syncevolution.org (with
^^^^^^^^^^^^^
That's probably the reason, I've only got 1.1.99.6-1 on my N900.
I checked syncevolution.org to see whether there are any newer N900
binaries on there, but I'm having trouble setting up the correct
repositories:
http://syncevolution.org/documentation/installation points to
http://maemo.org/packages/view/syncevolution-frontend/ for N900
installation, but the versions listed on that page are even older (0.12
and 0.9)...
[...]
> What call does does it use to pass that variable?
That depends on the transport.
libsoup: g_object_set SOUP_SESSION_SSL_CA_FILE
libcurl: curl_easy_setopt CURLOPT_CAINFO
libneon (WebDAV backend): ne_ssl_trust_default_ca for system
certificates, ignores SSLCACertificates setting
In all cases SyncEvolution never deals with the content of the setting
itself. Instead it relies on the library that it calls to do something
sensible with it.
Unfortunately, according to
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTCAINFO ,
libcurl does not "do something sensible" with it. Instead it always
takes the parameter to be a CAfile, even if it is a directory.
So, apparently, the app is supposed to do this check itself, and use
CURLOPT_CAPATH if it passes a directory.
I agree that the naming is indeed misleading. Calling it CURLOPT_CAFILE
would have made more sense, but they probably have their reasons...
Regards,
Alain
6:06 p.m.
On Tue, 2011-11-01 at 23:15 +0100, Alain Knaff wrote:
On 2011-11-01 20:24, Patrick Ohly wrote:
> On Tue, 2011-11-01 at 17:46 +0100, Alain Knaff wrote:
>> What call does does it use to pass that variable?
>
> That depends on the transport.
>
> libsoup: g_object_set SOUP_SESSION_SSL_CA_FILE
> libcurl: curl_easy_setopt CURLOPT_CAINFO
> libneon (WebDAV backend): ne_ssl_trust_default_ca for system
> certificates, ignores SSLCACertificates setting
>
> In all cases SyncEvolution never deals with the content of the setting
> itself. Instead it relies on the library that it calls to do something
> sensible with it.
>
Unfortunately, according to
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTCAINFO ,
libcurl does not "do something sensible" with it. Instead it always
takes the parameter to be a CAfile, even if it is a directory.
So, apparently, the app is supposed to do this check itself, and use
CURLOPT_CAPATH if it passes a directory.
I agree that the naming is indeed misleading. Calling it CURLOPT_CAFILE
would have made more sense, but they probably have their reasons...
I don't mind writing some extra code for doing this check, but hadn't
you already tried that without success? You said "just tried to set
CURLPOPT_CAPATH (and unset SSLServerCertificates in .config again...):
doesn't work".
So it would be the right thing to do on some platform/configuration (I'm
not even sure where), but wouldn't help on the N900, would it?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7:07 p.m.
On Tue, 2011-11-01 at 23:15 +0100, Alain Knaff wrote:
On 2011-11-01 20:24, Patrick Ohly wrote:
> On Tue, 2011-11-01 at 17:46 +0100, Alain Knaff wrote:
[...]
>> ltrace also shows that the only environment variable accessed by
>> syncevolution is SYNCEVOLUTION_DEBUG
>
> That's a bit surprising. The 1.2 binaries from syncevolution.org (with
^^^^^^^^^^^^^
That's probably the reason, I've only got 1.1.99.6-1 on my N900.
Sorry, forget to comment on that. No, 1.1.99.6 is very similar to 1.2
and also should check additional environment variables.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7:21 p.m.
On 02/11/11 08:06, Patrick Ohly wrote:
On Tue, 2011-11-01 at 23:15 +0100, Alain Knaff wrote:
[...]
I don't mind writing some extra code for doing this check, but
hadn't
you already tried that without success? You said "just tried to set
CURLPOPT_CAPATH (and unset SSLServerCertificates in .config again...):
doesn't work".
What I did was to set the CURLPOPT_CAPATH _environment_variable_, and
that didn't work. Maybe libcurl on N900 doesn't check the environment,
but does accept the relevant setting if passed in via curl_easy_setopt ?
Unfortunately, I currently don't have access to a compilation
environment for the N900, so I can't check whether such a code change
would indeed fix the problem.
So it would be the right thing to do on some platform/configuration (I'm
not even sure where), but wouldn't help on the N900, would it?
As far as I understand this distinction between CURLPOPT_CAINFO and
CURLPOPT_CAPATH is platform independent. The checking of the environment
or of ~/.curlrc files may however depend on the platform (if the
maintainers of libcurl on the N900 left those out in order to create a
more "light-weight" version?)
Regards,
Alain
7:30 p.m.
On 02/11/11 09:07, Patrick Ohly wrote:
On Tue, 2011-11-01 at 23:15 +0100, Alain Knaff wrote:
> On 2011-11-01 20:24, Patrick Ohly wrote:
>> On Tue, 2011-11-01 at 17:46 +0100, Alain Knaff wrote:
> [...]
>>> ltrace also shows that the only environment variable accessed by
>>> syncevolution is SYNCEVOLUTION_DEBUG
>>
>> That's a bit surprising. The 1.2 binaries from syncevolution.org (with
> ^^^^^^^^^^^^^
> That's probably the reason, I've only got 1.1.99.6-1 on my N900.
Sorry, forget to comment on that. No, 1.1.99.6 is very similar to 1.2
and also should check additional environment variables.
Unfortunately, it does not. Does syncevolution itself read those
variables, or do the libraries on which it depends read them? Or is it
just ltrace going funny? (I've seen a similar thing with strace... that
it stops logging some syscalls after a while)
Regards,
Alain
8:08 p.m.
On Wed, 2011-11-02 at 09:21 +0100, Alain Knaff wrote:
On 02/11/11 08:06, Patrick Ohly wrote:
> On Tue, 2011-11-01 at 23:15 +0100, Alain Knaff wrote:
[...]
> I don't mind writing some extra code for doing this check, but hadn't
> you already tried that without success? You said "just tried to set
> CURLPOPT_CAPATH (and unset SSLServerCertificates in .config again...):
> doesn't work".
What I did was to set the CURLPOPT_CAPATH _environment_variable_, and
that didn't work.
Then I misunderstood. I thought you had made the change in the source
code.
Maybe libcurl on N900 doesn't check the environment,
but does accept the relevant setting if passed in via curl_easy_setopt ?
Could be. But a much more likely explanation is that libcurl is linked
against GnuTLS instead of OpenSSL, in which case CURLPOPT_CAPATH simply
doesn't do anything because only OpenSSL supports it.
Unfortunately, I currently don't have access to a compilation
environment for the N900, so I can't check whether such a code change
would indeed fix the problem.
Can you run ldd on /usr/lib/libcurl* and check whether it uses gnutls or
libssl? On Debian, I get:
$ ldd /usr/lib/libcurl.so.3 | grep -e tls -e ssl
libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007f6733f55000)
libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00007f6732cf0000)
$ ldd /usr/lib/libcurl-gnutls.so.3 | grep -e tls -e ssl
libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00007f0704d07000)
Interesting, the "non-gnutls" variant actually links against both. But
gnutls is only pulled in indirectly:
$ readelf -a /usr/lib/libcurl.so.3 | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libidn.so.11]
0x0000000000000001 (NEEDED) Shared library: [libssh2.so.1]
0x0000000000000001 (NEEDED) Shared library: [liblber-2.4.so.2]
0x0000000000000001 (NEEDED) Shared library: [libldap_r-2.4.so.2]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libgssapi_krb5.so.2]
0x0000000000000001 (NEEDED) Shared library: [libssl.so.0.9.8]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.0.9.8]
0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
$ LD_DEBUG=files ldd /usr/lib/libcurl.so.3 2>&1 | grep gnutls
24198: file=libgnutls.so.26 [0]; needed by /usr/lib/libldap_r-2.4.so.2 [0]
> So it would be the right thing to do on some
platform/configuration (I'm
> not even sure where), but wouldn't help on the N900, would it?
>
As far as I understand this distinction between CURLPOPT_CAINFO and
CURLPOPT_CAPATH is platform independent.
The distinction is, but support for CAPATH isn't. With "platform" I mean
both the hardware and the OS on top of it, which includes whether
libcurl uses OpenSSL or GnuTLS.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
8:11 p.m.
On Wed, 2011-11-02 at 09:30 +0100, Alain Knaff wrote:
On 02/11/11 09:07, Patrick Ohly wrote:
> On Tue, 2011-11-01 at 23:15 +0100, Alain Knaff wrote:
>> On 2011-11-01 20:24, Patrick Ohly wrote:
>>> On Tue, 2011-11-01 at 17:46 +0100, Alain Knaff wrote:
>> [...]
>>>> ltrace also shows that the only environment variable accessed by
>>>> syncevolution is SYNCEVOLUTION_DEBUG
>>>
>>> That's a bit surprising. The 1.2 binaries from syncevolution.org (with
>> ^^^^^^^^^^^^^
>> That's probably the reason, I've only got 1.1.99.6-1 on my N900.
>
> Sorry, forget to comment on that. No, 1.1.99.6 is very similar to 1.2
> and also should check additional environment variables.
>
Unfortunately, it does not. Does syncevolution itself read those
variables, or do the libraries on which it depends read them?
libsyncevolution.so reads them, at least when building SyncEvolution
with shared libraries. Might not be the case on the N900.
Or is it
just ltrace going funny?
Perhaps. <shrug>
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
8:50 p.m.
On 02/11/11 10:08, Patrick Ohly wrote:
[...]
Can you run ldd on /usr/lib/libcurl* and check whether it uses gnutls
or
libssl? On Debian, I get:
$ ldd /usr/lib/libcurl.so.3 | grep -e tls -e ssl
libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007f6733f55000)
libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00007f6732cf0000)
$ ldd /usr/lib/libcurl-gnutls.so.3 | grep -e tls -e ssl
libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00007f0704d07000)
On the N900, I get:
Nokia-N900-51-1:~# ldd /usr/lib/libcurl.so.3 | grep -e tls -e ssl
libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x4000e000)
Interesting, the "non-gnutls" variant actually links against both. But
gnutls is only pulled in indirectly:
$ readelf -a /usr/lib/libcurl.so.3 | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libidn.so.11]
0x0000000000000001 (NEEDED) Shared library: [libssh2.so.1]
0x0000000000000001 (NEEDED) Shared library: [liblber-2.4.so.2]
0x0000000000000001 (NEEDED) Shared library: [libldap_r-2.4.so.2]
0x0000000000000001 (NEEDED) Shared library: [librt.so.1]
0x0000000000000001 (NEEDED) Shared library: [libgssapi_krb5.so.2]
0x0000000000000001 (NEEDED) Shared library: [libssl.so.0.9.8]
0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.0.9.8]
0x0000000000000001 (NEEDED) Shared library: [libz.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
Nokia-N900-51-1:~# readelf -a /usr/lib/libcurl.so.3 | grep NEEDED
0x00000001 (NEEDED) Shared library: [libssl.so.0.9.8]
0x00000001 (NEEDED) Shared library: [libcrypto.so.0.9.8]
0x00000001 (NEEDED) Shared library: [libz.so.1]
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
$ LD_DEBUG=files ldd /usr/lib/libcurl.so.3 2>&1 | grep gnutls
24198: file=libgnutls.so.26 [0]; needed by /usr/lib/libldap_r-2.4.so.2 [0]
Nokia-N900-51-1:~# LD_DEBUG=files ldd /usr/lib/libcurl.so.3 2>&1 | grep gnutls
nothing
>> So it would be the right thing to do on some platform/configuration (I'm
>> not even sure where), but wouldn't help on the N900, would it?
>>
>
> As far as I understand this distinction between CURLPOPT_CAINFO and
> CURLPOPT_CAPATH is platform independent.
The distinction is, but support for CAPATH isn't. With "platform" I mean
both the hardware and the OS on top of it, which includes whether
libcurl uses OpenSSL or GnuTLS.
ok. So what happens with GnuTLS if you pass a directory with CURLPOPT_CAINFO?
Does GnuTLS interpret this as a directory which contains files with CA
certificates?
Regards,
Alain
9:14 p.m.
On Wed, 2011-11-02 at 10:50 +0100, Alain Knaff wrote:
On 02/11/11 10:08, Patrick Ohly wrote:
>> As far as I understand this distinction between CURLPOPT_CAINFO and
>> CURLPOPT_CAPATH is platform independent.
>
> The distinction is, but support for CAPATH isn't. With "platform" I
mean
> both the hardware and the OS on top of it, which includes whether
> libcurl uses OpenSSL or GnuTLS.
>
ok. So what happens with GnuTLS if you pass a directory with CURLPOPT_CAINFO?
Does GnuTLS interpret this as a directory which contains files with CA
certificates?
My guess is that it simply won't work because GnuTLS expects (and only
supports) a single file. I've never tried it, so I don't know what the
resulting error message is.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
9:18 p.m.
On 02/11/11 11:14, Patrick Ohly wrote:
On Wed, 2011-11-02 at 10:50 +0100, Alain Knaff wrote:
> On 02/11/11 10:08, Patrick Ohly wrote:
>>> As far as I understand this distinction between CURLPOPT_CAINFO and
>>> CURLPOPT_CAPATH is platform independent.
>>
>> The distinction is, but support for CAPATH isn't. With "platform" I
mean
>> both the hardware and the OS on top of it, which includes whether
>> libcurl uses OpenSSL or GnuTLS.
>>
>
> ok. So what happens with GnuTLS if you pass a directory with CURLPOPT_CAINFO?
> Does GnuTLS interpret this as a directory which contains files with CA
> certificates?
My guess is that it simply won't work because GnuTLS expects (and only
supports) a single file. I've never tried it, so I don't know what the
resulting error message is.
Well in that case, what harm could be done by putting the test for file
or directory into the app?
- If curl is linked against OpenSSL, this will be the appropriate thing
to do
- If on the other hand, curl is linked against GnuTLS, it won't work,
but as GnuTLS doesn't support CA directories at all (if I understand you
correctly), then nothing is lost compared to the current situation
(which always calls CAINFO)
Regards,
Alain
10:18 p.m.
On Wed, 2011-11-02 at 11:18 +0100, Alain Knaff wrote:
On 02/11/11 11:14, Patrick Ohly wrote:
> On Wed, 2011-11-02 at 10:50 +0100, Alain Knaff wrote:
>> On 02/11/11 10:08, Patrick Ohly wrote:
>>>> As far as I understand this distinction between CURLPOPT_CAINFO and
>>>> CURLPOPT_CAPATH is platform independent.
>>>
>>> The distinction is, but support for CAPATH isn't. With
"platform" I mean
>>> both the hardware and the OS on top of it, which includes whether
>>> libcurl uses OpenSSL or GnuTLS.
>>>
>>
>> ok. So what happens with GnuTLS if you pass a directory with CURLPOPT_CAINFO?
>> Does GnuTLS interpret this as a directory which contains files with CA
>> certificates?
>
> My guess is that it simply won't work because GnuTLS expects (and only
> supports) a single file. I've never tried it, so I don't know what the
> resulting error message is.
>
Well in that case, what harm could be done by putting the test for file
or directory into the app?
None. As I said, I don't mind adding the code. But before doing it and
asking Ove to create new binaries, I wanted to be sure that it really
has a chance of improving the situation.
I also wanted to explain why SyncEvolution and it's documentation is so
fuzzy about these options. In many cases it doesn't know what the string
values will do in the underlying layers.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
12:34 a.m.
On Wed, 2011-11-02 at 12:18 +0100, Patrick Ohly wrote:
On Wed, 2011-11-02 at 11:18 +0100, Alain Knaff wrote:
> On 02/11/11 11:14, Patrick Ohly wrote:
> Well in that case, what harm could be done by putting the test for file
> or directory into the app?
None. As I said, I don't mind adding the code. But before doing it and
asking Ove to create new binaries, I wanted to be sure that it really
has a chance of improving the situation.
Patch attached and committed to for-master/curl-capath branch. Note that
there might be a slight regression risk around NSS-enabled libcurl. See
patch comments.
Ove, can you perhaps help Alain with trying out this change by providing
a binary?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
3973
days inactive
3974
days old
syncevolution@synevolution.org
18 comments
3 participants
participants (3)
-
Alain Knaff -
Ove Kåven -
Patrick Ohly