| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Subject: | Re: LibreSSL and OpenSSL separation in libpq to support 1.1.1 deprecation |
| Date: | 2026-08-12 09:51:57 |
| Message-ID: | f3806b11-7d89-4888-8cdd-4ec453b5abe3@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 09.07.26 23:14, Daniel Gustafsson wrote:
> The attached implements LibreSSL as a separate TLS library implementation (*)
> in libpq with fe-secure-libressl.c and be-secure-libressl.c along with build
> and test infrastructure.
I'm skeptical about this approach. What has been presented so far
doesn't convince me that the differences between the openssl and the
libressl variants will be larger than their commonalities.
As an example, my recent patch [0] works just the same on both (AFAICT).
I didn't have to worry about the differences at all.
Under the proposed system, I would have to make the same code changes
twice, test everything twice (including obtaining libressl in the first
place and set up a separate build for it). Doesn't sound appealing.
Another possible future of the proposed system is that changes and
improvements for the libressl variant are forgotten or just skipped,
which would lead to it degrading over time, while now at least it is
sort of dragged along by force.
[0]:
https://www.postgresql.org/message-id/953bceb7-340d-4717-9682-0ebe65c4b57e%40eisentraut.org
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hayato Kuroda (Fujitsu) | 2026-08-12 10:31:20 | RE: 019_replslot_limit.pl might fail due to checkpoint skipped |
| Previous Message | Ashutosh Bapat | 2026-08-12 09:41:47 | Re: Error handling in after-startup shmem requests |