(not sure if this is the right component) In bug 1498909, we're trying to dynamically load libsecret as a way to access secret storage provided by the OS. It turns out that our xpcshell testing environment doesn't have access to gnome-keyring, so all of the tests fail. It would be great if we could start gnome-keyring-daemon or make it available for these tests on our testing infrastructure.

It's straightforward to install things in docker images using in-tree changes. Those include scripts that do the setup of a docker container before running tests, among other things starting pulseaudio (look for `pactl` under `taskcluster/`). That would probably be a good place to start gnome-keyring-daemon, if indeed that's possible.

On a local docker setup, I can only get gnome-keyring-daemon to run if I run the container with the --privileged option (otherwise I get an "Operation not permitted" error). Is this an option on our infrastructure? (I'm assuming no...)

Not really, no. We can muck with the Apparmor profile to add specific capabilities, but only after thinking hard about what undesirable behavior that might permit. Any idea what capability it needs? I'm guessing something about memory locking, maybe. Is there some way to mock the service out, or convince it not to use that capability? Alternately, the talos hosts run tasks on the "native" system, instead of in Docker. Perhaps the specific test that needs this functionality could run on those hosts, as well? Then you'd need to work with relops to get the keyring service properly started up there (and work around any modal popups, etc.)

Counterintuitively, gnome-keyring-daemon needs its capabilities removed in order for it to run in docker (doing so means that it can't lock secrets in memory, but since this is for tests and we aren't storing any actually sensitive secrets, this should be fine). This patch also makes sure gnome-keyring-daemon is running with an unlocked keychain before the tests are run.

Over in bug 1503756, folks are blocked because when they update desktop1604-test, XSession starts crashing, and Android 7.0 tests start failing. Are you able to avoid that somehow? Got a try run, with Android 7.0? See https://bugzilla.mozilla.org/show_bug.cgi?id=1503756#c53 especially.

No - this doesn't seem to help whatever's wrong with XSession on Android 7: https://taskcluster-artifacts.net/FwSP4SyZShaTPKWIpdYqLw/0/public/logs/live_backing.log: [task 2018-11-27T18:25:40.604Z] /builds/worker/bin/test-linux.sh: line 196: 49 Trace/breakpoint trap /etc/X11/Xsession 2>&1

Pushed by gszorc@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c6135d5825bb set up and start gnome-keyring-daemon so libsecret works in Firefox in our test environment r=dustin