| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "Koshi Shibagaki (Fujitsu)" <shibagaki(dot)koshi(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |
| Date: | 2024-02-20 12:40:27 |
| Message-ID: | 07dd63d3-3efe-45da-8efe-9fc72ae4ddef@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 20.02.24 12:39, Daniel Gustafsson wrote:
> A fifth option is to throw away our in-tree implementations and use the OpenSSL
> API's for everything, which is where this thread started. If the effort to
> payoff ratio is palatable to anyone then patches are for sure welcome.
The problem is that, as I understand it, these crypt routines are not
designed in a way that you can just plug in a crypto library underneath.
Effectively, the definition of what, say, blowfish crypt does, is
whatever is in that source file, and transitively, whatever OpenBSD
does. (Fun question: Does OpenBSD care about FIPS?) Of course, you
could reimplement the same algorithms independently, using OpenSSL or
whatever. But I don't think this will really improve the state of the
world in aggregate, because to a large degree we are relying on the
upstream to keep these implementations maintained, and if we rewrite
them, we become the upstream.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2024-02-20 12:49:08 | Re: Synchronizing slots from primary to standby |
| Previous Message | Daniel Gustafsson | 2024-02-20 12:35:02 | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |