On Sat, 30 May 2020 14:31:48 -0700 "TJ Saunders" <[email protected]> wrote:
> Hello, ProFTPD developers! I'm contemplating the growing complexity > of ProFTPD's TLS/crypto codebase, and how to reduce it. Much of that > complexity is related to OpenSSL, and its changing APIs over the > years. > > Thus I'd like to start phasing out support for older OpenSSL > versions. How old? Well, I'm hoping you can help me decide that. > > We can use the OPENSSL_API_COMPAT macro (at least since > OpenSSL-1.1.0), like this PR: > > https://github.com/pyca/cryptography/pull/4313 > > I know that there are some platforms, like HP-UX or AIX, where > bleeding-edge OpenSSL versions may not be used/available. But > support for OpenSSL before 1.0.0 can be phased out, yes? > > Part of this will be establishing criteria for this project, going > forward, for knowing when/how to EOL support for older library > versions (not just OpenSSL) -- and how to announce that, with enough > advance notice for packagers/distros to be prepared. > > I look forward to hearing your thoughts on this topic! Well it looks like support for OpenSSL < 1.1.0 has already been phased out in 1.3.7rc4: it uses SSL_SESSION_set1_id_context(), which was introduced in OpenSSL 1.1.0. As for how long I support older systems, that depends on which hat I'm wearing: As a packager for Fedora proper, which only has a lifespan of 13 months from release, support for older versions is a non-issue. Indeed, the problem is often the other way around, with system libraries too new for some upstream projects to be able to handle. As a packager for Fedora EPEL, I'm looking to support a release until it reaches its end of life. The oldest still-supported version is EPEL-6, which is due to reach end of life in November, 10 years after the initial release of Red Hat Enterprise Linux 6.0. However, I try to avoid doing major version bumps in EPEL, so the version of proftpd in EPEL-6 is proftpd 1.3.3g. I try to backport security fixes where possible, and I've managed it so far. If there was a case where I couldn't manage it, I'd be prepared to do a major version bump if necessary. RHEL-6 has openssl 1.0.1e, RHEL-7 has openssl 1.0.2k and RHEL-8 has openssl 1.1.1c. As an independent packager with my own personal repository, I try to build the latest version of proftpd for all Fedora and RHEL releases back to the time of the oldest currently-supported RHEL version, which is currently Fedora 13 and RHEL-6. Fedora 13 has openssl 1.0.0d. When RHEL-6 reaches EOL, I'll move up to Fedora 19 being my oldest supported version and that has OpenSSL 1.0.1e. The packages on ancient EOL Fedora releases are hardly used by anybody and if they fail to build, it's not a big issue. I find value in doing the builds because it helps when debugging issues relating to system package versions - I can see more precisely where something stopped working by looking at old Fedora versions than I can by looking a the small number of RHEL versions. So, overall, I'd like to see support remain for libraries for 10 years, which would mean that support for OpenSSL < 1.0.0 is no longer useful from my perspective. On the other hand, if that's a hard burden, it's quite understandable and I'd have no objections if you shortened the support lifetime. If that meant that the latest and greatest proftpd version wasn't available on an old RHEL version, then so be it. Paul. _______________________________________________ ProFTPD Developers List <[email protected]> https://lists.sourceforge.net/lists/listinfo/proftp-devel
