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.
Axel
Am 09.08.17 um 02:30 schrieb Mark Côté:
(Cross-posted to mozilla.tools)
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
lists.
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?
Thanks,
Mark
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
