Subject: Follow-up on OpenSSL "engines" and "providers"

From: Bear Giles <[email-masked]>
Date: Thu, 29 Jan 2026 10:15:35 -0700

I've been doing a lot of thought about how my prior and current work could
be useful, not just intellectual exercises that might be useful to some
people, and keep coming back to the idea that my focus should probably be
other server-side extensions and not the SQL user. They won't be excluded -
far from it - but the emphasis should be providing an open source solution
that can handle much of the encryption and authentication required by other
extensions.

Most importantly - giving them a way to avoid knowing their private keys.
They can't expose what they don't have.

---

From: Daniel Gustafsson <[email-masked]>
Date: Fri, 13 Feb 2026 12:42:29 +0100

> On 29 Jan 2026, at 18:15, Bear Giles <[email-masked]> wrote:

> Most importantly - giving them a way to avoid knowing their private keys. They can't expose what they don't have.

FWIW there has been discussion among those of us who regularly dip our toes in
the OpenSSL support code to add some form of integration with vaults (like
vault from Hashicorp, ipa/idm from Redhat, Keychain from Apple etc) for storing
secrets.  AFAIK there are no concrete patches to look at (yet?), but there is
interest and it will most likely be discussed at PGConf.dev in case you are
thinking of attending.

--
Daniel Gustafsson

---

From: "Anders Åstrand" <[email-masked]>
Date: Mon, 16 Feb 2026 12:12:08 +0100

> interest and it will most likely be discussed at PGConf.dev in case you are

I've been toying with the idea of building a key manager extension that could be used by others to get hold of secrets or use encryption keys without necessarily having to know where those secrets would be stored. It could use loadable shared libraries for the different providers similar to how we do it for OAuth.

I don't believe this code would have to start out in core at all, but maybe we will want to integrate it later for reasons.

-- 

Anders Åstrand
Percona