3.0.0 release

[felixfontein]

SUMMARY

We currently have three deprecations:

• Support for ACME v1 protocol in the acme_* modules, to be removed in 3.0.0.
• Support for Ansible 2.9 (this allows to remove the slowest CI targets and some compatibility code). (The docker images in CI are huge, and change detection does not work for filter plugins - changes there trigger all tests.)
• Support for ansible-base 2.10 (this allows to remove some compatibility code).

Things we haven't deprecated yet, but could:

• pyOpenSSL support for openssl_pkcs12 module. cryptography's PKCS#12 support was added in cryptography 3.0, released in July 2020. To use iter_size with cryptography, 38.0.0 is needed (September 2022), and maciter_size is only supported with the pyOpenSSL backend.

So what should we do? When should we release 3.0.0, and should we start deprecating pyOpenSSL support for openssl_pkcs12 now, when 3.0.0 is released, or even only later on?

ISSUE TYPE

• Admin

COMPONENT NAME

collection

[felixfontein]

My personal preferrence would be:

• Deprecate pyOpenSSL support in openssl_pkcs12 in 3.0.0, and remove it in 4.0.0.
• Release 3.0.0 in spring (April/beginning of May) so it can be included in Ansible 8.0.0 (preliminary roadmap: https://github.com/ansible/ansible/pull/79598/files#diff-af3f8f1063fa1b2f7c29025776dc17df23476609d5a4b2ee16da18a89b5d8a76R25).

WDYT?

[felixfontein]

Both Ubuntu 18.04 (https://packages.ubuntu.com/search?suite=bionic&searchon=names&keywords=python3-cryptography) and 20.04 (https://packages.ubuntu.com/search?suite=focal&searchon=names&keywords=python3-cryptography) contain pre-3.0 releases of cryptography, and the same is true for Debian Stretch (https://packages.debian.org/stretch/python3-cryptography) and Buster (https://packages.debian.org/buster/python3-cryptography). Ubuntu 20.04 will be EOL in April 2025 (https://en.wikipedia.org/wiki/Ubuntu_version_history#Version_timeline), and Debian Buster in June 2024 (https://en.wikipedia.org/wiki/Debian_version_history#Release_timeline).

[felixfontein]

Alpine has been using >= 3.0.0 since v3.13 (https://pkgs.alpinelinux.org/packages?name=py3-cryptography&branch=v3.13&repo=&arch=&maintainer=), which is already EOL (https://alpinelinux.org/releases/).

With OpenSuSE I'm not sure, Tumbleweed has 38.0.4, but I'm not sure what Leap 15.4 has - https://software.opensuse.org/package/python3-cryptography and https://software.opensuse.org/package/python-cryptography are a bit confusing to me. (According to https://en.opensuse.org/Lifetime Leap 15.3 is EOL, so it's mainly 15.4 that matters.)

For Fedora, 36 and 37 have a rather new python3-cryptography (https://packages.fedoraproject.org/pkgs/python-cryptography/python3-cryptography/), and Fedora 35 is EOL (https://docs.fedoraproject.org/en-US/releases/eol/#_unsupported_fedora_linux_releases), but python36-cryptography is still cryptography 2.3 (https://packages.fedoraproject.org/pkgs/python3-cryptography/python36-cryptography/) :-(

[MarkusTeufelberger]

We might also think about dropping python2 support eventually on the target host... especially if only newish versions of cryptography work anyways (which don't support python2 any more). This could allow for some potentially nice things with type annotations, f-strings etc.

[felixfontein]

That's a good point. I guess dropping Python 2 support should probably wait for 4.0.0, but we can already bump the cryptography minimum requirements for 3.0.0 (and maybe drop some compatibility code needed for very old cryptography versions).

[felixfontein]

One other thing: I suggested a policy for community.docker (ansible-collections/community.docker#543 (comment)) to maintain at most one stable branch, so that releasing 3.0.0 would mean we declare stable-1 EOL (and remove its CI, and basically freeze it - or if that is too drastic, at least disable regular CI runs, and basically declare it basically "if you want to have something fixed, you fix it yourself, and make sure that CI still works"). What do you think about that?

[felixfontein]

FYI: ansibe-core 2.16 will be the last ansible-core version supporting Python 2 (see https://github.com/ansible/ansible-documentation/pull/174/files#diff-3104ffe53d108843024eafc6727807cae0590a65c1bd27e959c0fa3791a6fe6eR136), and it will be End of Life in May 2025 (https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html#ansible-core-support-matrix).

If we adopt that a new major release only supports the ansible-core releases that are not EOL by the time community.crypto X.0.0 is released (which would be similar to my proposal for community.general: ansible-community/community-topics#245 (comment)), then we can drop Python 2 support (at least for the main branch) in 2025.

Of course we could also drop support earlier, and only support a subset of Python versions that all supported ansible-core versions support. Especially for typing reasons, sticking to Python 3.9+ (or even "just" 3.8+) is a lot nicer than having to support Python 3.7 as well (the first 3.8+ only ansible-core version is 2.18, and 2.17 is EOL only in November 2025).

Instead of looking just at ansible-core Python requirements, we could combine both these and the minimal Python and cryptography requirements needed for current (i.e. non-EOL) LTS releases of a selected set of OSes. For that, we need a good way to check which versions these are. For Debian, Ubuntu, Alpine, and Fedora I think this is easy to figure out. For OpenSuSE and RHEL I have no idea how to query this information.

[felixfontein]

Proposal: let's release 3.0.0 in next spring (so it's out for inclusion in Ansible 12.0.0, whose feature freeze is likely in May 2025), drop support for all Python versions before 3.8, so we can have good typing everywhere, and require cryptography 3.4+ (that's the first version that drops Python 2 support and adds type hints). At the same time let's drop support for ansible-core < 2.16 (while not supporting all Python versions that 2.16 and 2.17 support, namely 2.7, 3.6, and 3.7.)

Everyone who needs support for Python before 3.8 and/or cryptography before 3.4 can still use community.crypto 2.x.y.

How does that sound?

[felixfontein]

Note that things like list[int] require Python 3.9+, and int | float requires Python 3.10+, but with from __future__ import annotations Python 3.8 also accepts that. Actually, I just tried, Python 3.7.0 also accepts it with the future import (the annotations future import was introduced in some pre-release of 3.7.0 IIRC). Without the future import, Python 3.8 and 3.7 both barf on such type hints. So maybe we can also support Python 3.7? cryptography itself also still supports 3.7; it dropped support for 3.6 over a year ago. They also do from __future__ import annotations everywhere...

[felixfontein]

I created a PR to deprecate the PyOpenSSL backend of openssl_pkcs12: #831