-
Bug
-
Resolution: Fixed
-
Critical
-
None
The latest version of the plugin is asking for too much permissions when the users are logging into a Jenkins instance using GitHub OAuth.
I agree that the plugin needs this many permissions to access the various parts of a github's repository, but I believe the scope for user authentication can be narrowed down to username/email address.
I believe it's just a matter of using the right scope for regular user authentication instead of the more broader scope that the plugin needs for "administrative" tasks.
Please see https://github.com/saltstack/salt-jenkins/issues/61 for additional information of the permissions being asked to a regular user.
- is related to
-
-
- Resolved
-
-
JENKINS-27691 make Github OAuth Scopes configurable
-
- Resolved
-
[JENKINS-26145] Narrow down github auth scope for user logins
Given that the source code of the plugin is available, isn't this more cosmetic than anything else?
norman richards
added a comment - Given that we want this plugin to work for a wide variety of users, (my assumption) shouldn't the default scopes be more reasonable? I'd suggest they should be configurable so that a jenkins installation can chose the permissions appropriate for it's users.
norman richards
added a comment - Given that we want this plugin to work for a wide variety of users, (my assumption) shouldn't the default scopes be more reasonable? I'd suggest they should be configurable so that a jenkins installation can chose the permissions appropriate for it's users. Sure, the plugin should restrict itself to the minimum. But I meant that the impact of any additional permissions can be known with certainty in this case: It's not like you give access to your account to a third party, but to software you run yourself and can read the source code of. Therefore I don't see how this can be classified as anything more severe than Minor.
It's not like you give access to your account to a third party, but to software you run yourself and can read the source code of. Therefore I don't see how this can be classified as anything more severe than Minor.
Let's consider the following...
Your company has a Jenkins installation using this plugin. This plugin requests access to ALL repositories, including your private repositories, not just your company's private repositories.
Do you really think that your company should have access to your private repositories?!
After reading the source code I think that the permissions were broaden to support the Github Commiter Authorization Strategy. If this is the case, I think that only when using Github Commiter Authorization Strategy the permissions should be broaden.
Of course, preferably, you should be able to tell the plugin what permissions you want to ask from your users, and the plugin should warn if any of it's enabled features require more permissions...
To be honest if this could have higher than critical priority that would be great.
Lukasz Guminski
added a comment - I have developers who are strongly concerned about giving Jenkins the access to all their repositories. Because there is no option to cancel Github authentication (no cancel button) and fall back to an alternative authentication method (e.g login/password), they are reluctant to use Jenkins at all.
Lukasz Guminski
added a comment - I have developers who are strongly concerned about giving Jenkins the access to all their repositories. Because there is no option to cancel Github authentication (no cancel button) and fall back to an alternative authentication method (e.g login/password), they are reluctant to use Jenkins at all. A PR has been merged which addresses this issue, however, it still requires the read:org scope to be set(see explanation here)
Lukasz Guminski
added a comment - Great news! Thanks 
Sam Gleske
added a comment - Fixed in release 0.21. 
Yeah, this is pretty important. You can't expect users to give full access to their account just to access jenkins.