Develop Reference

Obnoxious CryptographyDeprecationWarning because of missing hmac.compare_time function everywhere

Things were running along fine until one of my projects started printing this everywhere, at the top of every execution, at least once:
local/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.
I have no idea why it started and it's disrupting the applications'/tools' output, especially when it's being captured and consumed by other tools. Like many difficulties throughout time, I'm fairly certain it is related to urllib and, by association, requests. Worse, I have so many projects and cross-dependencies that I can't possibly update all of the imports and branches with the call to warnings.filterwarnings() to suppress the warning.
I have Python 2.7.6 . Apparently this goes away in 2.7.7 . Only, I have some systems that have 2.7.6 where I do not see the warnings. So, something may or may not be disabling them in one version and I might've inadvertently replaced it with another version.
My Ubuntu, Python, urllib, requests (with the security option), cryptography, and hmac are all identical versions/builds on systems that do print the warning and systems that do not.
There appears to be no relevant warnings or announcements online and it seems like any related project is static/stable by this point (even though 'hmac' can be installed via PIP, it hasn't changed in eight years).

I hit this error for quite sometime. For my environment, it was a pain to upgrade Python to a higher version than 2.7.6. The easier solution was to downgrade cryptography module using pip:
pip2.7 install cryptography==2.2.2
I think the best solution is to upgrade your python version though

This answer is for Python3
I got here by looking for an answer while using Paramiko. For those still looking for a simple answer. I got these CryptographyDeprecationWarning suppresed with the these lines of code before importing Paramiko:
import warnings
warnings.filterwarnings(action='ignore',module='.*paramiko.*')
I hope this helps

If you want to be more selective about suppressing JUST that particular deprecation warning:
import warnings
from cryptography.utils import CryptographyDeprecationWarning
warnings.filterwarnings("ignore", category=CryptographyDeprecationWarning)

I started getting this warning for a straightforward requests.get call. This warning is printed when the module cryptography.hazmat.primitives.constant_time is loaded, and so this should typically only come once per Python program. If you are seeing it many times, it must be because a Python program (like a utility) is getting executed multiple times. You just have to identify that program and add the below code to the main entry point:
import cryptography
from cryptography import utils
with warnings.catch_warnings():
warnings.simplefilter('ignore', cryptography.utils.DeprecatedIn23)
import cryptography.hazmat.primitives.constant_time

I fixed this for all my local projects and tools using Python 2 by removing the warning from the python source code [your_installation_path]\Python\Lib\site-packages\cryptography\__init__.py
Just remove this snipped at the end of the file and delete the __init__.pyc file so its recompiled with the changes:
if sys.version_info[0] == 2:
warnings.warn(
"Python 2 is no longer supported by the Python core team. Support for "
"it is now deprecated in cryptography, and will be removed in the "
"next release.",
CryptographyDeprecationWarning,
stacklevel=2,
)

For Python3 only:
Per an apparent Paramiko update this worked for me and solve the similar problem/symptoms I was experiencing:
pip3 install --upgrade paramiko
This installed paramiko 2.6.0 on my system, replacing 2.4.2:
$ pip3 install --upgrade paramiko
[...]
Installing collected packages: paramiko
Found existing installation: paramiko 2.4.2
Uninstalling paramiko-2.4.2:
Successfully uninstalled paramiko-2.4.2
Successfully installed paramiko-2.6.0
$
My Python2 environment appears to be messed up, so I'm not able to test this on Python2.

When you do pip2.7 install cryptography==2.2.2, it appears the error might still occur.
I believe you need also sudo pip2.7 install --upgrade pip
Aso, as of 5/5/19 the newest appears to be cryptography=2.6.1

Python Requests: Where is Crypto.dll?

I am trying to use the Python requests module on Windows with Anaconda. After installing it with pip, attempting to import it fails because asn1crypto is required in the cryptography 2.2.2 module. After installing that with pip, it fails because the crypto library (that'd be crypto.dll on Windows) does not exist. Where the heck does this come from? The way asn1crypto uses it makes it seem like this is libcryptoXXX.dll, but I do not see any circumstance that it would be called crypto.dll. It looks like very old versions of pyOpenSSL (back when it was python-OpenSSL) came with crypto.so for Unix distributions, but I don't know where that came from and don't see any mention of a crypto.dll (and crypto.so was no longer distributed by the version of pyOpenSSL that requests says it requires). So what is this crypto.dll and where can I get it?

Setting expectations up front - all I've got to offer is a workaround and notes on my own experience.
I was faced with the same issue with Anaconda on Windows, and after going on a small adventure I simply removed asn1crypto from Anaconda. This raised an issue with a dependent package, so I removed that. 5 or 6 packages later I had a subset of Anaconda where Python code seems to successfully build and run.
My assessment is that this is an issue with Anaconda on Windows, specifically with asn1crypto (why do you expect and need "crypto.dll" on machines that don't have it, and offer no alternative?). I'd love to be wrong and for someone to tell me why.
My small adventure had me fruitlessly looking for the mysterious crypto library. I describe this below.
Looking for the "crypto.dll", I came across some questionable leads before landing here, which suggested I could pick up "libcrypto.dll" as part of an older version of OpenSSH for Windows. Not quite what I was looking for, but worth a try. Didn't work. Tried the 32 bit version (in path via system32) and the 64 bit version (in path via SysWOW64) with no luck. Tried the new and renamed to "libeay32.dll" version from a later release of OpenSSH on Windows. Didn't work. Tried the versions from OpenSSL on Windows (inexplicably renamed in the other direction). Tried masquerading these dlls as "crypto.dll", which just caused other errors.
Once again, I'd love for a more satisfying answer to exist (hint hint, future readers).

Using Pexpect with Python 3

After hours of research I have broken down to posting. I am trying to use the Pexpect module with python 3, which I am led to believe is possible from the document page which does say it will run with python 3.2.
Things I have tried: I have tried many different ways of installing including downloading the source and running the command sudo python3 setup.py install. I have also tried installing it with pip and *easy_install* which is what the documentation suggest. It seems that everything goes off with out a hitch until I attempt to import the module in the pyshell. When I type import pexpect I get the error:
class spawn(object):
File "/usr/local/lib/python3.2/dist-packages/pexpect/init.py", line 286, in spawn
write_to_stdout = sys.stdout.buffer.write
AttributeError: 'PseudoFile' object has no attribute 'buffer'
I have also tried googleing the error with no luck. And I have tried using python 2.7 and it works fine. I have tried on multiple debian based operating systems: Ubuntu 12.04 and Kali with the same results.
I feel like there is something obvious I am missing, but I just don't see it. Any points in the right direction Or helping me understand the error message would be much appreciated!

There was a bug in Pexpect 3.0 which stopped it working if sys.stdout was replaced before it was imported. It looks like IDLE replaces stdout, so as you've found, it doesn't work in IDLE & Python 3.
The bug has now been fixed. I'll try to get a new version of Pexpect out in the next few days, and then you'll be able to use it from IDLE.

httplib2 API is different when installed from source or as RPM?

Boy, is this frustrating...
I installed the httplib2 by downloading the .tar.gz package from the site on my CentOS development VM. After spending 1/2 day to get it do two-way ssl authentication, I install the python26-httplib2.noarch on the target RHEL 5.7 machine. Suddenly the code does not run as the class constructor is different!
The official documentation defines the Http class as follows:
class httplib2.Http([cache=None][, timeout=None][, proxy_info=None][,
ca_certs=None][, disable_ssl_certificate_validation=False])
My code that uses the tar installation indeed does this, and it works:
client = httplib2.Http(ca_certs='/path-to/ca.cert')
However, the ca_cert parameter is not recognized in the RPM installation. Looking in the lib, I indeed see the following:
class Http(object):
def __init__(self, cache=None, timeout=None, proxy_info=None):
i.e. totally different parameter list.
Is there any explanation for this?
PS. Sorry if I sound furious - I am. It's 8pm and I hoped to check in the code today...
PPS. Python 2.6

I would guess: different httplib2 versions. As far as I understand from a quick glance at the change log and code, ca_certs supports SSL server certificate validation, which has been added in httplib2 0.7.0. Is it possible that the httplib2 version coming from RPM is older than that? What does print httplib2.__version__ show?
As a workaround, I would suggest not to install Python libraries from tar.gz files or from Red Hat packages; use pip instead, possibly with a requirement file where you can specify the exact version number (or even a lower-bound one) of each external library you need for your program to run.

Python 2 and IPv6

I'm trying to enable IPv6 in a Python 2 application and am running into trouble. Whenever I try to bind to an IPv6 socket, a socket.error: getsockaddrarg: bad family exception is thrown. I can reproduce the error simply by doing:
import socket
s = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
s.bind(('', 12345))
This code works fine if I run in Python 3. Unfortunately the script would need a significant porting effort to work in Python 3 and I'd rather not have to do that yet.
Is there something I need to do to get IPv6 working in Python 2 or am I S-O-L?
Details:
Python 2.6.2 (r262:71600, Oct 24 2009, 03:16:31)
[GCC 4.4.1 [gcc-4_4-branch revision 150839]] on linux2
(it's the Python that's part of the standard openSUSE 11.2 install).
Update
After AndiDog helped me figure out that socket.AF_INET6 is defined even when IPv6 is not configured, I discovered socket.has_ipv6. This is defined as a boolean and indicates whether Python was build with IPv6.

Okay here's the answer from the comments:
Seems like Python wasn't configured with --enable-ipv6.
It shouldn't be a OS problem because Python 3 works. Even if the OS doesn't have IPv6 support, it seems that socket.AF_INET6 is always available (if it is defined in the OS header files). Cf. socketmodule.c, line 4433 (in current Python 2.6.4 source code).

Sounds like that particular Python was not compiled with IPv6 support.
In which case, you can download the source for that version and build yourself a compatible Python that will work. You may even be able to do some editing in the Debian package and upgrade the system python.

Works fine with 2.6.4 on my Mac (Mac OS X 10.5.8) -- and unfortunately I can't downgrade to 2.6.2 nor do I have any openSUSE around to check where the bug specifically comes from you. Could you try getting 2.6.4 and building from sources to see if the bug goes away, or check some openSUSE-specific bug tracker...? At least we do know it's not a generic Python 2.6 bug (with the latest, bug-fixed version of 2.6, at least)...