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 was merely speculating on some bright future where Serf had a crypto
abstraction layer. Sorry for the confusion.
-- Brane
