MozReview API Keys

[Dylan Hardison]

Just a note -- ever since Bug 1184332[1] the API keys that
MozReview uses should only be used by MozReview.
Any other tool (like bzexport) should have its own API key.

This is because the methods that a mozreview-associated API key can call
are a restricted subset.

I think it is also a best practice for different tools to have
different API keys.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1184332

[Gregory Szorc]

So, this only impacts the API Key that the MozReview web interface requests
to be created. There may be a separate API key defined in the client config.

I just glanced at my API Keys page on BMO and there is no indication what
keys have what permissions. Is this feature on your roadmap?

Also, while I agree separate keys per service are good from a security
perspective, it does make initial configuration a bit more difficult:
instead of generating and configuring 1 API Key, now we have to generate
several.

To make matters worse, I don't believe there is a mechanism to request
generation of API Keys outside of the HTML interface. And, you can't
control which permissions are granted to newly-created keys via the HTML
interface. It would be really nice if the config wizard could open a page
like
"requestAPIKey?perms=post_comment,upload_attachment&description=bzexport",
the user could click "Generate Key," and they could paste the resulting key
into the config wizard. Until something as turnkey as this is implemented,
it is much easier to continue to use a single, full access API key for all
clients.

I love API Keys and the work being done around them. But there is still a
bit of work for them to achieve the security properties I think we want
them to eventually have.

> _______________________________________________
> tools-bmo mailing list
> tool...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/tools-bmo
>

[Dylan Hardison]

On Tue, Nov 10, 2015 at 12:54 PM, Gregory Szorc <g...@mozilla.com> wrote:
> So, this only impacts the API Key that the MozReview web interface requests
> to be created. There may be a separate API key defined in the client config.
>
> I just glanced at my API Keys page on BMO and there is no indication what
> keys have what permissions. Is this feature on your roadmap?

Yes, there's Bug 1223421 for now. When there's a capability system in
place we'll display that information too.

> Also, while I agree separate keys per service are good from a security
> perspective, it does make initial configuration a bit more difficult:
> instead of generating and configuring 1 API Key, now we have to generate
> several.

Well, "now" has been a long while... Bug 1184332 was a requested
feature for the benefit (= security) of mozreview.

If you've been using your mozreview api key for the last four months
and not noticed all the unknown method
errors... then you can continue using it. What will change is that you
won't be able to see the (content of) the mozreview api
key on the pref's page and instead of an unknown method error, you'll
get "you're not allowed to call that method" error.

> To make matters worse, I don't believe there is a mechanism to request
> generation of API Keys outside of the HTML interface. And, you can't control
> which permissions are granted to newly-created keys via the HTML interface.

Permissions are a desired feature but were lowered in priority while
we address other performance concerns.
I wanted both capabilities and a mandatory, but self-service app
registry but we opted for the minimum viable product
(which is Bug 1184332).

> It would be really nice if the config wizard could open a page like
> "requestAPIKey?perms=post_comment,upload_attachment&description=bzexport",
> the user could click "Generate Key," and they could paste the resulting key
> into the config wizard. Until something as turnkey as this is implemented,
> it is much easier to continue to use a single, full access API key for all
> clients.

This is exactly what auth delegation (that mozreview uses) does.
Currently it would not work
for a localhost app because it requires a POST request from BMO (which
was done to avoid disclosing
api keys in server logs) but I think this restriction could be relaxed
to allow a redirected GET request to localhost|127.0.0.1.

I currently run a shim on my server that lets me consume an API key in
emacs for my various api-using emacs utilities
(mostly to expand [[bmo:bug_id]] links with the bug summary in org-mode)

Prior to the refactor to POST requests I did it entirely in-process
(using the emacs httpd as an auth delegation endpoint).