To answer the question not asked ;-)
I think we should strive to have as few people as possible with general access to security bugs. The concerns the folks have when crossing borders is awful. And just from a general risk profile. Saying that as someone that neither has nor wants access to security bugs in general. So, in that sense, I think we should make this a general assumption, that the folks writing patches and doing reviews are not in group of the bug. As to mirroring the information, I think it'd be good if there couldn't be people on phabricator that are not on the bug. That way, the folks on the bug that manage the security risk of it have one way of tracking the visibility of the security issue. I could see how not everybody involved in the bug automatically wants all the bugmail. I personally wouldn't mind if I could opt-in to that, but I'd be annoyed if I had to ask folks to manually add me again, after I asked them to CC me to the bug. More a question if it's technically feasible, could folks ask phabricator for access by following the link, and it would go back and check bugzilla on-demand if it should do that? Depends a bit on the additional private-attachment thing that Nicolas mentioned.

Am 09.08.17 um 02:30 schrieb Mark Côté:
(Cross-posted to

Hi, I have an update and a request for comments regarding Phabricator and 
confidential reviews.

We've completed the functionality around limiting access to Differential revisions (i.e. code 
reviews) that are tied to confidential bugs.  To recap the original plan, various security groups 
in BMO are mirrored to Phabricator as "projects", containing the same set of users.  When 
a bug has such a security group added to it, e.g. dom-core-security, thus restricting its 
visibility largely to members of that group, a Phabricator "policy" is similarly set on 
any associated revisions, restricting their visibility to the same group of people (plus the author 
of the revision, if they are not in the project already).

However, users outside of the security group(s) can see confidential bugs if 
they are involved with them in some way.  Frequently the CC field is used as a 
way to include outsiders in a bug.

Phabricator has a similar feature, called "subscribers", which, as with CCs, 
both grants visibility to confidential revisions and also sends email updates when the 
revision changes.  It was suggested that we attempt to synchronize CC and subscriber 

First I want to double check that this is truly useful.  I am not sure how 
often CCed users are involved with confidential bugs' patches (I might be able 
to ballpark this with some Bugzilla searches, but I don't think it would be 
easy to get a straight answer).  Anecdotally I have been told that a lot of the 
time users are CCed just to be informed of the problem, e.g. a manager might 
want to be aware of a vulnerability.  Given that adding subscribers to a 
revision is just as easy as CCing a user on a bug, if it is infrequent that 
outsiders need to be involved in reviewing confidential patches, I lean towards 
taking the simple route of making this manual.

However if this is more common than I suspect, then we must decide how to 
synchronize the lists.  The most straightforward approach is one-way 
synchronization from BMO, that is, anyone CCed on the bug will automatically be 
added as a subscriber to any associated revisions, but anyone manually added to 
the subscribers list who is not CCed on the bug would be automatically removed 
by the BMO-Phabricator synchronization routine.  The alternative is to keep 
track of who was manually added and who was automatically synchronized, which 
gets complicated rather quickly, both in terms of implementation and usability.

The second question that would come up is whether this synchronization should 
apply to all revisions or just confidential ones.  Given the dual nature of 
CCs/subscribers, for both visibility and notifications, I lean towards only 
doing this synchronization for confidential revisions, where it is more 
important.  A further justification for limiting the mirroring is that 
Phabricator has a much more powerful and fine-grained notification system 
(Herald) than BMO's product- and component-watching feature.  Automatic 
mirroring everywhere would reduce the utility of the former.

If you have any thoughts on this, please reply.  I'll answer any questions and 
summarize the feedback with a decision in a few days.  Note that we can, of 
course, try a simple approach to start, and add in more complex functionality 
after an evaluation period.

To sum up, there are three questions:

1. Is mirroring a confidential bug's CC list to association Differential 
revisions' subscriber lists actually useful?  That is, does the utility justify 
the cost of implementation and maintenance?

2. If yes, is one-way mirroring, from BMO to Differential, sufficient?

3. Again if #1 is yes, should such mirroring be limited to confidential bugs, 
given that Phabricator's notification system is more fine-grained, and thus 
more useful, than BMO's product- and component-watching feature?


dev-platform mailing list

Reply via email to