776366 - Consider allowing restricted native Bugzilla REST API access to bugs that are not otherwise accessible to a user

Status: NEW

(bugzilla.mozilla.org :: API, enhancement)

Description

[Boris Zbarsky [:bzbarsky]]

Consider the case of a script that handles marking bugs after m-c<->inbound merges.  Such a script needs to read/set the status whiteboard, 
read/set resolution, add a comment, read/set bug flags, read/set 
attachment flags, read/set target milestone.

Notably, it does NOT need to read comments or read attachment content.

It may be reasonable to allow such a script to operate on restricted (e.g. security-group) bugs even if the user it's logged in as can't normally load such bugs.  Either as part of a new group, or by allowing it for all users.

Comment 1

[:glob ✱]

i have concerns over the potential for information to be leaked from bugs (such as legal, and other products not directly related to firefox development).  i'm adding the sec-review-needed ketword to loop security into this.

from a technical point of view, bzapi is a proxy which sits in front of bmo.  this makes it difficult to add new calls which require a tight amount of integration.

my preference would be to add a new bugzilla-native xmlrpc/json method to address just the needs of a m-c<->inbound merging script.  it would have to be available to members of a trusted group, and it should only have these enhanced abilities on selected products, not system-wide.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Byron Jones ‹:glob› from comment #1)
> i have concerns over the potential for information to be leaked from bugs
> (such as legal, and other products not directly related to firefox
> development).  i'm adding the sec-review-needed ketword to loop security
> into this.

Dan might have some opinions on this, cc'ing.

Comment 3

[Ed Morley [:emorley]]

(If we were to do this, it would now be with the new native REST API, rather than the BzAPI proxy)

Comment 4

[Mark Côté [:mcote]]

Looks like security never got back to us on this.

Comment 5

[Mike Hommey [:glandium]]

Another context where such a feature would be useful: pulsebot currently posts landing messages to bugs, except when it doesn't have access to the bugs, which includes security bugs. In an hypothetical future where pulsebot also handles closing bugs on landing on central and switches flags when uplifting on other branches, the fact that it can't act on e.g. security bugs will become an even bigger burden to the people landing those bugs.

Comment 6

[Mark Côté [:mcote]]

I think this will become more and more relevant as we add more automation.  Yvan hasn't worked here in a while, though, so clearing him.  I'll bring this up again with security soonish.