Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

OSPS-AC-01.01 is always ERROR on a user-owned repository (owner-type detection, follow-up to #467)

Open
  • Is something wrong?
#580 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
github, python
Domain
cli, security

Research direction

Start with the OSPS-AC-01.01 control definition (its TOML) and the gh_api handler path that calls /orgs/<owner> and /user, then reproduce with darnit audit -f openssf-baseline --include OSPS-AC-01.01 on a user-owned repository. Find where owner.type from /repos/{owner}/{repo} is already fetched and how it could reach this control. The issue leaves the resulting status for user-owned repos as a design decision, so settle that with the maintainers first. Done means a user-owned owner skips the org call and gives a clear needs-confirmation result, and a missing read:user scope is reported as such.

Written by the indexing model from the issue text.

Description

needs triage

Summary

On a repository owned by a user account, OSPS-AC-01.01 is always ERROR, and the message reads like a failed API call:

$ darnit audit -f openssf-baseline --include OSPS-AC-01.01 <checkout of Marc-cn/SSI>
WARNING: OSPS-AC-01.01: gh_api handler could not complete (error_class=unavailable): Platform API call /orgs/Marc-cn could not be measured (unavailable): HTTP 404
WARNING: OSPS-AC-01.01: gh_api handler could not complete (error_class=evaluation): Could not evaluate expr over the response from /user: CEL evaluation failed: ("no such member in mapping: 'two_factor_authentication'", ...
Total: 1 | Pass: 0 | Fail: 0 | Warn: 0 | N/A: 0 | Error: 1 | Pending: 0
  ! OSPS-AC-01.01: ERROR [unavailable] - Platform API call /orgs/Marc-cn could not be measured (unavailable): HTTP 404

gh api /repos/Marc-cn/SSI --jq .owner.type returns User.

What is by design

The control's TOML says "404 (a user, not an org) and 401/403 are ERROR, never FAIL", and the /user step is evidence only, so that the auditor's own 2FA can never produce a PASS. That is the fix for #467 and it should stay.

What is missing

This is the follow-up #467 describes: PR #271 "promised a follow-up issue for owner-type detection; none was filed", and #467's suggested direction includes "Gate the /user fallback on the owner being a User account (owner.type from /repos/{owner}/{repo} is already fetched elsewhere in the audit)".

Without it, on a user-owned repository:

  1. The org step asks /orgs/<user>, which can only 404. The result is ERROR with a message about an unreachable platform. Nothing says "this owner is a user, so there is no organization setting to check".
  2. The help text says "a person confirms the control for a user-owned repository", but the audit result does not lead there. An agent reading the result (Claude Code, in my case) reported it as an API error and suggested confirming MFA by hand, which is the right conclusion reached by guessing.
  3. With a default gh auth login, the /user step errors as well, because the token has no read:user scope and the field is absent. So even the evidence is not recorded unless the user knows to run gh auth refresh -s read:user.

Suggested direction

  • Detect the owner type once (from /repos/{owner}/{repo}) and make it available to the control.
  • For a User owner: do not call /orgs/<owner>. Conclude a "needs confirmation by a person" result (WARN, or whatever fits the result-authority contract), with the /user response as evidence when the field is visible, and a message that says the repository is user-owned.
  • For an Organization owner: unchanged.
  • When /user has no two_factor_authentication field, say that the read:user scope is missing instead of reporting a CEL evaluation error.

Which status a user-owned repository should get is a design decision for this control, so I have not sent a PR.

Environment

darnit main at 24a4fed, RHEL 10.2, gh 2.102.0 logged in with scopes gist, read:org, repo, workflow.

Drafted with Claude; reviewed and filed by me.

Dominant language
Python
Stars
22
Forks
27
Avg merge
1d 20h
Merged PRs (30d)
39

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from darnitdevorg/darnit

All issues in darnitdevorg/darnit

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.