today I updated SonarQube from version 10.3.0 to 10.4.0. We have the GitLab authentication running with scope of “read user”. This was working before the update. After the update the error message
The requested scope is invalid, unknown, or malformed.
occurred during the SonarQube login. After investing time in the documentation I found that the “api_read” scope is also necessary, but only if group synchronization is used, what we do not use. But I gave it a try with no success.
After playing around a bit with the scope, I realized that an api reat/write scope is now required for the authentication to work again.
I have 2 questions about this:
Today we were to update our instance and found out API access is also required but it’s not mentioned in the documents, this is an unprofessional thing that the application needs to read and write without our permission and even without mentioning somewhere as a source of truth, so my question is:
We are experiencing the same problem and prefer not to use group sync. We are hesitant to grant API scope access to Sonar as there is no official documentation regarding this change. Additionally, write access is not required for authentication purposes.
We acknowledge a bug was created in the 10.4 release. It impacts only users relying on GitLab JIT authentication without group sync.
We have created the following bug ticket to address the problem.
In the meantime, you can keep the workaround described in this thread: assign the api permission to the GitLab Application. We confirm that we shouldn’t ask for write permissions and that this workaround will only be temporary until the ticket mentioned above is released.
Thanks also for pointing out the documentation, it is now updated to reflect the current situation.
Are there any plan for a 10.4.1 with this bug fixed?
For security concerns, we are very hesitant about increasing the scope to api, and thus about upgrading to 10.4 at all.
There’s no plan yet to trigger a bug-fix release for this issue.
Granting the API permission to the GitLab application is not ideal, but it would be only a temporary workaround. Would you see any major issue in increasing the permissions of the application?
The main impact I see is for users of our SonarQube instance; they would have to accept a new application authorization with the buggy scope in SonarQube 10.4 and then accept a new authorization with the correct scope when SonarQube will be fixed.
I think it would be better for them to not go through this hindrance.
Would you see any major issue in increasing the permissions of the application?
Do I trust SQ enough to give it permission to read my GitLab user profile? Yes.
Do I trust SQ enough to give it permission to act in my name on our GitLab in any way it wants? Meh, I’m torn… I have elevated privileges on our GitLab… It’s not that I don’t trust SonarSource, but there are scenarios where SQ could be a vector of a wider attack (for instance via a compromised 3rd party plugin we would let slip in, or via a library flaw à la log4shell).
I might just choose to close my eyes/imagination on this slight and temporary risk, and just enjoy the new SQ 10.4 features, but still, I would be even happier with a 10.4.1
