constant_time.py:26: CryptographyDeprecationWarning: Support for your Python version is deprecated. The next version of cryptography will remove support. Please upgrade to a 2.7.x release that supports hmac.compare_digest

[jsoref]

This was mentioned in #6824 (comment) but that issue was closed as being related to debian wheezy

My operating system is (include version):

CentOS release 6.10 (Final)

rpm -qi python27-1.1-15.el6.x86_64
Name        : python27                     Relocations: (not relocatable)
Version     : 1.1                               Vendor: Red Hat, Inc.
Release     : 15.el6                        Build Date: Mon 17 Feb 2014 03:51:13 AM EST
Install Date: Wed 08 Feb 2017 12:27:34 PM EST      Build Host: x86-021.build.eng.bos.redhat.com
Group       : Unspecified                   Source RPM: python27-1.1-15.el6.src.rpm
Size        : 0                                License: GPLv2+
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary     : Package that installs python27
Description :
This is the main package for python27 Software Collection.

I installed Certbot with (certbot-auto, OS package manager, pip, etc):

certbot-auto using scl enable python27 ...

I ran this command and it produced this output:

scl enable python27 /root/bin/scl-certbot-renew

/root/bin/scl-certbot-renew:

/root/bin/certbot-auto -q renew --post-hook /root/bin/certbot-renew-hook

/opt/eff.org/certbot/venv/lib/python2.7/site-packages/cryptography/hazmat/primitives/constant_time.py:26: CryptographyDeprecationWarning: Support for your Python version is deprecated. The next version of cryptography will remove support. Please upgrade to a 2.7.x release that supports hmac.compare_digest as soon as possible.
  utils.DeprecatedIn23,

Certbot's behavior differed from what I expected because:

This package is part of the certbot venv and I shouldn't be getting scary warnings.

#3726 (comment) suggests filing a new issue.

Here is a Certbot log showing the issue (if available):

Logs are stored in /var/log/letsencrypt by default. Feel free to redact domains, e-mail and IP addresses as you see fit.

Here is the relevant nginx server block or Apache virtualhost for the domain I am configuring:

[bmw]

This Python 2.7 package you're using looks quite old. You need Python 2.7.7 or higher.

The two options for you are:

1. Install a more recent version of Python 2.7 from SCL. It looks like the latest version there is Python 2.7.13.
2. Stop using SCL and let certbot-auto walk you through installing Python 3.4 from EPEL. For it to do this, you should run certbot-auto where the only Python in your PATH is the Python 2.6 version that is the default on CentOS 6.

[BenjamenMeyer]

@bmw can you please update the message to say 2.7.7+ instead of simply 2.7.x? That would make this so much more clear.

[jsoref]

Turns out this isn't coming from certbot.

https://stackoverflow.com/questions/51778764/obnoxious-cryptographydeprecationwarning-because-of-missing-hmac-compare-time-fu

It's from pyca/cryptography -- I'll send a PR to them...

[BenjamenMeyer]

@jsoref thanks!

[jsoref]

So, I think given that certbot really wants to manage its own python34 instead of using someone's scl python2.7.old, it should probably recognize that case and suggest people not use py27 on rhel6/centos.

Based on my experience, one of two things will happen if a user tries to use certbot w/o scl-py27:

• certbot will magically get py34 working
• certbot will give a stupid error because py34 may have been present in part and has been removed

It seems reasonable for certbot to issue a warning pointing to a page that explains:

You should try running certbot w/o wrapping it in scl-py27 -- things might just work. If they don't, try yum install python34-devel python34-tools and then running it -- it might just work.

[bmw]

Thanks for submitting that PR @jsoref.

So, I think given that certbot really wants to manage its own python34 instead of using someone's scl python2.7.old, it should probably recognize that case and suggest people not use py27 on rhel6/centos.

I'm not sure we really care what you use. People are should be able to use an up-to-date version of the Python 2.7 SCL packages without issues.

If you are using older/other packages, you may get deprecation warnings like you saw here and perhaps eventually errors if we drop support for that version of Python, but I personally think this is the correct behavior rather than trying to special case this setup. If Certbot works with the version of Python you want to use, great, we should use it. If we don't or we are trying to move away from it, tell the user. We are not planning on deprecating Python 2.7 support at this time.

certbot will give a stupid error because py34 may have been present in part and has been removed

This seems like a separate issue. If you're able to provide instructions on how to reproduce it, we'd like to know so we can try and see that the problem is fixed.

[stale]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

[skyflyer]

I know this is an old issue... but this issue is still present. Certbot will create virtual environment with a system version of python 2.7.6 (Ubuntu 14.04). Even if put python 2.7.17 in the path before it or if I create the /opt/eff.org/certbot/venv manually with python 2.7.17. The system also has a python3.x installed.

I was running this with sudo certbot-auto: this requests root permissions, which then ignore the locally configure path to python.

This is how I was able to "fix" the issue:

sudo su -
export PATH=/usr/local/lib/python2.7.17/bin:$PATH
certbot-auto

[github-actions]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

[github-actions]

This issue has been closed due to lack of activity, but if you think it should be reopened, please open a new issue with a link to this one and we'll take a look.