Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
Date: Tue, 09 Feb 2021 15:19:38
In Reply to: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390 by "Michał Górny"
1 On Mon, 2021-02-08 at 12:19 +0100, Michał Górny wrote:
2 > FYI the developers of dev-python/cryptography decided that Rust is going
3 > to be mandatory for 1.5+ versions. It's unlikely that they're going to
4 > provide LTS support or security fixes for the old versions.
5 >
6 > Since cryptography is a very important package in the Python ecosystem,
7 > and it is an indirect dependency of Portage, this means that we will
8 > probably have to entirely drop support for architectures that are not
9 > supported by Rust.
10 >
11 > I...]
12 >
13 > I've raised a protest on the cryptography bug tracker [2] but apparently
14 > upstream considers Rust's 'memory safety' more important than ability to
15 > actually use the package.
16 >
17 > Honestly, I don't think it likely that Rust will gain support for these
18 > platforms. This involves a lot of work, starting with writing a new
19 > LLVM backend and getting it accepted (getting new code into LLVM is very
20 > hard unless you're doing that on behalf one of the big companies). You
21 > can imagine how much effort that involves compared to rewriting the new
22 > code from Cryptography into C.
23 >
24 > If we can't convince upstream, I'm afraid we'll either have to drop
25 > these architectures entirely or fork Cryptography.
26 >
27 >
28 > [1]
29 > [2]
31 So it seems that upstream has practically closed the discussion,
32 and the short summary is that they only care for the 'majority' of
33 users, they don't care for minor platforms (but we're free to port
34 LLVM/Rust to them) and -- unsurprisingly -- this is a part of crusade
35 towards promoting Rust.
37 Given the aggressive opinions of a number of Python core devs
38 participating in the discussion, I'm afraid that it is quite probable
39 that a future version of CPython may require Rust. In fact, they've
40 already started having knee-jerk reactions to the problem at hand [1].
41 To be honest, I've never thought I'd be this disappointed in Python
42 upstream.
44 Good news is that they've promised to keep a LTS branch with security
45 fixes to the non-Rust version. Until end-of-year. And they've pretty
46 aggressively stated that they won't fix anything except security bugs
47 with a CVE assigned. So if it stops building for whatever reason, we're
48 on our own.
50 I've reached out to Debian and they're planning to remove support for
51 minor architectures for this package in the next release. However,
52 Python is not as central to them as it is to us. Alpine is also
53 affected but seems intent on pushing Rust forward, so they'll probably
54 drop these architectures as well.
56 Mike's submitted a PR to remove (unnecessary) cryptography dep from our
57 urllib3/requests packages [2]. This should make it possible to avoid
58 cryptography at least on some systems. However, it is still an indirect
59 test dependency of these packages, so we're going to have a hard time
60 keeping them properly tested.
62 At this point, I'm really depressed about this and I'm seriously
63 wondering why I'm wasting so much effort on open source. I don't see
64 a good way out of it. Rust could be a nice language -- but it won't if
65 it continues to be surround by arrogant zealots who want to destroy
66 everything in their path towards promoting it.
68 The first big blocker we're going to hit is trustme [3] package that
69 relies on cryptography API pretty heavily to generate TLS certs for
70 testing. If we managed to convince upstream to support an alternate
71 crypto backend, we'd be able to retain minor keywords a lot of packages
72 without too much pain.
74 [1]
75 [2]
76 [3]
78 --
79 Best regards,
80 Michał Górny