Having both reported, fixed and reviewed security bugs, I feel an
uni-directional sync from Phabricator to BMO is not going to cut it. I
think it will be unexpected for most users and might just lead to
additional "why can I not see the patch" bug comments.
I understand that it's more work, but I really think we should aim for
"perfect" rather than "good enough", when it comes to developer experience.
I don't see a strong "security reason" not to include people copied in
the bug to see the patch. Quite contrary: It's also what distinguishes
our bug bounty program from others. We're more open, we have outside
reporters work with us on the patch and see all the comments and
iterations that lead to its perfection. This encourages early feedback
and improves the outcome.
On 10.08.2017 00:57, Daniel Veditz wrote:
> On Wed, Aug 9, 2017 at 11:32 AM, Mark Côté <mc...@mozilla.com> wrote:
>> 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.
> What if there's not "the" fix but multiple patches? This is quite common
> for security bugs where a testcase that reveals the vulnerability is done
> in a separate patch so it can be checked in after we release the fix. Or
> occasionally bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1371259
> that had 9 separate patches. Would the same people have to be separately
> subscribed to each?
> There's a case to be made for adding in both directions. How much work
> would it be to (add all CCs to subscriber list) when attaching a new patch,
> and (subscribe person to all existing patches) when someone new is CC'd to
> a bug? This was my attempt to match your "one time mirroring" approach to
> going the other way, which makes sense to me.
> And don't forget reporter and assignees. Occasionally a reporter not in the
> security group will notice that a patch is insufficient which is nicer to
> find before the patch is committed than after the commit link is added to
> the bug. Sometimes someone other than the official assignee adds a patch
> for an alternate approach to a fix and asks the assignee for feedback,
> though that's uncommon and the assignee could just be manually subscribed
> to the patch at that point.
> We can wait and see how common the "please subscribe me to the patch"
> requests are, but I suspect they'll be common enough.
> Dan Veditz
> dev-platform mailing list
dev-platform mailing list