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
-- Brane
