[Bug 1875410] Re: “sudo pip3” unusable because “import keyring” hangs for a long time

[Dmitry Shachnev]

Note that running pip as root is discouraged, as it may break your
system packages.

In any case, if you do not need keyring support in pip, try setting this
environment variable:

PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to python-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/1875410

Title:
  “sudo pip3” unusable because “import keyring” hangs for a long time

Status in python-keyring package in Ubuntu:
  New

Bug description:
  0. Upgrade to focal (the problem was not present in eoan).
  1. Try pip3 install somepackage. It works.
  2. Try sudo -u nobody pip3 install somepackage. It works (assuming appropriate file permissions).
  3. Try sudo pip3 install somepackage. It hangs for about 30 seconds.
  4. Try sudo env -u HOME -u XAUTHORITY pip3 install somepackage. It works.

  The reason is that the “import keyring” statement attempts to contact
  org.freedesktop.secrets via DBus. However, when root does it using a
  user’s X connection, a “DBusException:
  org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name
  'org.freedesktop.secrets': no such name” is the result. When DBus
  seems to be present like this but does not in fact work, and it is the
  case when either HOME or XAUTHORITY environment variables are
  preserved by sudo (and it preserves the latter in the default
  configuration), it waits for the entire duration of the timeout.

  There seem to be two issues here:
  a) The DBus environment is somehow such that it appears functional but isn’t.
  b) The keyring module initialization performs work which is isn’t even needed by the calling code (pip calls get_credential(url="https://pypi.org/simple", username=None) which, because username is None, never contacts any backends).

  Perhaps the following fixes are in order:
  a) The DBus machinery should recognize cases where it isn’t going to receive an answer so it can raise an error without timing out.
  b) The keyring module should be as lazy as possible and it should avoid initializing its backends until a request comes that needs to be forwarded to at least one of those.

  The problem (a) might be specific to certain secret storage backends,
  I’m using whatever KDE has as the default.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: python3-keyring 18.0.1-2ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
  Uname: Linux 5.4.0-26-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Mon Apr 27 16:45:03 2020
  PackageArchitecture: all
  SourcePackage: python-keyring
  UpgradeStatus: Upgraded to focal on 2020-04-26 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-keyring/+bug/1875410/+subscriptions