Cryptography 35.0.0 breaks certbot

Client dev
1

This morning I got informed about a MacPorts ticket for an issue loading certbot #63567 (certbot execution failed) – MacPorts. The error is

An unexpected error occurred:
pkg_resources.ContextualVersionConflict: (cryptography 35.0.0 (/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages), Requirement.parse('cryptography<4,>=2'), {'dns-lexicon'})

I can reproduce it on my machine, even after rebuilding py-acme and certbot.

On Github I see py-cryptography was updated from 3.4.8 to 35.0.0 two days ago py-cryptography: update to 35.0.0 · macports/macports-ports@c7bb4cf · GitHub

and broke the Requirement.parse.

2

Well, it seems the dependency requirements are from dns-lexicon. While dns-lexicon is indeed a dependency of certain certbot DNS, it's not certbot itself with the incorrect cryptography dependency.

See the certbot cryptography dependency here:

Should work fine with 35.0.0.

Same goes for the acme library:

It's probably better to directly open an issue at Issues · AnalogJ/lexicon · GitHub

1 Like
3

By the way, doesn't MacPorts have a system in place which prevents breaking commits such as py-cryptography: update to 35.0.0 · macports/macports-ports@c7bb4cf · GitHub ?

It's obvious that commit broke dns-lexicon, but I don't see any checks next to that commit in the commit history. Some commits do have successful checks, some commits have broken checks, but are still committed.. Doesn't really look like a fool-proof system if you'd ask me.

1 Like
4

Thanks for the quick response!

Indeed, after deactivating dns-lexicon and dns-namecheap, certbot loads. I'll open an issue with dns-lexicon.

MacPorts only checks if library links are broken. However, this rarely catches python issues. I usually find python dependency errors when attempting to execute a package.

1 Like
5

In the mean time, I've already opened a PR to remove the <4 constraint: Remove cryptography<4 constraint by osirisinferi · Pull Request #968 · AnalogJ/lexicon · GitHub

Indeed, I don't think checking library links suffices for Python packages.

2 Likes
6

I am seeing this error on archlinux-arm too.

@Schamschula how do you deactivate dns-lexicon and dns-namecheap?

7

Under MacPorts you deactivate a package (e.g. the Python 3.9 version) by running

sudo port deactivate py39-dns-lexicon

archlinux uses a different package manager, so you'll need to check the documentation.

8

oh, that's what you meant by deactivate; I thought it was a plugin to deactivate in certbot

Thanks

1 Like
9

Usually the DNS plugins are provided separately from the main certbot program and acme library. So if you don't use those DNS plugins, you should be able to uninstall them.

1 Like
10

Well, I am using certbot-dns-ovh, that depends on dns-lexicon; so I can't do that?

11

True, if you use that plugin you can't indeed. But in that case I don't really understand why you asked on how to disable dns-lexicon in the first place.

Anyway, in any case it seems Arch bumped the version for cryptography, but didn't bump the version of dns-lexicon to 3.7.1. (Which is the version where this issue was fixed.)

So your best move would be to a
point out this matter to the Arch maintainer for dns-lexicon, so he/she can bump the version to 3.7.1.

1 Like
12

FWIW, I just want to warn people this will likely continue to break and this install method (macports) is not officially supported - so you should keep an eye out with tests on your system to catch future breakage.

TLDR: The distro/macport ports are all ports/patches of the official certbot (and other package) source and are often designed to pick up other ports from the system first. the breaking packages could be installed from the distro package manager, or from the pypi/pip package manager (or even vendored); and could be installed into a user space, shared system space, or even vendored into the package. The Certbot devs have been pushing towards the snap installation method, in part, because that creates a nice and easily maintained sandboxed environment where the requirements can all be nicely managed. Currently Certbot supports Homebrew over Macports - at least for directions - but I don't know how long that will be for. Their team does not seem to want to support anything other than snapd, ASAP.

I often use a pip installed Certbot for local use of DNS-01 challenges. For my local usage pattern, and Python skill level, I'm not worried about potential breaks. If my usage pattern involved anything automated, I would absolutely have CI tests covering a build and a dry-run against staging of certbot and the necessary plugins.

1 Like
13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.