On 2026-Aug-12, Peter Eisentraut wrote: > 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.
I think it should be possible to have one file where the common routines that are identical for both libraries live (say be-secure-lossl.c for "libre/open" or whatever), and the corresponding be-secure-libressl.c and be-secure-openssl.c files only have the routines that differ between the two implementations. So the common code appears once and has to be patched just once, and we would only have differences where we must. Probably it's easiest to do this by having one .c file that's included by the other two, to avoid having to export the static variables and such. (Looking at the patch Peter mentions and the diff between the two be-secure files after Daniel's patch, the code involved there would be wholly in the common file, so there would be no need for double patching.) The diff between the two files has 552 "-" lines (mostly, libressl removing the SNI code), 89 "+" lines, and 1889 common lines. So this is not a completely absurd approach. In the src/interfaces/libpq code, the fraction of code that is common is even more pronounced. (In fact looking at that diff I wonder if fe-secure-libressl.c just didn't keep track of recent changes e.g. 7d45a6dc1974.) -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "We have labored long to build a heaven, only (Prof. Milton Glass) to find it populated with horrors" (Watchmen, Alan Moore)
