Closed
Bug 1507012
Opened 6 years ago
Closed 6 years ago
start (or make available) gnome-keyring for xpcshell tests
Categories
(Testing :: General, enhancement, P1)
Testing
General
Tracking
(firefox65 fixed)
RESOLVED
FIXED
mozilla65
Tracking | Status | |
---|---|---|
firefox65 | --- | fixed |
People
(Reporter: keeler, Assigned: keeler)
References
Details
Attachments
(1 file)
(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.
Comment 1•6 years ago
|
||
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.
Product: Taskcluster → Testing
Assignee | ||
Comment 2•6 years ago
|
||
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...)
Flags: needinfo?(dustin)
Comment 3•6 years ago
|
||
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.)
Flags: needinfo?(dustin)
Updated•6 years ago
|
Priority: -- → P3
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → dkeeler
Priority: P3 → P1
Assignee | ||
Comment 4•6 years ago
|
||
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.
Comment 5•6 years ago
|
||
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.
Flags: needinfo?(dkeeler)
Assignee | ||
Comment 6•6 years ago
|
||
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
Flags: needinfo?(dkeeler)
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
Comment 8•6 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox65:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in
before you can comment on or make changes to this bug.
Description
•