Re: Proposed patch for key managment

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Subject: Re: Proposed patch for key managment
Date: 2020-12-17 00:15:37
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 16 Dec 2020, at 17:26, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Greetings,
> * Michael Paquier (michael(at)paquier(dot)xyz) wrote:
>> On Tue, Dec 15, 2020 at 02:09:09PM -0500, Stephen Frost wrote:
>>> Yeah, looking at what's been done there seems like the right approach to
>>> me as well, ideally we'd have one set of APIs that'll support all these
>>> use cases (not unlike what curl does..).
>> Ooh... This is interesting. What did curl do wrong here? It is
>> always good to hear from such past experiences.
> Not sure that came across very well- curl did something right in terms
> of their vTLS layer which allows for building curl with a number of
> different SSL/TLS libraries without the core code having to know about
> all the differences.

The vtls layer in libcurl is actually quite similar to what we have in libpq
with be-secure.c and be-secure-*.c for TLS and with what Michael has been doing
lately with cryptohash.

In vtls library contexts are abstracted to the core code, with implementations
supplying a struct with a set of function pointers implementing functionality
(this difference is due to libcurl supporting multiple TLS libraries compiled
at the same time, something postgres IMO shouldn't do). We do give
implementations a bit more leeway with how feature complete they must be,
mainly due to the wide variety of libraries supported (from OpenSSL to IBM
GSKit and most ones in between). While basic it has served us quite well and
we have had first time contributors successfully come with a new TLS library as
a patch.

What we have so far in the tree (an abstract *reasonably generic* API hiding
all library context interactions) makes implementing support for a new TLS
library less daunting as no core code needs to be touched really. Having
kicked the tyres on this a fair bit I really think we should maintain that
separation, it's complicated enough as it is given just how much code needs to
be written.

cheers ./daniel

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2020-12-17 00:31:08 Re: On login trigger: take three
Previous Message Alastair Turner 2020-12-17 00:12:46 Re: Proposed patch for key managment