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é <mc...@mozilla.com> 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. Mark _______________________________________________ dev-platform mailing list firstname.lastname@example.org https://lists.mozilla.org/listinfo/dev-platform