For brevity and clarity I'm just replying to Dan here, but I am attempting to 
address other points raised so far in this thread.

On Wednesday, 9 August 2017 13:07:08 UTC-4, Daniel Veditz  wrote:
> On Tue, Aug 8, 2017 at 5:30 PM, Mark Côté <> wrote:
> > I am not sure how often CCed users are involved with confidential bugs'
> > patches
> > ​[​
> > ​....] 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.

I think Gijs's post is quite interesting.  It furthers my idea that there are 
two main reasons you get involved in a confidential bug: either someone figures 
you should know about the issue, or you are pulled in to review the patch.  
(Although there are some outliers, like Ehsan, who fall under both.)  I 
actually like Gijs's proposal, to mirror *from* Phabricator *to* BMO.  That 
way, if you're looking at the bug and want to pull someone in, you CC them; if 
you're looking at the fix and want to involve someone, you add them as a 
subscriber which then incidentally lets them view the bug, for background and 
updates and such.  We can also add a clear comment ("user X has been CCed to 
this bug via Differential revision Y" or such).

I think we'd want to simplify here, though, and make such mirroing "one time", 
meaning you get CCed when added as a subscriber, but you wouldn't be removed 
from the CC list of the bug if removed as a subscriber, since people may be 
being directly CCed to the bug as well.

> > 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.

Yes.  You won't be able to submit a revision associated with a bug you don't 
have access to, but as long as you can attach a file to the bug, you can create 
an associated revision.

> 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.​

Sorry, I was not clear here.  I meant whether we'd want to do any mirroring of 
CC/subscriber lists for public bugs.  (This was rephrased as question 3 in my 
summary).  Seems that the answer continues to be "no" here.

> 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.

Yeah that's going to depend on what solution we come up with. :)  But my 
proposed solution above wouldn't be too difficult, as we are already doing some 
revision->bug updates anyway.

> 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
> patch.

I think my above proposal addresses this, particularly with comments indicating 
when someone has been automatically added to the CC list.

Thanks everyone for your input so far.

dev-platform mailing list

Reply via email to