Open Bug 1877805 Opened 5 months ago Updated 4 months ago

Assess use of external addon Atlassian Cloud in Mozilla's GitHub organization mozilla-mobile

Categories

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

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: daniela, Assigned: ctb, NeedInfo)

Details

Attachments

(1 file)

Attached image permissions

I want to use the Atlassian Cloud addon in mozilla-mobile for the following reasons:

I am trying to use the Development feature on Jira to track Github commits. I was told by Jira admin that it is already setup on that end but I need the necessary permissions to setup on the GIthub side.

Below are my answers to your stock questions:

** Which repositories do you want to have access? (all or list)

** Are any of those repositories private?

  • no

** Provide link to vendor's description of permissions needed and why
I couldn't find a link but I provided a screenshot

** Provide the Install link for a GitHub app
I couldn't find a link

Hi Daniela, thanks for the bug. Jira is generally approved for private and internal repositories currently.

Jira also came up in another ticket for MozillaSocial (Bug 1876183). The tl;dr is that there's a risk of confidential information leakage with public repos. Hal left a comment there that outlines his concerns and some recommendations.

I think this point is probably relevant here:

If the current [Jira] app installation did not grant any write permissions, then public repositories can be added to the existing installation in Mozilla Social.

If the current [Jira] app installation was granted write permissions, then there are multiple options to mitigate the unintended disclosure of confidential information:

  • Create a 2nd app installation, solely for public repos, where the write permissions are not granted.
  • Apply the "marked project" workaround to all Jira projects that will be connected to a public repo (the prior work with Gene)
  • Contact the prior requestors for connection to non-public repos, and see if they have any objection to removing the write permissions (assumes that their use cases do not require the write permissions). Once they are removed, approach #1 is viable again.

On that point about the "marked project" workaround, this is something that Gene Wood worked on, you might want to ask him about this. There's also a little more context in the full comment on the bug.

I'm going to needinfo Hal in case he has any other input. But I hope the above makes some sense. If security approval is granted, then the 2nd Jira app installation can be requested through the GitHub Marketplace I believe.

If the above sounds too complicated, another way to track GitHub commits would be through the GitHub Desktop app. I believe that it can send notifications on commits, PRs, and other activity, and it also provides a way to browse the commit history.

Assignee: nobody → cbrentano
Status: NEW → ASSIGNED
Flags: needinfo?(hwine)

Our FXIOS jira project already has a 2-way sync setup with Github for issues. I am just trying to get pull requests and commits also linked to the jira issue. I believe that makes it a little different than the moz social case.

James: On the Jira side, is FxiOS tagged as being a "non confidential project"? I don't see any visual indicators in the linked issues, e.g. this one.

What am I not understanding about the approach you and Gene worked on?

Flags: needinfo?(jdirks)
Flags: needinfo?(gene)

I've asked James for more detail in https://bugzilla.mozilla.org/show_bug.cgi?id=1876183#c7 as I don't have any links to the work.

Flags: needinfo?(gene)

I've searched for a Jira issue or email regarding this, but I haven't been able to find any. I currently see this field active on a test project I have, but I don't see it assigned to other projects. I do recall that along with that during testing we set this field as 'required' and the person creating the Jira issue would have to check the box to be able to create the issue.
I'm not sure of activity beyond the testing. If I recall, project syncs (using the Unito app) were disabled where it was decided they should not be synced to a public repo.

Flags: needinfo?(jdirks)

So, we have several issues here:

  1. What general approach is appropriate for a sync-from-default-confidential-tool-to-default-public-tool?
  2. What do do about this request?

Presently, I feel like I'm lacking some specifics about precisely what is being sync'd where, and what controls are available to adjust that. This does seem to common request, so is worth some digging.

I'll start an email thread to get the technical details, and that should lead to actionable information for this case.

Following up on this. Was an email thread started?
I am going to be passing this on to Andy, so please reach out to him for further steps.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: