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

Stale kusari-oss references: signing identities, container image name, package metadata

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
55/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, github-actions, python
Domain
documentation, release

Research direction

Start with packaging/README.md, which states the identity rule, and .github/workflows/release.yml, which sets the GHCR image name. The section 4 items in docs/install/from-source.md (line 11 clone URL, lines 25 and 35 control count, checked against darnit list) are the most self-contained place to start. Sections 1 and 2 need the maintainers' answer first. Done means the stale references are updated where the issue asks, the Homebrew tap and DEFAULT_TRUSTED_PUBLISHERS stay unchanged, and the git grep count is re-run.

Written by the indexing model from the issue text.

Description

needs triage

Summary

171 references to kusari-oss remain in 35 files under docs/, packaging/, README.md, the pyproject.toml files and the workflows. Most are links that GitHub redirects. Some ae not harmless, and with 0.2.0 coming it seemed worth sorting them.

packaging/README.md already states the rule: "Sigstore certificate identities do not redirect", releases cut after the move resolve against darnitdevorg/darnit, and two things stay under the old org on purpose (the Homebrew tap and the kusari-oss entry in DEFAULT_TRUSTED_PUBLISHERS).

1. Signing identities in user-facing verification commands

These tell users to verify against the old identity:

  • docs/install/README.md:47, :53
  • docs/install/binary.md:43
  • docs/install/container.md:49, :74
  • docs/install/pypi.md:76 (fixed by #530, still open)
  • packaging/RECOVERY.md:149, :155, :242
  • packaging/container/README.md:65

A user who follows them for a release signed under darnitdevorg/darnit gets a verification failure on a genuine artifact.

Question: the examples all use v0.1.0. If 0.1.0 was published before the move, the old identity is correct for that version. Should the docs move to the new identity with a newer example version, or state which identity applies to which versions?

2. Container image name

release.yml pushes to ghcr.io/${{ github.repository_owner }}/darnit, which is now ghcr.io/darnitdevorg/darnit. docs/install/container.md, packaging/container/README.md and packaging/RECOVERY.md use ghcr.io/kusari-oss/darnit throughout (pull, run, cosign verify, cosign download attestation).

I do not think GHCR redirects image names between organizations, so these would not find new releases. I have not tested it.

3. Package metadata

pyproject.toml (root and packages/*) set Homepage, Repository and Issues to https://github.com/kusari-oss/darnit. They redirect, but they are what PyPI will show for 0.2.0.

4. docs/install/from-source.md

  • Line 11 clones https://github.com/kusari-oss/darnit (redirects).
  • Lines 25 and 35 say the baseline has 62 controls. darnit list reports 66.

5. Plain links

Release download URLs, issue links and the like, across the install docs, README.md, docs/SECURITY_GUIDE.md and docs/getting-started/. They redirect. Low priority.

Deliberate, not to change

  • kusari-oss/homebrew-tap and brew tap kusari-oss/tap, including the three references in release-smoke.yml.
  • The kusari-oss entry in DEFAULT_TRUSTED_PUBLISHERS.

Suggested order

1, 2 and 3 before 0.2.0 is published. 4 and 5 whenever.

I can send PRs for any of these once the question in section 1 is answered. Context: this is the follow-up I mentioned in #530.

Counted on main at 24a4fed with git grep -c kusari-oss -- docs/ packaging/ README.md pyproject.toml 'packages/*/pyproject.toml' '.github/workflows/*.yml'.

Drafted with Claude; reviewed and filed by me.

Dominant language
Python
Stars
22
Forks
27
Avg merge
2d 28m
Merged PRs (30d)
40

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.