Cryptography 3.3 LTS release without Rust bindings

[tiran]

@kaniini proposed the creation of a PyCA Cryptography LTS release branch. The LTS branch would give users more time to adjust their infrastructure for Rust requirements. Alpine and musl libc maintainers might even get manymusl binary wheels ready in time. I support their proposal and would be interested to assist with and use a LTS release in RHEL 8 and CentOS.

To reduce maintenance overhead and to set user expectations, a long term support branch should be clearly scoped. Therefore I propose

• LTS is based on 3.3.x branch (no Rust dependency)
• only updates for security issues (implies that bug must get a CVE).
• EOL on 2021-12-31. No further updates after EOL date
• supports for currently supported OpenSSL API/ABI. That implies compatibility patches for upcoming OpenSSL 3.0.0 will not be backported.
• feature updates are out of scope
• source-only releases, so you don't have to release a new LTS when OpenSSL does a security update. Users can use binary wheels of latest update.

This proposal should keep the workload small and cover majority of users.

10 months until EOL should be sufficient for majority of users to get Rust infrastructure in place. The next stable Debian 11 (Bullseye) should be released roughly half a year before the EOL date. Latest Alpine, CentOS 8, Fedora, and Ubuntu already have recent enough Rust.

[reaperhulk]

The primary challenge I see for this is keeping CI functional. Since we don't need to maintain a functioning wheel build system for this the problem is simpler, but, for two examples, we'd probably also want to freeze the docker containers on a specific tag and pin our test dependencies (which we currently leave open deliberately). 3.3.x was also the last release we supported Python 2 on so the test infra would need to maintain the ability to test against that.

I agree we need an official end date if we do this, but I'm not sure what the right date is for it.

[alex]

My default disposition is strongly anti-LTS. I think they tend to add a lot of maintenance burden for the folks who maintain them, as well as other OSS maintainers who get demands to support older versions of things as a result.

Indeed, @reaperhulk and I discussed doing an LTS a year ago for Python2 support, and concluded it was simply easier to support Python2 for an additional year rather than to support a separate LTS branch.

I also have philosophical concerns with the LTS theory of security: fixing vulnerabilities isn't the only way to improve security. Hardening, detection, privsep, etc. contribute much more to security (https://alexgaynor.net/2018/jul/20/worst-truism-in-infosec/). Just because you have all known bugs fixed doesn't make you equally secure: https://alexgaynor.net/2019/mar/07/chrome-windows-exploit-security-beyond-bugfixes/

There's also a practical concern: If we do source only releases, this will work well for Linux distribution maintainers who do their own builds, but wreak havoc on folks who install from PyPI. An alternate solution might be to simply not post to PyPI, but now we're in seriously strange territory.

I'm still open to being persuaded, but this is where I'm at now.

[tiran]

@alex
LTS may be the wrong term. Would you rather agree to an extended security fix policy for 3.3.x branch, similar how CPython does source-only security fixes? In my opinion there is some merit in backporting security fixes to a non-Rust branch for a short while. (I'm also aware that the new name is borderline bike-shedding.)

The target audience for an extended security fix release would be users that download sources from PyPI.

Linux distribution package maintainers typically cherry-pick and backport security fixes. For example I maintain internal forks of cryptography for RHEL. The RHEL 8.4 rebase to 3.2.1 contain backport of CVE-2020-36242, compatibility with old pytest, NPN APIs for older PyOpenSSL, encode_rfc6979_signature, and others. It's basically a 3.2.1 that is compatible with software written for 2.3.0. The CentOS git contains a snapshot of my backports.

@reaperhulk
I completely forgot that 3.3.x has Python 2 support. How annoying...

[leo60228]

Python 2 isn't getting security fixes. I don't really have any stake in this, but I'd consider it reasonable if the 3.3.x branch didn't have Python 2.

[kaniini]

Alpine has deprecated Python 2, so we have no interest in LTS for that reason.

Rust has a lot of problems for musl distributions (the default targets in rustc force static linking for example), so we have to define new targets, which makes getting rust everywhere problematic (we still lack rust for 2 release archs due to being unable to build cross compilers).

I suspect that there are other scenarios where upgrading or introducing Rust into an already released distribution is problematic.

Regarding commitment level, we would be glad to maintain the LTS ourselves without @alex having to spend time on it, other than his notifying us about things that need to be backported.

[alex]

If your definition of "needs backport" is "has a CVE", then we'll continue to issue CVEs for any vulnerability, and we'll make sure the version metadata is accurate. Do y'all have a capacity to automatically pull in CVEs, or do you need an explicit notification process?

[kaniini]

As long as there is CVEs listed in the git history, we can handle backporting anything we need, even if it means fixing the C code based on changes done to the equivalent Rust code.

I don't think Alpine is alone in this situation though, I suspect that CentOS/RHEL 8 is unlikely to ever get a new enough Rust, for example, but I don't know their policies.

edit: apparently CentOS does have a new enough rust. I guess that's what appstreams are about :)

[reaperhulk]

We don't consistently put CVEs in our git logs at the moment, but there's no real reason we couldn't make that part of our security response policy.

[alex]

Right, we put them in the changelog (and the CVE database, obviously). I don't see why we couldn't put them in git though!

…

On Tue, Feb 9, 2021 at 5:50 PM Paul Kehrer ***@***.***> wrote: We don't consistently put CVEs in our git logs at the moment, but there's no real reason we couldn't make that part of our security response policy. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBEOSCNXQRTWJAD23GLS6G3ZVANCNFSM4XK7UDDQ> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[tiran]

I don't think Alpine is alone in this situation though, I suspect that CentOS/RHEL 8 is unlikely to ever get a new enough Rust, for example, but I don't know their policies.

edit: apparently CentOS does have a new enough rust. I guess that's what appstreams are about :)

Yeah, RHEL 8.3 and CentOS 8.3-2011 have rustc-1.45. It's totally feasible to rebase the RHEL 8 python-cryptography package to a future version with Rust. I have most pieces in place.

[kuwv]

I'm really confused. How could the introduction of rust bindings ever be considered a minor version when there is no backwards compatibility.

This specifically breaks established spec: https://semver.org/

Just asking because I'm sure this could have been handled a bit cleaner with a bump to 4.0.0.

[alex]

Take a look at #5801 where we discuss this very question. (Spoiler: it's not at all clear this meets the semver standard for a major release at all.)

[kuwv]

Well, thank you for your efforts. I have no intention of tell you what you should be doing. I do agree with your arguments against C and the direction towards rust for future use.

It was just a bit disruptive unfortunately. I do think a 3.3.x would be beneficial.