Updated permissions request: "Read and write access to Contents"
MichaelKetting opened this issue · 39 comments
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
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
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
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.
@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.
Secretsis currently set as "no access".
@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.
This is a huge issue for us as well. I can't accept write access to the whole enterprise.
How can I restrict 'full write access' if I just installed the app? I don't have this option in the app settings
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?
So how does one disable the write permissions?
following
Any update here? thank you.
Just was asked for the Read and write access to Contents Permission. Cannot grant it due to company policies.
Same here.
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.
100% with you, this makes no sense, why isnt allowed to set what permission to let through
Same here, I don't think we can grant this. FYI @JJCassidyIotics
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).
Agreed. Not going to fly. Atlassian will have to try harder.
Echoing others here, passed on granting "Read and write access to Contents" (was read-only) last time and will do the same again.