GitLab Projects in Subgroups

[adam-moss]

Hi,

Could I please ask how one would retrieve the scorecard data for projects that exist within GitLab subgroups?

Example:

For project https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage I believe the API URL would be https://api.securityscorecards.dev/projects/gitlab.com/gitlab-org/ruby/gems/gitlab-triage/badge however this results in

{"code":404,"message":"path /projects/gitlab.com/gitlab-org/ruby/gems/gitlab-triage/badge was not found"}

Should this instead return the "invalid repository path" badge like it would for https://api.securityscorecards.dev/projects/gitlab.com/adam-moss/dotfiles/badge?

If I manually use shields.io directly https://img.shields.io/ossf-scorecard/gitlab.com/gitlab-org/ruby/gems/gitlab-triage?label=openssf scorecard&style=flat it seems to work?

Thanks

[spencerschrock]

I remember thinking GitLab subgroups would break something, I just wasn't sure where.

We don't have a GitHub Action equivalent for GitLab which would upload scores, but it should be possible for subprojects to be scanned in our weekly cron and accessible from the API.

[adam-moss]

We don't have a GitHub Action equivalent for GitLab which would upload scores, but it should be possible for subprojects to be scanned in our weekly cron and accessible from the API.

I'd be happy to work on a gitlab equivalent.im currently looking at embedding scorecard in ~11k gitlab repos 👍

[spencerschrock]

Fixing the endpoints to support subprojects from our weekly cron is probably the quickest win here.

I'd be happy to work on a gitlab equivalent.im currently looking at embedding scorecard in ~11k gitlab repos 👍

That would be a pretty large undertaking if the goal is to have the badge API endpoint show the score produced by the GitLab CI. On the GitHub action side, we make use of Sigstore provenance to check that the GitHub action which produces the score is "clean".

scorecard-webapp/app/server/post_results.go

Lines 183 to 184 in f28966e

	func getAndVerifyWorkflowContent(ctx context.Context,
	scorecardResult *models.VerifiedScorecardResult, info certInfo,

GitLab seemingly supports cosign (https://docs.gitlab.com/ee/ci/yaml/signing_examples.html), but parsing the workflow would be wildly different.

[spencerschrock]

Had a few minutes to look at this today. So the API spec we use, OpenAPI v2 (and even v3) doesn't (and wont) support this sort of in-path wildcard. So our route we define is doomed for these gitlab subgroups:

scorecard-webapp/openapi.yaml

Lines 78 to 94 in f1b48c0

	/projects/{platform}/{org}/{repo}:
	parameters:
	- in: path
	name: platform
	type: string
	required: true
	description: VCS platform. eg. github.com
	- in: path
	name: org
	type: string
	required: true
	description: Name of the owner/organization of the repository
	- in: path
	name: repo
	type: string
	required: true
	description: Name of the repository

Out of curiosity, the upcoming Go 1.22 Serve Mux would handle it (example from the proposal):

/b/{bucket}/o/{objectname...}

Avoiding a re-write, I assume we would want to standup another route, which supports query-based parameter passing instead (which would potentially help with #432 as well).

[jamietanna]

FYI I've just been looking at adding support for publishing results from GitLab CI for a few of my projects, and have just hit this issue with my test repo.

There's some more details in my thread in the OpenSSF Slack but would be up for helping add support if possible!

[spencerschrock]

It sounds like we'd need a similar parameter-based path for both GET and POST routes.

but would be up for helping add support if possible

Our API endpoints are defined here, and we follow https://swagger.io/specification/v2/

A first step would be figuring out what we want the route to be, defining it and parameters, then hooking it up to the same implementation the existing route uses.