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? -- Ivan Zhakov
