Registering a project last week, I stopped partway through the "log in with
GitHub" flow because the consent screen asked me to authorize a personal
account rather than an OpenSSF-owned application. I completed the
registration with the email/password signup instead, which worked fine.
Having looked into both points since, neither is a defect and the program is
plainly legitimate — but both seem worth raising, because the consent screen is
where a security-conscious registrant is most likely to stop.
1. The OAuth app is registered to an individual rather than the ossf org
I understand the history — the badge began as the CII Best Practices Badge,
built by the same person, before OpenSSF existed. But the effect today is that
the authorization boundary is one individual's GitHub account, while the
branding, the domain, and the repository (ossf/best-practices-badge) are all
OpenSSF. A registrant comparing the consent screen against the site has no easy
way to reconcile those, and "the app asking for access isn't owned by the
organization it claims to represent" is precisely the pattern security guidance
tells people to treat with suspicion.
Would transferring the OAuth app to the ossf organization be feasible?
2. read:org is broader than the feature may still require
From config/initializers/omniauth.rb:
provider :github, ENV.fetch('GITHUB_KEY', nil), ENV.fetch('GITHUB_SECRET', nil),
scope: 'user:email, read:org'Both scopes are read-only, and I gather read:org is what lets the site
auto-verify that a user controls the project they are registering. That is a
genuinely useful feature.
The difficulty is that read:org is not scoped to the organization being
registered — it grants visibility into every organization the authorizing
account belongs to. For maintainers whose GitHub account also carries client or
employer org membership, that is a far larger grant than registering one
open-source project warrants, and it is likely to stop some of them at the
consent screen, as it stopped me.
Since the local-account path already supports registering and editing a project
without any GitHub grant at all, the auto-verification appears to be a
convenience rather than a requirement. Would it be possible either to narrow the
scope, or to request read:org only at the point where a user actually wants
control detection, rather than at first sign-in?
Neither point is urgent, and the email signup is a perfectly good workaround —
I used it and the registration went through without trouble. Mostly I wanted to
flag that the sign-in screen is a place where the more security-conscious
visitors may bail, which seems like an unfortunate filter for a program whose
purpose is encouraging exactly that mindset.
Registering a project last week, I stopped partway through the "log in with
GitHub" flow because the consent screen asked me to authorize a personal
account rather than an OpenSSF-owned application. I completed the
registration with the email/password signup instead, which worked fine.
Having looked into both points since, neither is a defect and the program is
plainly legitimate — but both seem worth raising, because the consent screen is
where a security-conscious registrant is most likely to stop.
1. The OAuth app is registered to an individual rather than the
ossforgI understand the history — the badge began as the CII Best Practices Badge,
built by the same person, before OpenSSF existed. But the effect today is that
the authorization boundary is one individual's GitHub account, while the
branding, the domain, and the repository (
ossf/best-practices-badge) are allOpenSSF. A registrant comparing the consent screen against the site has no easy
way to reconcile those, and "the app asking for access isn't owned by the
organization it claims to represent" is precisely the pattern security guidance
tells people to treat with suspicion.
Would transferring the OAuth app to the
ossforganization be feasible?2.
read:orgis broader than the feature may still requireFrom
config/initializers/omniauth.rb:Both scopes are read-only, and I gather
read:orgis what lets the siteauto-verify that a user controls the project they are registering. That is a
genuinely useful feature.
The difficulty is that
read:orgis not scoped to the organization beingregistered — it grants visibility into every organization the authorizing
account belongs to. For maintainers whose GitHub account also carries client or
employer org membership, that is a far larger grant than registering one
open-source project warrants, and it is likely to stop some of them at the
consent screen, as it stopped me.
Since the local-account path already supports registering and editing a project
without any GitHub grant at all, the auto-verification appears to be a
convenience rather than a requirement. Would it be possible either to narrow the
scope, or to request
read:orgonly at the point where a user actually wantscontrol detection, rather than at first sign-in?
Neither point is urgent, and the email signup is a perfectly good workaround —
I used it and the registration went through without trouble. Mostly I wanted to
flag that the sign-in screen is a place where the more security-conscious
visitors may bail, which seems like an unfortunate filter for a program whose
purpose is encouraging exactly that mindset.