Hey all
Somehow using HTTPS with purest_json just worked(tm) in Debian Jessie. Now, that I had to compile purest_json myself, I'm having troubles verifying the server. I'm getting:
77 Problem with the SSL CA cert (path? access rights?)
when accessing a resource through HTTPS with [rest].
How can I tell [rest] where my certificate store lies? Or is there a way to specify a root certificate?
Roman
On 2018-04-25 10:59, Roman Haefeli wrote:
Somehow using HTTPS with purest_json just worked(tm) in Debian Jessie. Now, that I had to compile purest_json myself,
btw, what is wrong with the pd-purest-json Debian package?
afaik, the version in buster is pretty up-to-date and using the correct Debian package for your distribution will magically get rid of all the dependency problems you experience. also, the pd-deken-apt package allows you to integrate apt packages in your deken search.
famsdr IOhannes
On Mit, 2018-04-25 at 11:04 +0200, IOhannes m zmoelnig wrote:
On 2018-04-25 10:59, Roman Haefeli wrote:
Somehow using HTTPS with purest_json just worked(tm) in Debian Jessie. Now, that I had to compile purest_json myself,
btw, what is wrong with the pd-purest-json Debian package?
Nothing. It seems to use the certificate store from the system already. It works well for me. Thanks for pointing me to it.
afaik, the version in buster
I am on Debian stable (Stretch). The version of Buster doesn't matter for me.
is pretty up-to-date and using the correct Debian package for your distribution will magically get rid of all the dependency problems you experience.
Regarding my other mail: I'm not looking for a solution, as I don't have a problem using the package from apt or compile my own. But I'm curious to know whether it is possible as a Deken package maintainer to address the problem of different versions of linked libraries.
also, the pd-deken-apt package allows you to integrate apt packages in your deken search.
Which is a cool feature!
Roman
On Mit, 2018-04-25 at 13:08 +0200, Roman Haefeli wrote:
On Mit, 2018-04-25 at 11:04 +0200, IOhannes m zmoelnig wrote:
On 2018-04-25 10:59, Roman Haefeli wrote:
Somehow using HTTPS with purest_json just worked(tm) in Debian Jessie. Now, that I had to compile purest_json myself,
btw, what is wrong with the pd-purest-json Debian package?
Nothing. It seems to use the certificate store from the system already.
Actually, I would love to understand a bit more the magic behind it. Why does purest_json/rest from apt correctly validate certs against the system's CA store and the compiled version does not?
Roman
Hi,
Roman Haefeli schrieb am 25.04.2018 13:13:
On Mit, 2018-04-25 at 13:08 +0200, Roman Haefeli wrote:
On Mit, 2018-04-25 at 11:04 +0200, IOhannes m zmoelnig wrote:
On 2018-04-25 10:59, Roman Haefeli wrote:
Somehow using HTTPS with purest_json just worked(tm) in Debian Jessie. Now, that I had to compile purest_json myself,
btw, what is wrong with the pd-purest-json Debian package?
Nothing. It seems to use the certificate store from the system already.
Actually, I would love to understand a bit more the magic behind it. Why does purest_json/rest from apt correctly validate certs against the system's CA store and the compiled version does not?
This is probably related to the libcurl versions as documented in the wiki. The compilation instructions are a bit out of date, sorry about that.
Maybe you could replace libcurl4-nss-dev with libcurl4-gnutls-dev or libcurl4-openssl-dev for compiling purest_json.
Otherwise, you could also download the pem file from https://curl.haxx.se/docs/caextract.html and add
#define NEEDS_CERT_PATH 1
in line 45 of https://github.com/residuum/PuRestJson/blob/master/src/purest_json.h
Hth, Thomas
On Mit, 2018-04-25 at 14:11 +0200, Thomas Mayer wrote:
Maybe you could replace libcurl4-nss-dev with libcurl4-gnutls-dev or libcurl4-openssl-dev for compiling purest_json.
Ah, i see. When only libcurl4-openssl-dev is installed and the others removed, the resulting [rest] successfully validates certificates.
So it seems, only the documation needs an update (not to mention libcurl4-nss-dev)
Roman
On 2018-04-25 17:21, Roman Haefeli wrote:
So it seems, only the documation needs an update (not to mention libcurl4-nss-dev)
that's probably not enough. people might have to be made aware that they should *remove* libcurl4-nss-dev first (if this is indeed the case).
fgamsdr IOhannes
On 2018-04-25 13:08, Roman Haefeli wrote:
On Mit, 2018-04-25 at 11:04 +0200, IOhannes m zmoelnig wrote:
On 2018-04-25 10:59, Roman Haefeli wrote:
Somehow using HTTPS with purest_json just worked(tm) in Debian Jessie. Now, that I had to compile purest_json myself,
btw, what is wrong with the pd-purest-json Debian package?
Nothing. It seems to use the certificate store from the system already. It works well for me. Thanks for pointing me to it.
afaik, the version in buster
I am on Debian stable (Stretch). The version of Buster doesn't matter for me.
i might provide backports of (select) pd-packages. just like i already provide a "puredata" (0.48) backport to stretch users.
Regarding my other mail: I'm not looking for a solution, as I don't have a problem using the package from apt or compile my own. But I'm curious to know whether it is possible as a Deken package maintainer to address the problem of different versions of linked libraries.
short answer: no. longer answer: sure. people only need to include all the dependencies locally (in this case, the deken package would need to provide a "libjson-c2.so" file and the externals, e.g. "rest.pd_linux" would need to look for this dynamic library locally (in addition to the system paths)). repeat this for all other (non-standard) dynamic libraries your external depends on. repeat this for all (non-standard) dynamic libraries required by all (non-standard) dynamic libraries your external depends on. recurse until there are no more non-standard dependencies left.
just to give a quick impression on the numbers of dynamic libraries:
$ ldd zexy/zexy.pd_linux | grep -c .
4
$ ldd purest_json/rest.pd_linux | grep -c .
32
if you are only interested in libraries in '/usr/' (as a crude measurement on "non-standard" library):
$ ldd zexy/zexy.pd_linux | grep -c /usr/
0
$ ldd purest_json/rest.pd_linux | grep -c .
21
fgasdmr IOhannes