-
Notifications
You must be signed in to change notification settings - Fork 474
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: scanning gitlab private repositories #3581
Comments
Hey @adam-moss! Can you provide some more information? Are you using the latest version of Scorecard (v4.13.0)? Did you grant access to |
Hi, Yes, latest per
An example would be: % scorecard --repo https://gitlab.com/adam-moss/danger-bot
Starting [Dangerous-Workflow]
Starting [License]
Starting [Dependency-Update-Tool]
Starting [Fuzzing]
Starting [Contributors]
Starting [Code-Review]
Starting [Packaging]
Starting [Token-Permissions]
Starting [Vulnerabilities]
Starting [SAST]
Starting [CII-Best-Practices]
Starting [Pinned-Dependencies]
Starting [Maintained]
Starting [Security-Policy]
Starting [Binary-Artifacts]
Starting [CI-Tests]
Starting [Branch-Protection]
Starting [Signed-Releases]
Error: RunScorecard: repo unreachable: repo inaccessible: adam-moss/danger-bot access level private
2023/10/18 21:26:03 error during command execution: RunScorecard: repo unreachable: repo inaccessible: adam-moss/danger-bot access level private Compared with a public repo, e.g.: % scorecard --repo https://gitlab.com/adam-moss/dotfiles
Starting [Security-Policy]
Starting [Dangerous-Workflow]
Starting [Binary-Artifacts]
Starting [SAST]
Starting [Contributors]
Starting [Fuzzing]
Starting [Branch-Protection]
Starting [CII-Best-Practices]
Starting [Packaging]
Starting [Dependency-Update-Tool]
Starting [Signed-Releases]
Starting [Token-Permissions]
Starting [Pinned-Dependencies]
Starting [Maintained]
Starting [CI-Tests]
Starting [License]
Starting [Vulnerabilities]
Starting [Code-Review]
Finished [Security-Policy]
Finished [Dangerous-Workflow]
Finished [Binary-Artifacts]
Finished [SAST]
Finished [Contributors]
Finished [Fuzzing]
Finished [Branch-Protection]
Finished [CII-Best-Practices]
Finished [Packaging]
Finished [Dependency-Update-Tool]
Finished [Signed-Releases]
Finished [Token-Permissions]
Finished [Pinned-Dependencies]
Finished [Maintained]
Finished [CI-Tests]
Finished [License]
Finished [Vulnerabilities]
Finished [Code-Review]
RESULTS
-------
... Thanks 😄 |
Your private repo example gives me a 404, which is what I would expect as a third party:
I've created a test private repo and was able to access it with my PAT (I'm running at HEAD, but identical results at v4.13.0):
My token is as follows:
|
Seems like were falling under different errors tho. scorecard/clients/gitlabrepo/client.go Lines 86 to 92 in 63fff3c
When repoducing I'm also falling in the first IF, but seems like adam is falling in the second IF. |
It's a bug on GitLab for newly created projects. The setting |
I believe we should change the logic to: "if is a private repo but has a token, then it's fine". |
Nice find! My vote is to defer until @raghavkaul is available, to confirm intent behind the original patch. |
Agreed. Meanwhile I will share some other findings: But, yeah, Raghav to take a look at cases we want to avoid in the cronjob, if it's really Project visibility: one of public, private, internal (deprecated) public + repository disabled => disabled |
Thanks @gabibguti for looking into it, good find! The reason for the original patch was to make cron errors easier to debug/easier to prune private repos from the cron. According to GitLab docs:
It's hard to run Scorecard without access that info. So I think the |
As discussed, we will consider only |
Describe the bug
scorecard
current errors out when attempting to scan private GitLab projects even though it has an access token that gives access.Reproduction steps
Steps to reproduce the behaviour:
GITLAB_AUTH_TOKEN
to a suitable token with access to the projectscorecard --repo https://gitlab.com/path/to/my/project
Expected behaviour
I expected
scorecard
would successfully scan the project and provide the results in the normal way.Additional context
Merge request #3208 added an explicitly check for private projects in https://github.com/ossf/scorecard/blob/main/clients/gitlabrepo/client.go#L65, presumably to optimise the
cron
based schedule scans. However as it is implemented as a global ban rather than acron
specific option it prevents all scanning of private projects.The text was updated successfully, but these errors were encountered: