On Fri, 20 Jun 2025 at 22:38, Branko Čibej <br...@apache.org> wrote:
> On 20. 6. 25 21:43, Ivan Zhakov wrote: > > On Thu, 19 Jun 2025 at 15:56, Graham Leggett<minf...@sharp.fm.invalid> > > wrote: > > > >> On 18 Jun 2025, at 22:39, minfrin (via GitHub)<g...@apache.org> wrote: > >> > >>> minfrin opened a new pull request, #8: > >>> URL:https://github.com/apache/serf/pull/8 > >>> > >>> - Add serf_ssl_cert_uri_set(), a callback to set the URL of a > >> certificate store. > >>> - Use the OSSL_STORE API from OpenSSL to read certificates and keys. > >> Certs and keys are read from a URL instead of a file path. The default > URL > >> scheme is file:. > >>> - Keep fallback support for the existing > >> serf_ssl_client_cert_provider_set() callback, which reads exclusively > from > >> a local PKCS12 file. > >>> - Support full intermediate certificate handling. Previously > whatever > >> was in the PKCS12 file was blindly passed to the the server on the > >> assumption the administrator had pre-done the work constructing the > >> certificate chain. Now we make no assumption as to the size of the > >> certificate store, if a Windows personal certificate store of a MacOS > >> keychain is used, we search for the most appropriate leaf certificate > that > >> matches what is requested by the server. > >>> - Update test cases to handle both URIs and PKCS12 files. > >>> > >>> Note: tests will fail on modern unix until reference to now-removed > >> MD5 is fixed. This test failure is unrelated. > >> > >> Hi Graham, > > I didn't look at the patch yet, but I have general concern: serf doesn't > > depend on OpenSSL. E.g. it may use Crypto API on Windows in future. So I > > think we should avoid exposing OpenSSL in public serf API. Is it possible > > to abstract URI somehow? Maybe some kind of flag? > > > Agree with the concept of leaving OpenSSL specifics out of the public API. > > Am sceptical about abstracting OpenSSL out of Serf's internals. It's a > nice goal to have, sure; for the Windows CryptoAPI as well as macOS > network security layer, or gnutls or LibreSSL (this last works out of > the box, but behaves differently from OpenSSL 3 or even 1.1.1). I'm sure > "someone" will have the time and motivation to make this small change. :D > > I agree that full abstraction of OpenSSL URI is a complex task. But I was thinking of something very simple. Like serf_ssl_cert_enable_system_certs(someflags ?). -- Ivan Zhakov