Closed Bug 737831 Opened 9 years ago Closed 9 years ago

Confidential Partner Data Handler Group

Categories

(bugzilla.mozilla.org :: Administration, task)

Production
task
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mbest, Assigned: dkl)

References

Details

We are starting to see more code coming in that's private and requires us to extract a public test case from it.  In an effort to protect this code, but still give it a good chance to be worked on, we would like to create a group that allows this code to be added to Bugzilla but to have this 3rd party code private. Once we have a public test case is completed we can open things up, either by creating a new bug and attaching the public test case or by opening up the original but removing the private code.

The scope of those that have access to the group should be restricted to MoCo and MoFo employees and contractors.  Alternatively, we can supply a list of those that should have access in the short term.  usevisibilitygroups should be restricted to these two groups.  CCing a user to a bug would ideally give them access to it so we can include the 3rd parties whose code is being investigated.

This group should be available across all project related to Gecko (Firefox, Fennec, etc).
Johnathan and JP.  Have a look an let me know if I have correctly captured how the "Confidential Partner Data Handler Group" should be setup?
I think this is mostly right, though I should note that "removing the private code" is hard -- removing attachments in bugzilla, historically, has been a rare, admin-managed event since it involves hacking directly on the matrix.

On the other hand, an attachment can be marked private even when the bug is opened.
(In reply to Johnathan Nightingale [:johnath] from comment #2)
> I think this is mostly right, though I should note that "removing the
> private code" is hard -- removing attachments in bugzilla, historically, has
> been a rare, admin-managed event since it involves hacking directly on the
> matrix.
> 
> On the other hand, an attachment can be marked private even when the bug is
> opened.

Perhaps it would be better to just create a new bug and transfer the test case over.  Comments may code details and it would be better not to have this exposed.
That is administratively easier, and might be the right approach in some cases, but we like to limit the number of bugs we leave permanently closed, so I think it should be an option of last resort.
(In reply to Johnathan Nightingale [:johnath] from comment #2)
> I think this is mostly right, though I should note that "removing the
> private code" is hard -- removing attachments in bugzilla, historically, has
> been a rare, admin-managed event since it involves hacking directly on the
> matrix.
> 
> On the other hand, an attachment can be marked private even when the bug is
> opened.

of these two options it's probably better to delete the attachment, as that's built into bugzilla (we don't need to hit the db directly), and private attachments are generally used for security related attachments.
Does being able to mark code as private require a configuration change to the group?
Does having users able to delete the attachments require a configuration change to the group?
Is deleting an attachment difficult?

I would like to make sure we bring these comments back to what we want the admins to setup.
(In reply to Martin Best (:mbest) from comment #6)
> Does being able to mark code as private require a configuration change to
> the group?

yes, on bmo, any comments and attachments which are private are visible only to the core-security group.  we can't have multiple private groups, so (ab)using private attachments really suitable.

> Does having users able to delete the attachments require a configuration
> change to the group?

deleting attachments is a bmo admin only function; it doesn't require direct db access as suggested in comment 2, however it isn't something we can make available to non-admins.

> Is deleting an attachment difficult?

3 steps -- enable attachment deletion, delete the attachment's payload, then disable attachment deletion.

when you ask us to delete an attachment, only the payload itself is removed (the meta data remains), and a comment is automatically inserted with the reason for the attachment deletion.
Severity: normal → enhancement
OS: Windows 7 → All
Hardware: x86_64 → All
Version: Development → Current
My view is that the least worst option is to leave the original bug secret. Attachment deletion would be a difficult workflow because of the admin requirement, and abusing the security group to hide them isn't ideal either. 

We can link the two bugs together via dependencies so people can imply from the first _why_ it's still secret.

Gerv
+1 (Comment 8) I'm coming to a similar conclusion.
(In reply to Martin Best (:mbest) from comment #0)
> The scope of those that have access to the group should be restricted to
> MoCo and MoFo employees and contractors.

Just wondering - what is your estimate of the distribution of the code snippets in question that would fall into these buckets:

- limited to being viewed solely by employees (e.g. by a legal agreement between MoCo and another company)
- limited to being viewed by a small, trusted set of contributors, at our discretion, who may or may not be employed by MoCo?

I get the impression that the second bucket might be suitable for the majority of the cases that we're discussing - maybe that's an incorrect assumption?

I think it would be nice if we could try to avoid using the "employment" line as the criteria for membership as much as possible. I understand that that may not be possible in all cases.
(In reply to Martin Best (:mbest) from comment #9)
> +1 (Comment 8) I'm coming to a similar conclusion.

I would add we should be clear that the goal of the hidden bug isn't to produce a fix, its to produce a reduced test case that goes to a public bug to be worked on.
Gavin: my impression is that, unfortunately, it's all the first bucket - because these companies will only release the code under some sort of NDA, and non-Mozilla contributors don't have an arrangement with Mozilla whereby they would be bound by any NDA we signed. Therefore, this is one of those cases where the line, sadly, needs to be "employment".

But I could be wrong. If these code releases are "gentleman's agreement" rather than NDA, then there could be stuff in bucket 2.

Hang on, though... my understanding from the newsgroup discussion was that no-one is going to be a member of the new group by default; everyone who needs to see a bug will get CCed manually. Isn't that right? If so, this mechanism provides for as much flexibility as we need. But, reading above, that's not what comment 0 says. Can someone clarify?

Gerv
Reply to Comment 10:

I did check with Legal on a project with NDAs and private code and they did say that contractors are covered if they signed our standard agreement.  However, logistically it maybe too hard to id them as such in Bugzilla so keeping it employee only for now is fine if that's the case.

Having people without an agreement with us look at private code needs the sign off of the owner of that code.
Reply to Comment 12:

That was Asa's suggestion.  

The reason I looked to see if we could get MoCo and MoFo staff included is that having to CC everyone makes it more work for the person submitting or driving the bug to find someone to fix it.  Having a bug group accessible to the staff makes it easier for people to grab something when they have time.

The best reason not to do it this way is that it could add leak risk due to people not fully understanding the requirements of have access the code.  In this case, I think it would trump the reduced work mentioned above and Asa's idea should be the way to go.
About Comment 14:

We need to figure out which way this needs to go before the group can be setup.
Seems like we are not going to get anymore input on this issues so the finall version will be:

* A private group with no members to start, except for me to manage it.
* You can't see the bug unless you are CCed or the owner of the bug.
* We will have the ability to add members as we go.
Proposed Action: 

* Create new group:
  - Name: "partner-confidential"
  - Description: "Confidential Partner Data"
* No members initially except for mbest who will manage it initially.

Sound good?

Still need:

* List of products to enable the new group for (i.e. Firefox, Fennec, etc).
* Should this be always fileable even by those not in the group? 

dkl
First two bullets looks good.

* Products
** Boot2Gecko
** Firefox
** Core
** Fennec
** Fennec Native
** Mozilla Labs

Anyone should be able to file into it not being a member.
(In reply to Martin Best (:mbest) from comment #18)
> First two bullets looks good.
> 
> * Products
> ** Boot2Gecko
> ** Firefox
> ** Core
> ** Fennec
> ** Fennec Native
> ** Mozilla Labs

Thanks. Will get it setup as soon as I can.

> Anyone should be able to file into it not being a member.

This will require some code change and may need to go out with our weekly code push next week.

dkl
Assignee: nobody → dkl
Status: NEW → ASSIGNED
Ok, that time frame works so sounds like a plan.
Group created and added to the products listed. Code change to make always fileable will go out with the next code push.

Committing to: bzr+ssh://dlawrence%40mozilla.com@bzr.mozilla.org/bmo/4.0
modified extensions/BMO/lib/Data.pm
Committed revision 8139

Committing to: bzr+ssh://dlawrence%40mozilla.com@bzr.mozilla.org/bmo/4.2
modified extensions/BMO/lib/Data.pm
Committed revision 8126.

dkl
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(In reply to Martin Best (:mbest) from comment #18)
> First two bullets looks good.
> 
> * Products
> ** Boot2Gecko
> ** Firefox
> ** Core
> ** Fennec
> ** Fennec Native
> ** Mozilla Labs
> 
> Anyone should be able to file into it not being a member.

You've forgotten Toolkit.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Good catch, can we add toolkit.
added to toolkit.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Blocks: 772776
You need to log in before you can comment on or make changes to this bug.