On Wed, Aug 12, 2026 at 8:14 AM Daniel Gustafsson <[email protected]> wrote: > > 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. > > Testing everything twice isn't new, we already need to test all libpq TLS > related changes on both OpenSSL and LibreSSL since they are supported. > Trusting that one works because the other one does is a brittle assumption and > I've had to revert commits because of precisely that reason. Applying code > twice is a real pain though, but navigating an increased level of ifdefs won't > be pleasant either (assuming it happens of course).
+1 -- this is where I kind of raised an eyebrow at your argument, Peter. We're already doing that, and we *must* do it, whether it's obvious or not that said work is being done. I'm very much in favor of splitting that apart and making the invisible pain visible (at least conceptually -- I haven't had a chance yet to sit down and look at this particular patch, and I'm very sorry for that; maybe a hybrid such as Alvaro's suggestion would work too). In my opinion, keeping the two same-in-name-but-not-in-practice implementations together is keeping things more brittle, not less, most recently when I look at the SNI work. If we split the two, then in addition to not risking 1.1.1-based destabilization as we move to 4.0 APIs, we can investigate porting LibreSSL code on top of their libtls API instead. > Again, all of this is moot if we don't deprecate 1.1.1 support, but I don't > think we are doing our users a service by allowing them to use an TLS library > which when v20 goes EOL has been out of security updates for 8+ years. We should do that for PG20. I'm continuing to push for that in other threads [1]. No one has said "no" yet, I think, so IMNSHO we should just do it. Thanks, --Jacob [1] https://postgr.es/m/CAOYmi%2B%3DVJJ%3D1a-wHwWd2mTgQ3bkHzAUHCFssosF7h1y8TEN%2Biw%40mail.gmail.com
