Python/cryptography – Dependency on rust removes support for number of platforms(github.com)
github.com
Python/cryptography – Dependency on rust removes support for number of platforms
https://github.com/pyca/cryptography/issues/5771
6 comments
The devs intentionally released a version with Rust as an optional but enabled-by-default dependency. I'm not sure how this counts as "jumped the gun" - it's basically the only safe way to roll out this change. Given the number of people in the thread who are doing automated updates in production pipelines to the latest published version (there's pushback on having to read announcements, pushback on having to read CI output to see deprecation warnings, etc.), it doesn't seem like there's any other way to get people's attention other than enabling it by default and making it easy to disable it.
They left two ways to get things working - you can set an environment variable, or you can pin the previous version, because 3.4 has no functional changes from 3.3.2. (The complete set of changes in this version are dropping Python 2, shipping a newer wheel baseline ABI, adding Rust, and adding type hints. No new features and certainly no security fixes relative to 3.3.2.)
What is the other option here?
They left two ways to get things working - you can set an environment variable, or you can pin the previous version, because 3.4 has no functional changes from 3.3.2. (The complete set of changes in this version are dropping Python 2, shipping a newer wheel baseline ABI, adding Rust, and adding type hints. No new features and certainly no security fixes relative to 3.3.2.)
What is the other option here?
Its worse then that because most of the users of cryptography aren't using it directly. It is often a layer or 3 down the dependency graphs. So its not unreasonable that the users weren't testing it.
There is a range of things the cryptography team could have done better.
1.) made it a major version change (i.e. 4.x) or even a new package name. This could be a bit extreme, but I would suggest if they are shifting to integrating more Rust, the package will likely have heavy internal changes.
2.) made a larger effort to understand how impactful the rust transition would be to non cryptography developers.
3.) Reached out to distro packagers to make sure they are aware. It appears they were focused more on PyPI users.
4.) Had a longer period of transition, Ideally with a public deprecation warning so that these users have had at least 6 months of logs they ignored before it broke.
However I think the blame needs to go to the packages that are using cryptography like ansible. They shouldn't have a floating dependency that allows a jump to a version that may be incompatible. Secondly the users of the package should be monitoring their upstream.
I think this is a larger issue under the surface for these alternative hardware platforms. Rust is becoming a major development language, and its side effects include much higher resource usage at compile time. I am not sure your going to be able to self host a Rust compiler on a m68k platform. This may be one of the points where a somewhat large portion of our computing hardware is "cut off", or alternative approaches will be required such as cross compilation. If Fedora, Debian, NetBSD and Gentoo wish to keep supporting these platforms it might require a considerable investment, however I wonder if it will be worth the time for most people.
There is a range of things the cryptography team could have done better.
1.) made it a major version change (i.e. 4.x) or even a new package name. This could be a bit extreme, but I would suggest if they are shifting to integrating more Rust, the package will likely have heavy internal changes.
2.) made a larger effort to understand how impactful the rust transition would be to non cryptography developers.
3.) Reached out to distro packagers to make sure they are aware. It appears they were focused more on PyPI users.
4.) Had a longer period of transition, Ideally with a public deprecation warning so that these users have had at least 6 months of logs they ignored before it broke.
However I think the blame needs to go to the packages that are using cryptography like ansible. They shouldn't have a floating dependency that allows a jump to a version that may be incompatible. Secondly the users of the package should be monitoring their upstream.
I think this is a larger issue under the surface for these alternative hardware platforms. Rust is becoming a major development language, and its side effects include much higher resource usage at compile time. I am not sure your going to be able to self host a Rust compiler on a m68k platform. This may be one of the points where a somewhat large portion of our computing hardware is "cut off", or alternative approaches will be required such as cross compilation. If Fedora, Debian, NetBSD and Gentoo wish to keep supporting these platforms it might require a considerable investment, however I wonder if it will be worth the time for most people.
This is a good change. Compatibility for the sake of compatibility holds back software. Its one of the reasons why software is such garbage.
C is not a safe language. It can and should be replaced entirely by Rust, or similar new languages.
Please, just make software better.
C is not a safe language. It can and should be replaced entirely by Rust, or similar new languages.
Please, just make software better.
In hindsight, probably would’ve been way better to ship a `cryptography2` package and deprecate the old package.
That way you get the benefits of using rust without the anger about the sudden breakage of a transitive dependency.
In terms of floating versioning, I honestly think it’s not reasonable to ask packages to do this, because then you get into dependency hell with unfixable dependency conflicts.
That way you get the benefits of using rust without the anger about the sudden breakage of a transitive dependency.
In terms of floating versioning, I honestly think it’s not reasonable to ask packages to do this, because then you get into dependency hell with unfixable dependency conflicts.
Seems logical to use Python as a high level interface to Rust
I see two distinct views: - Devs are saying it’s not their job to cater to ancient systems, or to cater to every user; Rust will improve safety, which is more important than supporting <your system>. - Users are complaining that this change is unnecessary, they weren’t informed, and this is going to reduce security for older systems that will miss out on this and future releases.
Repeat times infinity.
On the one hand, I feel like the devs jumped the gun on this change, and may not understand their users as well as they think. As someone pointed out on the issue, a great deal of Linux code would benefit from Rust, but it’s imprudent to simply rewrite it and expect people to get with the program. On the other hand, I’m sensing a lot of entitlement in the thread from people who don’t realize they’re getting cryptography for free.
This pattern of discussion (and finger pointing) is repeated again and again in the open source community, and it will be ad nauseam until we decide on a clear contract between consumers and producers of open-source software.