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
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
