(install) tests already try to initialize SecretService/Dbus keyring (DBusException, failing)

Johannes Dewender avatarJohannes Dewender created an issue

I am maintaining the Python 3 version of the Arch Linux package of python-keyring: https://aur.archlinux.org/packages/python-keyring/

The packaging runs nosetest3 in the "check()" part. When having python-secretstorage installed, that part is also tested and fails on the building user (different from the user running the X session) with:

dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

When running the same with the user that created the current X session it opens a Window asking to set a password for a new keyring.

Either that shouldn't happen or python-keyring doesn't have any (usable) install-time/packaging tests. With install-time/packaging tests I mean what is done with "make check" in autotools and it should be non-interactive and self-contained (as in: doesn't fiddle with configurations and such).

Comments (10)

  1. Johannes Dewender

    Debian doesn't have the problem since they decided to not include python-secretstorage in the build environment, because they "have not found a good a way to run tests that require dbus in a chroot".

    I would suggest making that test optional or mocking dbus or other parts.

    The only other option I have as a package maintainer is removing the tests from packaging. So problems with conflicting apis/versions/whatever can only be found on usage later on.

  2. Johannes Dewender

    For the DBusException I get when packaging: The dbus daemon/session for the user is usually started with the X session of the user (that logged in via xdm or similar). The build user has or has not access to the currently running X server (xhost +localhost?), but probably doesn't have his own dbus session (my build user certainly does not). In both cases (no X and no dbus) the test should be skipped.

    In general nothing that needs user-input should be tested so actually acessing the keyring of the current user probably shouldn't be tested when that would ask the user for a password or anything. Mocking might help to keep password inputs from opening. However, skipping the test when dbus can't be accessed is more important (see above).

  3. Johannes Dewender

    I can actually start dbus for that user prior to the build with

    eval $(dbus-launch --sh-syntax)
    

    Then the tests don't fail, but it looks like some timeout is reached (tests hang for several seconds), not being able to access it anyway. (build uses fakeroot, and xhost +localhost is set) So I'd just skip the test when dbus isn't available, too.

  4. Dmitry Shachnev

    SecretStorage r86 now replaces this type of exceptions with SecretServiceExceptions, which will lead to the test being skipped.

    Also, to run the Secret Service tests in a clean environment you also need some kind of Secret Service daemon running. I have tried launching gnome-keyring, but it fails to start in such environments. How are you going to solve that problem?

    The ultimate solution to fix that will be to write a mock Secret Service replacement with python-dbusmock, but that might be quite complicated.

  5. Johannes Dewender

    Dmitry Shachnev Trying your code (with no dbus session) gives: NameError: global name 'DBUS_NO_REPLY' is not defined. After adding it to the imports it works. Thanks.

    Not having a "Secret Service daemon" running is probably what leads to several seconds stalling. I didn't check what exactly happens, but after that amount of time the testing succeeds (with lots of skipping).

    You might also know what happens in https://bitbucket.org/kang/python-keyring-lib/issue/133/on-import I'd guess that secretstorage.Collection(bus) needs a configured keyring, not finding org.freedesktop.secrets otherwise.

  6. Dmitry Shachnev

    Trying your code (with no dbus session) gives: NameError: global name 'DBUS_NO_REPLY' is not defined. After adding it to the imports it works. Thanks.

    Fixed in bzr branch, thanks!

  7. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.