On Fri, 20 Jun 2025 at 22:51, Branko Čibej <br...@apache.org> wrote:
> On 20. 6. 25 22:41, Ivan Zhakov wrote: > > 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 > > ?). > > Misunderstanding here. It's clearly possible to do this without exposing > the URIs in the public API, and it's what we should do. I agree it's > unlikely that a user would want to, e.g., request certs from the macOS > Keychain instead of the Windows certificate store while running on > Windows. Although, who knows what kind of weirdness happens in > enterprise deployments. > > I don't remember MacOS Keychain, but Windows have concept "machine" and "user" certificate store. Probably macOS KeyChain has the same. So maybe it makes sense to expose flags to be able to select "machine", "user" or both certificate stores. -- Ivan Zhakov
