Update to reflect that TLS1 and TLSv1.1 are now deprecated
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t76958psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 11:50 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t76958_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t76958_1 && git checkout t76958_1Patchset v1 (message #1) is on t76958_1
The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the
attached rewords where we say our default of 1.2 is industry best practice with
a link to the authoritative source.
--
Daniel Gustafsson https://vmware.com/
On 3/24/21 5:49 AM, Daniel Gustafsson wrote:
The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the
attached rewords where we say our default of 1.2 is industry best practice with
a link to the authoritative source.
I would s/as of/stated in/ and add a comma after RFC 8996, but otherwise
+1 from me.
Jonathan
On 24.03.21 10:49, Daniel Gustafsson wrote:
The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the
attached rewords where we say our default of 1.2 is industry best practice with
a link to the authoritative source.
The "industry best practices" the original text refers to are things
like PCI-DSS and various announcements by browser vendors. Those best
practices have already been around for long before RFC 8996. I think
this patch is mangling the two concepts of what is best practice and
what is officially deprecated, and since when each of them applies.
If we want to throw RFC 8996 into the mix, we could drop the reference
to best practices and just write something like
"The default is TLSv1.2. Note that all older versions are deprecated as
of this writing (see RFC 8996)."
However, now that I read this, it's not clear from this who is doing the
deprecating. Someone could wonder, does this mean PostgreSQL will drop
support for it?
Maybe the old wording is best and more timeless, and if someone wants to
question it they can do their own research.
On 24 Mar 2021, at 21:07, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
On 24.03.21 10:49, Daniel Gustafsson wrote:
The recently published RFC 8996 deprecates the use of TLSv1 and TLSv1.1, the
attached rewords where we say our default of 1.2 is industry best practice with
a link to the authoritative source.The "industry best practices" the original text refers to are things like PCI-DSS and various announcements by browser vendors. Those best practices have already been around for long before RFC 8996. I think this patch is mangling the two concepts of what is best practice and what is officially deprecated, and since when each of them applies.
Well, since the publishing of RFC 8996 as a BCP document the industry best
practice is to not allow TLSv1.0 or TLSv1.1 at all, so claiming 1.2 as the
default with others available being best practice is concept mangling to some
extent as well.
However, now that I read this, it's not clear from this who is doing the deprecating. Someone could wonder, does this mean PostgreSQL will drop support for it?
OpenSSL and/or distributions are likely to beat us to it, so users may find
their servers unreachable after upgrading OpenSSL because of the protocol no
longer being available. Maybe it's the below wording which should reflect that
all versions of OpenSSL will restrict the available protocols, either because
of age or RFC 8996?
"Older versions of the OpenSSL library do not support all values; an
error will be raised if an unsupported setting is chosen."
--
Daniel Gustafsson https://vmware.com/