On Tue, Aug 8, 2017 at 5:30 PM, Mark Côté <mc...@mozilla.com> wrote:
> I am not sure how often CCed users are involved with confidential bugs'
> ....] 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.
People are CC'd for both reasons quite often. Couldn't tell you if it's
50-50 or 30-70.
> 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.
Can someone who is the assignee of a confidential bug, but is not in the
security group, create a confidential Phabricator patch for that bug? That
case happens quite often as some simpler security bugs are taken by the
reporter or assigned to newer team members. If so then I guess we could try
the manual approach as a MVP until it annoys people too much.
The second question that would come up is whether this synchronization
> should apply to all revisions or just confidential ones.
For a confidential bug, why would some revisions be confidential and some
not? It's not uncommon for a bug to be marked confidential after work has
started on it and security ramifications become clear. We'd want that
confidentiality to apply to the patches that already exist because they may
provide outsiders the same hints about the problem they gave us.
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?
How much work is it? Hard to know how much work reducing the annoyance and
friction is worth.
2. If yes, is one-way mirroring, from BMO to Differential, sufficient?
Probably not, especially if you don't block subscribing people for
confidential bugs. People will be blindsided if they've subscribed people
and then it gets wiped out. Being told you have to go to BMO for that bug
will be an annoyance, but at least you won't think you've given someone
access when you really haven't and then wonder why they never review your
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?
I'm on the fence about #1 (I lean toward 'yes'), but definitely only
needed for confidential bugs.
dev-platform mailing list