pynacl: import nacl.bindings hangs

I ran into an issue with another library hanging on import that appears be caused by PyNaCl. I can reproduce the issue with

$ python -c 'import nacl.bindings'

Expected Behavior: command should complete in, at most, a few seconds. Actual Behavior: commands takes roughly 90 seconds to complete

Running strace on the command shows that the import is hanging here

open("/dev/random", O_RDONLY)           = 4
poll([{fd=4, events=POLLIN}], 1, 4294967295

I found this closed issue and tried following the recommendation of running pip install pynacl -I --no-binary pynacl but the issue still occurs. https://github.com/paramiko/paramiko/issues/1023

OS: Ubuntu 14.04.5 Python Version: 2.7.6

About this issue

Original URL
State: open
Created 7 years ago
Reactions: 2
Comments: 23 (10 by maintainers)

Commits related to this issue

Fix Entropy Performance issue with libsodium, etc. There seems to be a bug with entropy pool gathering with libsodium in which calls to /dev/random fail. This manifests itself in QEMU because it has... — committed to redhat-performance/quads by sadsfae 5 years ago

Most upvoted comments

If it’s inherently insecure to not read /dev/random at startup, does that mean that OpenSSH is insecure? I can spawn dozens of ssh processes and none of them will hang, which implies that they’re not reading /dev/random.

If I try to spawn two Python processes that both import nacl.bindings, at least one of them will hang, since both will try to read /dev/random, and the first one to succeed will drain off all the entropy for the next 10 minutes or so on a Google Cloud VM instance. Starting dozens of Python processes that all import nacl.bindings is impossible.

j3pic on Oct 10, 2019

By default libsodium only uses the /dev/random path to determine if the CSPRNG is initialized before it starts using /dev/urandom. It also prefers to use getrandom, which gives the same behavior for free (blocking only until the CSPRNG is ready). On normal systems this happens extremely rapidly, but there exists a weird long tail of systems that can have bad entropy for long periods of time (especially small things like raspberry pi devices). We do not want to supply bad randomness as that is a major security problem, so blocking is the right decision.

This obviously results in a bad user experience, but the underlying problem is not one pynacl/libsodium can fix, we can only wait.

reaperhulk on Jan 18, 2019

We are facing this issue on a Linux VPS used for test, the app is restarted after each code modification, which triggers a new init call to pynacl/libsodium. Sometimes (~30% of the time) it takes 40-90 seconds to start, because this “pause” in libsodium start.

Here’s the point when we CTRL+C when this hangs. Note that the prompt shell is given back only after the hang ending, so this is a real blocking thing.

  File "/root/guardata/guardata/crypto/__init__.py", line 8, in <module>
    from nacl.public import SealedBox, PrivateKey as _PrivateKey, PublicKey as _PublicKey
  File "/usr/local/lib/python3.7/dist-packages/nacl/public.py", line 17, in <module>
    import nacl.bindings
  File "/usr/local/lib/python3.7/dist-packages/nacl/bindings/__init__.py", line 423, in <module>
    sodium_init()
  File "/usr/local/lib/python3.7/dist-packages/nacl/bindings/sodium_core.py", line 32, in sodium_init
    ffi.init_once(_sodium_init, "libsodium")
  File "/usr/local/lib/python3.7/dist-packages/nacl/bindings/sodium_core.py", line 22, in _sodium_init
    ensure(lib.sodium_init() != -1,

This is not happenning with “no-binary” and compiling from source with wheel. Why this hang doesn’t happen with the program from source? what is the difference between source and precompiled whl? Precompiled and re-compiled should behave the same, so maybe investing in the differences can lead to some clues about this issue.

bitlogik on Oct 1, 2020

This one fixed it for me:

pip install pynacl -I --no-binary pynacl

hellt on Apr 8, 2020