--- Comment #11 from Chris Steipp <> ---
Just to clarify, my concern was that I think I've seen the password for the
Selenium_user account, and I we probably store it in Cloudbees somewhere. So
it's likely several people have had access to it at one time or another.

Because test/test2 is a production domain, a sysop who inserts malicious
javascript there can escalate their privileges across the cluster. We can take
away CORS access from test/test2, but then cross-domain gadgets and other
things that should be tested will fail. So after talking to Chris McMahon, I
remove sysop and bureaucrat from Selenium_user.

Options for going forward:
* Don't run tests that require sysop on the production cluster
* Move the permissions that we need for the tests (I'm guessing these are all
flow specific currently?) into a new group on test/test2, and assign
Selenium_user as the only user in that group.
* Have the tests use OAuth, with a grant that only contains the necessary
rights and is only valid on those wikis, so that the Selenium_user's actual
password doesn't have to be shown/stored anywhere.

You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to