ossf / scorecard

OpenSSF Scorecard - Security health metrics for Open Source
https://scorecard.dev
Apache License 2.0
4.61k stars 500 forks source link

:bug: Add a workaround for organisations in GitLab #4415

Open verm opened 4 days ago

verm commented 4 days ago

This fixes Contributors.

Currently organisations are an experimental features in GitLab this change makes it use the users email domain as a pseudo organisation. The domains are anonymised as these are printed as part of the report and shouldn't be exposed.

It's uncertain if the uptake in organisation will be large considering GitLab users are used to using groups for this purpose.

What kind of change does this PR introduce?

Fixes a bug where Contributors were always set to 0 I did not see an open issue for this.

What is the current behavior?

Contributors will always be 0.

What is the new behavior (if this is a feature change)?**

Which issue(s) this PR fixes

NONE

Special notes for your reviewer

What I've done here is used the email domains as a pseudo orginisation and anonymomised it using the slice index as gitlab-N. This lets Contributors give somewhat useful data and in the future when Orginisation is no longer experimental we'll be able to remove this. I found this to be the least invasive method of handling the situation.

Does this PR introduce a user-facing change?

NONE

Fix Contributors to return somewhat useful data for GitLab.
verm commented 3 days ago

Email domains aren't indicative of an organization that a contributor belongs to. Is there any other API feature we can use to get contributor organizations?

Orginisations in GitLab are an experimental feature with no interface other than the API to get to it. There is no other unique identifier. I agree that it's not ideal nore a good indicator the only other option is to remove it completely but this at least gives us something that may be useful.

I did it this way as it seemed the least invasive to support this until Orginisation is settled as a public feature.

raghavkaul commented 3 days ago

We use the Users API to get the Organization, not the Organizations API. As I understand it, it's just the API that's experimental, and Organizations are part of GitLab to stay.

verm commented 3 days ago

We use the Users API to get the Organization, not the Organizations API. As I understand it, it's just the API that's experimental, and Organizations are part of GitLab to stay.

Yes they are here to stay the way GitLab wants you to set them up is using groups which don't exist in GitHub. If you go to GitLab docs they just want you to setup groups -- this is not what the API being used is it's an entirely new concept for Orginizations similar to how GitHub has them.

The concept of 'orginization' does not exist in GitLab yet it is only exposed via an API and it's all experimental.

This is why in nearly every case using this API right now is going to return an empty string. The web UI isn't even enabled for it:

To summerise: The only way you're going to get a user with an orgnization is if you enable experimental flags and use the API directly. It won't show up anywhere on the web UI nore can you edit it. You can also see here that all of the feature flags are disabled by default for orginization: