Updated permissions request: "Read and write access to Contents"

[MichaelKetting]

Dear Jira Team,

I got an updated permission request last night from the Jira app for Github:

Read and write access to Contents
We have updated the contents permissions from 'read-only' to 'read & write.' We have done this so you can create a branch from a Jira Issue.

In the latest version of the Readme (https://github.com/atlassian/github-for-jira/blob/37134b68e9a1181a6dfd7dd5e8cc5b526b807b0b/README.md, Augst 24th), only "Read-only for Contents" is listed.

I do not wish to enable Write access to content because the "Create Branch" feature is not something that is helpful enough to warrent granted another service write access to my repository. I understand that Atlassian is taking security seriously, as stated in other threads on the permission topic, however, the least privilege principle still compells me to be as restrictive as possible.

Please advise on how to best handle this new app permission request. From what I gather, it's not possible to simply deny some permissions, so right now, I'm just not approving the updated permission request and wait what happens next.

Thanks for your consideration and help,
Michael

[tibbon]

I believe it is in relation to this commit: 32cfa6a

[jmleoni]

Hello JIRA Team,

I have the very same concern what is going to happen if I don't accept the new privileges requested by the app, will it continue to work as before without the branch creation automation ?

Kind regards

Jean-Marc

[diego-santacruz]

Hello Jira Team,

I have the same concern too, in particular that if I understand correctly the information at https://docs.github.com/en/rest/overview/permissions-required-for-github-apps#contents, giving write access to Content allows the app to do any operation on git commits, not just create new branches, and also a bunch of other things like commit comments, imports, reactions, etc.

That seems to be excessive and going against the principle of least privilege when the intent is for the app to be able to create branches, which is certainly useful but not a big thing either as Jira is already providing a copy & paste git command to do so.
But granted, github does not have a permission that just allows to create branches, just one plain "git" permission that allows to create commits, tags, etc.

As other users, I will not be approving the updated permissions for now.

Thanks,
Diego

[tibbon]

It is worth highlighting that I believe "Contents" also encompasses [PUT /repos/:owner/:repo/actions/secrets/:name](https://docs.github.com/en/rest/reference/actions#create-or-update-a-repository-secret) (write) and its GET equivalent.

This would allow read and write permission on private secrets, which many organizations use for highly sensitive values.

The feature of creating branches seems interesting, but the tradeoff here for it being a non-optional feature appear out of balance for most uses.

[mboudreau]

@MichaelKetting @jmleoni @diego-santacruz
The app will continue to work without this permission updated, however, if in the future a new permission is changed/updated for a new feature, you'll have to accept both changes.

We are working on a way for customers to have more granular control of the app permissions by create their own custom apps that still points to ours. We're currently in the process of prioritizing this story over many others vying for our attention. In the meantime, just don't update the permissions :)

@tibbon that's incorrect. As per the documentation you've linked:

GitHub Apps must have the secrets repository permission to use this endpoint.
Secrets is currently set as "no access".

[MichaelKetting]

@mboudreau Thank you for the update! Not updating is my plan for now :)

I've also created a request with Github to make partical revokations possible: community/community#38382

Maybe this could ehlp to make things easier.

[dmeatte-aq]

This is a huge issue for us as well. I can't accept write access to the whole enterprise.

[survived]

How can I restrict 'full write access' if I just installed the app? I don't have this option in the app settings

[diego-santacruz]

Just to reinforce the argument: the recent security breach at CircleCI shows why it is important to ask for the minimum required permissions. If the same kind of problem would happen with Jira it could mean that a malicious entity could break havoc in all repos of a company.

Is there any chance you would revise the rights required by this app to avoid requesting such wide rights, or at least make them optional?

[atzmony]

So how does one disable the write permissions?

[dmichau]

following

[csaba-kovacs]

Any update here? thank you.

[wiedemcn]

Just was asked for the Read and write access to Contents Permission. Cannot grant it due to company policies.

[adrian-gierakowski]

Same here.

[diego-santacruz]

Same here, I had already raised the issue 10 months ago about the read & write to Content permission just gives the Jira app plain access to all of git, and shortly after someone else pointed out that it also gives read & write access to private secrets, which is another no-no to most companies.

Atlassian: I think it is pretty easy to understand that write permission to git and reading of secrets is not acceptable in most companies, but it seems the Jira for GitHub app authors do not consider that important and just try to push new functions without regard for security. Could you please at least consider an app setting that allows to tailor what permission the app asks for? And note that read & write to Content permission is not required for most of the app (we have been using it long without granting it).

These are the permissions I currently have as request, and I will not be giving write access to Content, so not only we are unable to accept the new read-only permissions for alerts (which btw look good) but if we ever need to reinstall the app in the future we will simply not be able to use it as we would need to accept all permissions or none.

[csaba-kovacs]

100% with you, this makes no sense, why isnt allowed to set what permission to let through

[bernardcooke-iotics]

Same here, I don't think we can grant this. FYI @JJCassidyIotics

[DM-sb]

100% agree with the posters above. Not sure why we have to approve content read and write which is not needed for the functionality that we want (i.e. dependabot alerts).

[jonbaetz-qz]

Agreed. Not going to fly. Atlassian will have to try harder.

[jonorossi]

Echoing others here, passed on granting "Read and write access to Contents" (was read-only) last time and will do the same again.

[niksteff]

Stumbled upon this again this morning while pasting a repo link into a jira ticket and jira wanted access to correctly display the link.

Yeah this is an issue for us as well ... > 400 Employees etc. We are surely not granting write access to our enterprise repos and secrets. This has to change so the git feature is useful again.

[tibbon]

Looping back on this, I'd love to see Atlassian take this seriously and revert the changes that made this happen - or at least put some option/escape hatch on it. OWASP A5:2017-Broken Access Control is well documented, and this appears to be a step in that direction.

[jose7165]

mboudreau

...
We are working on a way for customers to have more granular control of the app permissions by create their own custom apps that still points to ours. We're currently in the process of prioritizing this story over many others vying for our attention. In the meantime, just don't update the permissions :)
...

@mboudreau @rachellerathbone,

I wonder if there is any update on this topic regarding more granular permissions? Write permissions for a given repository is one thing, currently the JIRA app asks us write permission for the entire organisation. Echoing the many other discussions on this ticket, this is not a permission level we are OK to accept, following the principle of least privilege.

If you're waiting on something to change from GitHub's end to support this, please let us know (also share a ticket ID if relevant), so that we can also flag the issue to GH.

Thank you!

[dashakostieva]

Just as users above, looking forward to a resolution that aligns with the best security practices and respects user preferences for customized permissions.

[MichaelKetting]

Jira App just re-requested permissions and now also wants write access for Deployments.

@mboudreau do you have an ETA when the team will resolve this permission problem? For existing users, we just have to remember to review and deny (at least until there's a new read-dependency we cannot go without). For new users, they cannot opt out of the permissions as far as I understand the system. Please consider this a major impediment. Thank you!

[quaelin]

Hi, just adding on the pile here. Jira has just requested write access to everything in GitHub, which we cannot grant. Would love to hear when there might be a more granular solution.

[tibbon]

This is a genuine reason to consider switching away from Jira, and the lack of response on this is stunning.

[alghanor]

Would like to hear how to control or take back write permissions once the general one has been granted.

[dmeatte-aq]

All I want is something that links commits to jira issues. This latest round of permission scope increases is incredibly frustrating.

[diego-santacruz]

I second that, this is getting ridiculous. Can anyone from Atlassian comment on this? This has been open for more than a year without any response from Atlassian.

[TarqusMiltonium]

I second that, this is getting ridiculous. Can anyone from Atlassian comment on this? This has been open for more than a year without any response from Atlassian.

If it helps set your expectations, it can often take ~3 years for Atlassian staff to respond, and then ~4 years to ship super-basic features in their most-used products. As an example, check out https://jira.atlassian.com/browse/CONFCLOUD-67895 -- that was for adding a border to an image in a Confluence page (yep, as simple as it sounds). Oh, and this was a feature that the on-prem version had for 15+ years, and was omitted from the "new" cloud editor. Ticket was Opened Sep 2019, only Fixed in Jun 2023. Replies from Atlassian staff were very few & far between (Interestingly, I swear that ticket had various ~annual replies over the years from project managers who promised to deliver the feature "soon", but as of today there are now no replies from internal staff until Oct-22 - either they deleted the old entries or I'm thinking of a different ticket - but either way, that record shows 3 years before a reply from Atlassian). Similar-aged issues exist for other "features" such as adjustable table widths, and I forget what else I waited for over those years.

I feel sorry for the Atlassian staff who will ultimately read this comment - I suspect that noone likes sitting on egregious bugs for 3+ years - but it's hard to feel anything other than annoyance when such fundamental usability issues go unaddressed for grossly extended periods of time.

Oh, and to join in the chorus, I am also unhappy granting about the "Read and Write Contents" permissions to the whole org. The Security Policy README lists the required permission for Contents as "Read only", which it clearly isn't - their app is essentially in violation of their own stated policy requirements. There also doesn't seem to be a way to secure this access further -- eg if I could grant the app R/W access but then deny write access by some other mechanism, I would be ok with that (this may be a GitHub limitation). To be clear, I'm not an expert in GtiHub security policies - but I also shouldn't have to be, just to run a Jira integration.

[MichaelKetting]

Hi @atrigueiro, I'm hoping you might be able to help us getting some eyes on this issue since it's gathering continued interest is is a real issue for those of us using both Github and Jira in production.

Thanks!
Michael

[Ryan-Yuanqing-Jiang]

Hi Michael, Milton, Diego and everyone else on the thread, this is Ryan I am the PM in the team at Atlassian working on this integration.

Thanks for raising your concerns and requests, and there's no question that we should've provided more visibility with responses on the thread. I can relate to the frustration here and apologise for the inconvenience caused, and I do agree that asking for Write access to certain data entities is just not viable in certain organisations/teams.

Some visibilities on the work-in-progress and challenges:

• We are actively exploring solutions to this issue in this and the next quarter (picking up from our previous attempt). And we aim to have a solution in place in the next quarter.
• Whilst we want to provide granular permission control, GH App has this limitation: there's a lack of flexibility to 'pick & choose' the permission grants, it's always 'all or nothing'. Therefore we have to get creative here to work around this issue, whilst being careful not to impact our current customers who are relying on the downstream features depending on some of the Write access.

Again, I am with you on this one: it's neither great nor easy to fix, but we could at least be more helpful by providing more visibility and responses.

To help with this, here's a public Request ticket that we will be using to track, provide feedback, and collect comments: https://jira.atlassian.com/browse/JSWCLOUD-25963 . A while ago we decided to close-source this repo to support further development, therefore we will spend less time monitoring the posts and threads on GitHub. Instead, we will rely more on the public request and bug tickets to collect feedback.

Thanks!

RJ

[MichaelKetting]

Thank you @Ryan-Yuanqing-Jiang for the detailed update!

[MichaelKetting]

I've added the ticket to my watch list and for transparency's sake, a cross-post of my suggestion:

For me it would be a perfectly okay option to not have those two features (create branches and URL-unfurling), thus sticking to a readonly solution. Maybe it would be possible to create two editions of the app built from the same codebase, one with write-access-based features and one where those are stripped out.

cc @Ryan-Yuanqing-Jiang

[diego-santacruz]

Thanks for the detailed update, it is very much appreciated to have some feedback and visibility. I have added a comment to the Jira issue detailing acceptable options for us. We would really like to see this move forward.

[Ryan-Yuanqing-Jiang]

Thanks guys, I will be updating the movement in this ticket onwards: https://jira.atlassian.com/browse/JSWCLOUD-25963

Appreciate the solution options here, separating Read/Write with 2 apps is on our list of options to evaluate. Just to keep it transparent, there's another initiative at play, where we need to be careful of the options we pursue.

Without getting into too much detail, we are currently:

• Spiking our solution options, to understand the 1st and 2nd order of impact, making sure needs for different customer cohorts are considered;
• After this, we will move on to executing in Q4. I will try to keep the community updated when we have a more solid timeline;

Thanks again for all your patience and support, this is what drives us.

[TarqusMiltonium]

Thanks for the update & new Issue link, most appreciated.

[bgvozdev]

#1820 (comment)