[gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip
(I replied via https://groups.google.com/g/linux.gentoo.dev/c/WG-OLQe3yng
"Reply all" (which only replied to the list AFAICT) but I did not
subscribe to gentoo-dev via the official
https://www.gentoo.org/get-involved/mailing-lists/ so my reply is
missing)
On Thu, Feb 4, 2021 at 4:09 PM Manoj Gupta wrote:
>
> Hi gentoo devs,
>
> This question is regarding interaction of fowners [1] and estrip
> functionality in portage.
> fowners is used on various binaries and files to assign the ownership to
> specific users or group.
>
> GNU objcopy and strip do not change the file ownership when run as root.
> However, llvm's versions do not preserve it and instead make root the owner
> of the modified file.
> e.g.
> sudo strip keeps the original ownership .
> sudo llvm-strip will change ownership to root.
>
> We were trying to have llvm objcopy with a patch [3] to have the same
> behavior as GNU but LLVM developers pointed out that GNU implementation is
> thought to have a security issue:
> https://sourceware.org/bugzilla/show_bug.cgi?id=26945
> We have modified the LLVM patch to avoid chown on the final file and rather
> doing it on the temporay file but I am not sure if that will be enough to
> placate the llvm devs.
>
> What does everyone think of modifying usages of calls to strip and objcopy
> inside estrip so that file ownership is manually restored. e.g
>
> owner=$(stat -U file)
> group=$(stat -G file)
> strip
> chown owner:group file
>
> [1] https://devmanual.gentoo.org/function-reference/install-functions/
> [2] https://gitweb.gentoo.org/proj/portage.git/tree/bin/estrip
> [3] https://reviews.llvm.org/D93881
>
> Thanks,
> Manoj
> This is probably safe in portage because the temporary directory is no
> longer user-accessible, but it seems perverse to seek feature parity by
> adding the security vulnerability into the implementations that don't
> have it, rather than by removing it from the ones that do. Hopefully
> LLVM just accepts the patch.
In binutils, objcopy/strip call 'smart_rename', which has a
vulnerability: https://sourceware.org/bugzilla/show_bug.cgi?id=26945
The first resolution used renameat2, which is not intercepted by
fakeroot (Arch Linux runs strip and tar under fakeroot, then
extracting the tar to the system /).
After discussion with binutils upstream, Arch Linux's resolution is to
use `strip a -o b` instead of `strip a`:
https://git.archlinux.org/pacman.git/commit/?id=88d054093c1c99a697d95b26bd9aad5bc4d8e170
For some unclear reason the first binutils resolution was reverted in
the 2.36 branch. The latest attempt is to use open(O_TRUNC)+write
instead of atomic rename
https://sourceware.org/pipermail/binutils/2021-February/115282.html
That preserves security context/xattr (not used by any distribution
package)/owner/group/mode and avoids fchmod/chown.
However, like other non-atomic operations, this approach has one
wasteful write (`strip a` writes two files) and can potentially
corrupt the output in the case of full disk situation and other
erroneous cases.
The root cause is that `sudo strip a` (or `strip a` under fakeroot)
restoring owner/group is a questionable interface and distributions
read too much from the behavior.
Personally I'd like llvm-objcopy to keep the behavior as is (no
chown/fchown). Neither https://reviews.llvm.org/D96308 nor
https://reviews.llvm.org/D93881 is appealing.
Doing this (get_owner_group; {strip,llvm-strip} file -o temp && chown
owner:group file && mv temp file) on Portage side is doing a favor to
LLVM binary utilities.
It benefits GNU binutils as well - with newer binutils, the current
`strip a` will have a wasteful write and 2x dirty pages (write a
temporary file and copy that content to the original file).
Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip
On Tue, Feb 9, 2021 at 8:44 PM Michael Orlitzky wrote: > On Tue, 2021-02-09 at 21:44 -0500, Michael Orlitzky wrote: > > > > ... games-arcade/xboing are also suspect. > > > > (This one's fine, that's the documented way to do things now. Although > I don't see why we couldn't use a separate group for each game's score > file.) > > This was not an exhaustive list, just the last 10 occurrences. Similar to fowners, I counted 161 usages of fperms though the grep below is not necessarily correct or exhaustive. $ grep -ri fperms .|grep bin|grep usr|wc -l 161 In Chrome OS, the switch to llvm-strip/objcopy broke some things like reboot/shutdown (and more) etc. as this functionality relied on group ownership for the power management tools. I could imagine that different tools similarly may need group ownership etc. for the tasks they need to perform. -Manoj
Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip
On Tue, 2021-02-09 at 21:44 -0500, Michael Orlitzky wrote: > > ... games-arcade/xboing are also suspect. > (This one's fine, that's the documented way to do things now. Although I don't see why we couldn't use a separate group for each game's score file.)
Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip
On Tue, 2021-02-09 at 18:25 -0800, Manoj Gupta wrote: > > > > Root is the owner but often there is also a group that has access to the > files. > After stripping with llvm-strip, new ownership is root:root instead of > root:. > Therefore, the members of the group lose access to the files post stripping. > > We found this issue in Chrome OS when we tried to switch the defaults to > llvm's objcopy/strip. Thanks, I still agree that some consistent behavior is needed. The only reason I asked is because the fact that you *noticed* the problem is a red flag to me. A suid group is a valid use case, but a few of these examples don't set any special group permissions on the executables whose group they change. For example... > ./net-analyzer/netselect/netselect-.ebuild: fowners root:wheel > /usr/bin/netselect This ebuild does, fowners root:wheel /usr/bin/netselect fperms 4711 /usr/bin/netselect which makes you wonder why it changed the group in the first place. The ebuilds for mail-filter/procmail and games-arcade/xboing are also suspect.
Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip
On 2021-02-09, Michael Orlitzky wrote: On Tue, 2021-02-09 at 17:53 -0800, Fāng-ruì Sòng wrote: (I replied via https://groups.google.com/g/linux.gentoo.dev/c/WG-OLQe3yng "Reply all" (which only replied to the list AFAICT) but I did not subscribe to gentoo-dev via the official https://www.gentoo.org/get-involved/mailing-lists/ so my reply is missing) Apologies for hijacking your post with a tangential question, but you reminded me to ask: how did you notice this problem? Ultimately all system executables (in $PATH) should be owned by (and writable only by) root anyway; otherwise you get silly security vulnerabilities like "cat ~/virus > /usr/bin/foo" as a regular user. Context: both `strip a` and `llvm-strip a` create a temporary file. `strip a` does additional chown(2) (instead of fchown!) with a long list of hardening-style checks. Due to how the code is organized, passing a file description around can be difficult for binutils. Jian Cai reported the problem that `sudo llvm-strip a` does not restore the original filename. I played with `strip a` and `strip a -o b` a bit and noticed that chown(2) is only called in these cases: * (under root) strip a * (under root) strip a -o a not in these cases: * strip a -o b * strip a -o ./a --- From my side, I want llvm-objcopy/llvm-strip to have simple and consistent rules, smaller platform differences. Why does strip need to behave differently with or without root permission, when the target file has one hard link or more, on Linux than on other OSes? The driven reason is that distributions require such `strip a` behavior. Arch Linux has moved away. If Gentoo Linux can move away, llvm-objcopy can keep its current simpler behavior. --- I think Arch Linux did this: ``` fakeroot # create an executable owned by bin strip exe# still owned by bin tar cf package.tar exe # record the owner exit tar xf package.tar -C somewhere ```
Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip
On Tue, Feb 9, 2021 at 6:02 PM Michael Orlitzky wrote: > On Tue, 2021-02-09 at 17:53 -0800, Fāng-ruì Sòng wrote: > > (I replied via > https://groups.google.com/g/linux.gentoo.dev/c/WG-OLQe3yng > > "Reply all" (which only replied to the list AFAICT) but I did not > > subscribe to gentoo-dev via the official > > https://www.gentoo.org/get-involved/mailing-lists/ so my reply is > > missing) > > > > Apologies for hijacking your post with a tangential question, but you > reminded me to ask: how did you notice this problem? Ultimately all > system executables (in $PATH) should be owned by (and writable only by) > root anyway; otherwise you get silly security vulnerabilities like "cat > ~/virus > /usr/bin/foo" as a regular user. > > > Root is the owner but often there is also a group that has access to the files. After stripping with llvm-strip, new ownership is root:root instead of root:. Therefore, the members of the group lose access to the files post stripping. We found this issue in Chrome OS when we tried to switch the defaults to llvm's objcopy/strip. Example of ebuilds: $ grep -ri fowners .|grep bin|grep usr|tail -10 ./net-analyzer/tcpdump/tcpdump-4.9.3-r4.ebuild: fowners root:pcap /usr/sbin/tcpdump ./net-analyzer/tcpdump/tcpdump-4.99.0.ebuild: fowners root:pcap /usr/sbin/tcpdump ./net-analyzer/netselect/netselect-.ebuild: fowners root:wheel /usr/bin/netselect ./net-analyzer/netselect/netselect-0.4-r1.ebuild: fowners root:wheel /usr/bin/netselect ./net-analyzer/driftnet/driftnet-1.3.0.ebuild: fowners root:wheel "/usr/bin/driftnet" ./mail-filter/procmail/procmail-3.22-r14.ebuild: fowners root:mail /usr/bin/lockfile ./sys-block/scsiadd/scsiadd-1.97-r1.ebuild: fowners root:scsi /usr/sbin/scsiadd ./x11-terms/aterm/aterm-1.0.1-r4.ebuild: fowners root:utmp /usr/bin/aterm ./x11-terms/mrxvt/mrxvt-0.5.4.ebuild: fowners root:utmp /usr/bin/mrxvt ./games-arcade/xboing/xboing-2.4-r3.ebuild: fowners root:gamestat /var/games/xboing.score /usr/bin/xboing Thanks, Manoj
Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip
On Tue, 2021-02-09 at 17:53 -0800, Fāng-ruì Sòng wrote: > (I replied via https://groups.google.com/g/linux.gentoo.dev/c/WG-OLQe3yng > "Reply all" (which only replied to the list AFAICT) but I did not > subscribe to gentoo-dev via the official > https://www.gentoo.org/get-involved/mailing-lists/ so my reply is > missing) > Apologies for hijacking your post with a tangential question, but you reminded me to ask: how did you notice this problem? Ultimately all system executables (in $PATH) should be owned by (and writable only by) root anyway; otherwise you get silly security vulnerabilities like "cat ~/virus > /usr/bin/foo" as a regular user.
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Wed, 2021-02-10 at 08:51 +0800, Benda Xu wrote: > > > > The first big blocker we're going to hit is trustme [3] package that > > relies on cryptography API pretty heavily to generate TLS certs for > > testing. If we managed to convince upstream to support an alternate > > crypto backend, we'd be able to retain minor keywords a lot of packages > > without too much pain. > > I could feel the pain. > > Bootstraping Rust on Prefix is somewhere between alpha, hppa, ia64, > m68k, s390 and amd64[1]. The problem was exposed by > gnome-base/librsvg[2]. > > I am wondering how useable pkgcore is on alpha, hppa, etc. Maybe it's > time for us to plan for a Gentoo without essential Python dependency. It's not usable anywhere. We keep updating the PMS, and the council keeps voting to approve the new versions, and we teach all new developers that they need to respect both the PMS and council decisions... and then from that day on, everyone completely, publicly, ignores it, adding thousands of packages across entire ecosystems that don't work properly without portage. I'd like to say it's one of the craziest things I've ever seen, but, there was 2020. We "started" with three package managers, and now we're down to one. The council needs to grow some balls and enforce the PMS before that can change. Pkgcore could be salvaged if you could actually update your system with it. For my "me too," I've been told by upstream that the next major version of clamav will require rust. There are a lot of "real" UNIX machines relying on clamav for e.g. PCI compliance that will be screwed by that, not to mention all of the small business routers and mail gateways on obscure or limited hardware. Personally, I just haven't spent the last 20 years contributing to free software to be casually migrated to a system of bundled binary blobs; nor am I able to set aside 8GB of RAM for hours to rebuild the latest version of rust and its myriad unofficial dependencies every day on a production mail server. Eventually clamav will disappear, and we'll likely move a few big customers to Microsoft O365 as a result.
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On 2021-02-09 Tue 17:51, Benda Xu wrote: > I am wondering how useable pkgcore is on alpha, hppa, etc. Maybe it's > time for us to plan for a Gentoo without essential Python dependency. Just to keep misinformation down, pkgcore currently has nothing to do with rust as it's implemented in python due to basically being deemed portage-ng when it forked ~15 years ago. It previously did have some extensions written in C which have mostly been removed in the current day from CPython catching up in a number of areas. That being said, alternative languages and related support has been looked at for a number of reasons/features and development could move in that direction, but hasn't yet in a public fashion. Tim
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
Hi Michał, Michał Górny writes: > So it seems that upstream has practically closed the discussion, > and the short summary is that they only care for the 'majority' of > users, they don't care for minor platforms (but we're free to port > LLVM/Rust to them) and -- unsurprisingly -- this is a part of crusade > towards promoting Rust. > > Given the aggressive opinions of a number of Python core devs > participating in the discussion, I'm afraid that it is quite probable > that a future version of CPython may require Rust. In fact, they've > already started having knee-jerk reactions to the problem at hand [1]. > To be honest, I've never thought I'd be this disappointed in Python > upstream. > > Good news is that they've promised to keep a LTS branch with security > fixes to the non-Rust version. Until end-of-year. And they've pretty > aggressively stated that they won't fix anything except security bugs > with a CVE assigned. So if it stops building for whatever reason, we're > on our own. > > I've reached out to Debian and they're planning to remove support for > minor architectures for this package in the next release. However, > Python is not as central to them as it is to us. Alpine is also > affected but seems intent on pushing Rust forward, so they'll probably > drop these architectures as well. > > Mike's submitted a PR to remove (unnecessary) cryptography dep from our > urllib3/requests packages [2]. This should make it possible to avoid > cryptography at least on some systems. However, it is still an indirect > test dependency of these packages, so we're going to have a hard time > keeping them properly tested. > > At this point, I'm really depressed about this and I'm seriously > wondering why I'm wasting so much effort on open source. I don't see > a good way out of it. Rust could be a nice language -- but it won't if > it continues to be surround by arrogant zealots who want to destroy > everything in their path towards promoting it. > > The first big blocker we're going to hit is trustme [3] package that > relies on cryptography API pretty heavily to generate TLS certs for > testing. If we managed to convince upstream to support an alternate > crypto backend, we'd be able to retain minor keywords a lot of packages > without too much pain. I could feel the pain. Bootstraping Rust on Prefix is somewhere between alpha, hppa, ia64, m68k, s390 and amd64[1]. The problem was exposed by gnome-base/librsvg[2]. I am wondering how useable pkgcore is on alpha, hppa, etc. Maybe it's time for us to plan for a Gentoo without essential Python dependency. Looking forward to gcc-rust for saving the world in the end. Benda 1. https://bugs.gentoo.org/689160 2. https://bugs.gentoo.org/739574
Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages
On Tue, Feb 9, 2021 at 2:23 PM Ulrich Mueller wrote: > > > On Tue, 09 Feb 2021, Mike Gilbert wrote: > > >> Mh - so the obvious first feature request for the script is to also > >> output Free UID+GID pairs. Counting them manually in your screenshot > >> I get 36. > >> > >> That's not a whole lot; just 7% of 500. > > > The output was abbreviated. Here is the full output for entries where > > both ids are FREE. > > Still, it's not an infinite resource, and maybe we shouldn't waste a > pair if only one of UID or GID is needed? It's possible that a package might require both a UID and a GID at some point in the future. If we actually start running out of low-numbered ids, we could start mixing them at that point; having them match is really just a cosmetic thing. Or we could always just expand the permissible range.
Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages
> On Tue, 09 Feb 2021, Mike Gilbert wrote: >> Mh - so the obvious first feature request for the script is to also >> output Free UID+GID pairs. Counting them manually in your screenshot >> I get 36. >> >> That's not a whole lot; just 7% of 500. > The output was abbreviated. Here is the full output for entries where > both ids are FREE. Still, it's not an infinite resource, and maybe we shouldn't waste a pair if only one of UID or GID is needed? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages
On Tue, Feb 9, 2021 at 12:51 PM Peter Stuge wrote: > > Joonas Niilola wrote: > > There's a script by jkroon in data/api.git > > (https://gitweb.gentoo.org/data/api.git/) that prints the next available > > UID/GID pair for new acct-* packages. > > This is super nice! Thanks a lot jkroon! > > > > It is not forbidden to mix and mash UID/GID between different packages, > > but I'd still suggest to find a new "pair" even if you push just an UID > > or GID. Since we don't seem to be in danger of running out any time soon. > > Mh - so the obvious first feature request for the script is to also output > Free UID+GID pairs. Counting them manually in your screenshot I get 36. > > That's not a whole lot; just 7% of 500. The output was abbreviated. Here is the full output for entries where both ids are FREE. % bin/used_free_uidgids.sh | grep "FREE FREE" 23..24 FREE FREE 29..30 FREE FREE 34 FREE FREE 37..39 FREE FREE 41..42 FREE FREE 44 FREE FREE 49..52 FREE FREE 54..58 FREE FREE 67 FREE FREE 71..73 FREE FREE 83 FREE FREE 86..87 FREE FREE 90 FREE FREE 92..94 FREE FREE 96 FREE FREE 98 FREE FREE 104..105 FREE FREE 107..110 FREE FREE 112 FREE FREE 116 FREE FREE 118..121 FREE FREE 125..132 FREE FREE 134..138 FREE FREE 140..149 FREE FREE 151..152 FREE FREE 154..155 FREE FREE 159..166 FREE FREE 168 FREE FREE 170 FREE FREE 173..176 FREE FREE 179..182 FREE FREE 185 FREE FREE 187 FREE FREE 189 FREE FREE 210..211 FREE FREE 213..218 FREE FREE 224..229 FREE FREE 231 FREE FREE 233..234 FREE FREE 238 FREE FREE 244 FREE FREE 246..249 FREE FREE 251 FREE FREE 253..264 FREE FREE 266 FREE FREE 279..289 FREE FREE 293..298 FREE FREE 311..314 FREE FREE 317..320 FREE FREE 322..326 FREE FREE
Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages
Joonas Niilola wrote: > There's a script by jkroon in data/api.git > (https://gitweb.gentoo.org/data/api.git/) that prints the next available > UID/GID pair for new acct-* packages. This is super nice! Thanks a lot jkroon! > It is not forbidden to mix and mash UID/GID between different packages, > but I'd still suggest to find a new "pair" even if you push just an UID > or GID. Since we don't seem to be in danger of running out any time soon. Mh - so the obvious first feature request for the script is to also output Free UID+GID pairs. Counting them manually in your screenshot I get 36. That's not a whole lot; just 7% of 500. //Peter
[gentoo-dev] A script to pick next free UID/GID for your acct-* packages
Hey all, Summary: There's a script by jkroon in data/api.git (https://gitweb.gentoo.org/data/api.git/) that prints the next available UID/GID pair for new acct-* packages. You can use it by: cd ~/git/gentoo/data/api git pull sh bin/used_free_uidgids.sh The outcome looks like this for those curious: https://dev.gentoo.org/~juippis/pics/free_uid_gid_by_jkroon.png Check the Author e-mail from the script to report bugs, and please open pull requests here: https://github.com/gentoo/api-gentoo-org Story: As someone who's pushed a few new UID/GID packages lately it was becoming more and more tedious trying to find the next free number. And I was personally becoming worried when we're going to run out of available IDs. Now a while back I asked half-jokingly someone to write a script that finds the next free UID, GID and UID/GID, and also prints the current number of free IDs <500 in #gentoo-dev IRC channel. Lucky for us all, jkroon was up to the task. I wanted the implementation to be "open for inspection" and available in every system syncing data/api.git. So in my eyes the viable options were using bash or python, and the current script is written in bash. We've heard enough about using bash for this so please leave such comments out from this thread. It is well documented and should be maintainable for the time being, but if someone is up to re-writing it using some other viable language (python), please go ahead! In its current state the script works and is very useful! Script's output looks like this: #ID UID GID ... 317..320 FREE FREE 321 USED USED 322..326 FREE FREE 327..330 USED USED 331..332 USED FREE 333..372 USED USED 373 USED FREE ... Recommended GID only: 460 Recommended UID only: 458 Recommended UID+GID both: 326 Free UIDs: 200 Free GIDs: 177 (note that FREE/USED are colourcoded for your convenience, check the screenshot above!) It is not forbidden to mix and mash UID/GID between different packages, but I'd still suggest to find a new "pair" even if you push just an UID or GID. Since we don't seem to be in danger of running out any time soon. Please report bugs to Author (e-mail in the script), and for any fixes open pull requests at https://github.com/gentoo/api-gentoo-org/ Not to any proxied maintainers (reading this far), a free UID/GID pair will be given to you when your acct-* packages are merged, so you don't have to reserve an ID beforehand. But it'd be great if you picked one that is free when making your new acct-* packages so at least during merge the next free one will be close to your chosen one. Enjoy everyone, and huge thanks to jkroon! -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs: app-cdr/iat, dev-util/flawfinder
On Mon, 8 Feb 2021 08:25:28 +0200 Joonas Niilola wrote: > Packages up for grabs due to retirement of a proxied maintainer: > dev-util/flawfinder (outdated) I take this Alfredo
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Mon, 2021-02-08 at 12:19 +0100, Michał Górny wrote: > FYI the developers of dev-python/cryptography decided that Rust is going > to be mandatory for 1.5+ versions. It's unlikely that they're going to > provide LTS support or security fixes for the old versions. > > Since cryptography is a very important package in the Python ecosystem, > and it is an indirect dependency of Portage, this means that we will > probably have to entirely drop support for architectures that are not > supported by Rust. > > I...] > > I've raised a protest on the cryptography bug tracker [2] but apparently > upstream considers Rust's 'memory safety' more important than ability to > actually use the package. > > Honestly, I don't think it likely that Rust will gain support for these > platforms. This involves a lot of work, starting with writing a new > LLVM backend and getting it accepted (getting new code into LLVM is very > hard unless you're doing that on behalf one of the big companies). You > can imagine how much effort that involves compared to rewriting the new > code from Cryptography into C. > > If we can't convince upstream, I'm afraid we'll either have to drop > these architectures entirely or fork Cryptography. > > > [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html > [2] https://github.com/pyca/cryptography/issues/5771 So it seems that upstream has practically closed the discussion, and the short summary is that they only care for the 'majority' of users, they don't care for minor platforms (but we're free to port LLVM/Rust to them) and -- unsurprisingly -- this is a part of crusade towards promoting Rust. Given the aggressive opinions of a number of Python core devs participating in the discussion, I'm afraid that it is quite probable that a future version of CPython may require Rust. In fact, they've already started having knee-jerk reactions to the problem at hand [1]. To be honest, I've never thought I'd be this disappointed in Python upstream. Good news is that they've promised to keep a LTS branch with security fixes to the non-Rust version. Until end-of-year. And they've pretty aggressively stated that they won't fix anything except security bugs with a CVE assigned. So if it stops building for whatever reason, we're on our own. I've reached out to Debian and they're planning to remove support for minor architectures for this package in the next release. However, Python is not as central to them as it is to us. Alpine is also affected but seems intent on pushing Rust forward, so they'll probably drop these architectures as well. Mike's submitted a PR to remove (unnecessary) cryptography dep from our urllib3/requests packages [2]. This should make it possible to avoid cryptography at least on some systems. However, it is still an indirect test dependency of these packages, so we're going to have a hard time keeping them properly tested. At this point, I'm really depressed about this and I'm seriously wondering why I'm wasting so much effort on open source. I don't see a good way out of it. Rust could be a nice language -- but it won't if it continues to be surround by arrogant zealots who want to destroy everything in their path towards promoting it. The first big blocker we're going to hit is trustme [3] package that relies on cryptography API pretty heavily to generate TLS certs for testing. If we managed to convince upstream to support an alternate crypto backend, we'd be able to retain minor keywords a lot of packages without too much pain. [1] https://bugs.python.org/issue43179 [2] https://github.com/gentoo/gentoo/pull/19383 [3] https://github.com/python-trio/trustme -- Best regards, Michał Górny
