> On 4 Apr 2024, at 00:51, Peter Eisentraut <pe...@eisentraut.org> wrote: > > On 30.03.24 22:27, Thomas Munro wrote: >> On Sun, Mar 31, 2024 at 9:59 AM Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Thomas Munro <thomas.mu...@gmail.com> writes: >>>> I was reminded of this thread by ambient security paranoia. As it >>>> stands, we require 1.0.2 (but we very much hope that package >>>> maintainers and others in control of builds don't decide to use it). >>>> Should we skip 1.1.1 and move to requiring 3 for v17? >>> >>> I'd be kind of sad if I couldn't test SSL stuff anymore on my >>> primary workstation, which has >>> >>> $ rpm -q openssl >>> openssl-1.1.1k-12.el8_9.x86_64 >>> >>> I think it's probably true that <=1.0.2 is not in any distro that >>> we still need to pay attention to, but I reject the contention >>> that RHEL8 is not in that set. >> Hmm, OK so it doesn't have 3 available in parallel from base repos. >> But it's also about to reach end of "full support" in 2 months[1], so >> if we applied the policies we discussed in the LLVM-vacuuming thread >> (to wit: build farm - EOL'd OSes), then... One question I'm unclear >> on is whether v17 will be packaged for RHEL8. > > The rest of the thread talks about the end of support of RHEL 7, but you are > here talking about RHEL 8. It is true that "full support" for RHEL 8 ended > in May 2024, but that is the not the one we are tracking. We are tracking > the 10-year one, which I suppose is now called "maintenance support". > > So if the above package list is correct, then we ought to keep supporting > openssl 1.1.* until 2029.
Not 1.1.* but 1.1.1+. In the old OpenSSL version numbering scheme, releases changing the last digit would contain new features and releases that updated the appended letter only fixed bugs. -- Daniel Gustafsson
