Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)
Hello,
On Fri, May 27, 2022 at 09:46:51PM +0200, Arrigo Marchiori wrote:
> Hello Damjan,
>
> On Sun, May 22, 2022 at 06:10:46PM +0200, Damjan Jovanovic wrote:
>
> > On Sun, May 22, 2022 at 2:43 PM Arrigo Marchiori
> > wrote:
> >
> > > Hello Damjan, all,
> > >
> > > On Tue, Apr 26, 2022 at 07:56:22PM +0200, Damjan Jovanovic wrote:
> > >
> > > > On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski wrote:
> > > >
> > > > > I'm gonna look into the serf->(lib)curl option... Since we don't use
> > > any
> > > > > of the fancy features of serf, I'm thinking that the easy option might
> > > be
> > > > > best
> > > >
> > > >
> > > >
> > > > Hi
> > > >
> > > > I've ported our WebDAV content provider module from Serf to Curl.
> > >
> > > I just enhanced the error reporting a bit; I am finding a problem
> > > under Linux and I do not really know how to assess it.
> > >
> > > The problem: if we build AOO on CentOS (that is our reference
> > > platform) then Curl will look for CA certificates in
> > > /etc/pki/tls/certs/ca-bundle.crt
> > >
> > > This will fail on openSUSE and probably on Ubuntu as well.
> > >
> > > It seems that the above path is set at configure time and embedded
> > > into Curl's code as #define macros.
> > >
> > > Is there an ``official'' way to assess this? Like, can we depend on
> > > NSS' certificate store as you wrote (quoted below)?
> > >
> >
> > Curl/OpenSSL have an enormous number of options and I am pretty sure it can
> > be fixed, but first I need to understand where and how it's failing.
> >
> > We currently allow it to run with the default CA certificate path, do
> > pre-verification on the server's certificate using those CA certificates,
> > then call our SSL_VERIFY_PEER function where we override the verification
> > result with the certificates from NSS.
>
> Apparently, it is failing before calling our SSL_VERIFY_PEER function.
>
> > If it's failing before reaching our SSL_VERIFY_PEER function, we should be
> > able to use Curl's CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB functions to set a
> > custom CA certificate path (or in-memory buffer), maybe even an empty
> > buffer, so that it proceeds further. ("man CURLOPT_CAINFO", "man
> > CURLOPT_CAINFO_BLOB", or "man curl_easy_setopt" and read under the "SSL and
> > SECURITY OPTIONS" section.)
>
> So we would need to hard-code and try all possible paths to the CA
> bundle on Unix systems?
>
> > With the CURLOPT_CAINFO_BLOB option it might even be possible to skip the
> > custom certificate verification we do later, and pre-populate Curl/OpenSSL
> > with NSS certificates from the beginning, I just don't know enough about
> > NSS to rely on that (eg. if you are using a cryptographic device or smart
> > card in NSS, how does that work?). If that option is ok, then we might not
> > even need the NSS libraries: recent versions of NSS store all the
> > certificates in an SQLite database, which can be accessed with SQLite APIs
> > directly, no need to build with or ship the NSS libraries at all.
>
> If I understood correctly [1], a NSS-linked Curl would query NSS by
> itself... are we not in this condition?
Sorry, I forgot the link!
Here it is:
1: https://curl.se/libcurl/c/CURLOPT_CAINFO.html
> Thank you in advance and best regards,
--
Arrigo
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)
Hello Damjan,
On Sun, May 22, 2022 at 06:10:46PM +0200, Damjan Jovanovic wrote:
> On Sun, May 22, 2022 at 2:43 PM Arrigo Marchiori
> wrote:
>
> > Hello Damjan, all,
> >
> > On Tue, Apr 26, 2022 at 07:56:22PM +0200, Damjan Jovanovic wrote:
> >
> > > On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski wrote:
> > >
> > > > I'm gonna look into the serf->(lib)curl option... Since we don't use
> > any
> > > > of the fancy features of serf, I'm thinking that the easy option might
> > be
> > > > best
> > >
> > >
> > >
> > > Hi
> > >
> > > I've ported our WebDAV content provider module from Serf to Curl.
> >
> > I just enhanced the error reporting a bit; I am finding a problem
> > under Linux and I do not really know how to assess it.
> >
> > The problem: if we build AOO on CentOS (that is our reference
> > platform) then Curl will look for CA certificates in
> > /etc/pki/tls/certs/ca-bundle.crt
> >
> > This will fail on openSUSE and probably on Ubuntu as well.
> >
> > It seems that the above path is set at configure time and embedded
> > into Curl's code as #define macros.
> >
> > Is there an ``official'' way to assess this? Like, can we depend on
> > NSS' certificate store as you wrote (quoted below)?
> >
>
> Curl/OpenSSL have an enormous number of options and I am pretty sure it can
> be fixed, but first I need to understand where and how it's failing.
>
> We currently allow it to run with the default CA certificate path, do
> pre-verification on the server's certificate using those CA certificates,
> then call our SSL_VERIFY_PEER function where we override the verification
> result with the certificates from NSS.
Apparently, it is failing before calling our SSL_VERIFY_PEER function.
> If it's failing before reaching our SSL_VERIFY_PEER function, we should be
> able to use Curl's CURLOPT_CAINFO or CURLOPT_CAINFO_BLOB functions to set a
> custom CA certificate path (or in-memory buffer), maybe even an empty
> buffer, so that it proceeds further. ("man CURLOPT_CAINFO", "man
> CURLOPT_CAINFO_BLOB", or "man curl_easy_setopt" and read under the "SSL and
> SECURITY OPTIONS" section.)
So we would need to hard-code and try all possible paths to the CA
bundle on Unix systems?
> With the CURLOPT_CAINFO_BLOB option it might even be possible to skip the
> custom certificate verification we do later, and pre-populate Curl/OpenSSL
> with NSS certificates from the beginning, I just don't know enough about
> NSS to rely on that (eg. if you are using a cryptographic device or smart
> card in NSS, how does that work?). If that option is ok, then we might not
> even need the NSS libraries: recent versions of NSS store all the
> certificates in an SQLite database, which can be accessed with SQLite APIs
> directly, no need to build with or ship the NSS libraries at all.
If I understood correctly [1], a NSS-linked Curl would query NSS by
itself... are we not in this condition?
Thank you in advance and best regards,
--
Arrigo
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: MacOS and 4.1.12: connection ODB with ODS
Hi, Am 27.05.22 um 19:39 schrieb Bidouille: >> Short question: Are you testing on macOS Catalina or Montery? > Test on Catalina 10.15 (with MacStadium station) > But other french users are same issue with Monterey 12.4 OK, but is it Monterey on Intel or M1? Just out of interest, because we have another bug that does not occur on M1 with Rosetta 2... Do you have access to our M1 machine? Regards, Matthias > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: MacOS and 4.1.12: connection ODB with ODS
> Short question: Are you testing on macOS Catalina or Montery? Test on Catalina 10.15 (with MacStadium station) But other french users are same issue with Monterey 12.4 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Spam on the AOO forum
> On May 26, 2022, at 10:54 AM, Bidouille wrote: > >> Thanks, I had seen. But the choice is limited and then I can't take >> action for existing passwords. > > You could send a mass e-mail to all users (ACP > SYSTEM > General Tasks > > Mass e-mail) > If Dave is OK, it is possible to add this extension: > https://www.phpbb.com/customise/db/extension/selective_mass_emails Since each forum is now a separate installation of phpBB 3.3.7 it much less dangerous to try something normal out. You should try to install it from the admin UI to see if it works. If not then I can have a look. We should track this through a forum topic in the expected place. ATB, Dave > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: MacOS and 4.1.12: connection ODB with ODS
Hi, Am 27.05.22 um 15:38 schrieb Bidouille: > Testing with old 4.1.0 and still reproducible Thanks for testing! Short question: Are you testing on macOS Catalina or Montery? > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: MacOS and 4.1.12: connection ODB with ODS
Testing with old 4.1.0 and still reproducible - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
