Lack of independently verifiable and tamper evident release decisions outside the platform

[88nonog-dev]

from a

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[johnwills72]

That’s a really insightful point having release decisions as standalone, tamper-evident artifacts would definitely strengthen trust, especially for audits and offline validation. It would also reduce dependency on a single platform as the source of truth. In a similar way, systems like haha pkr game download highlight how important it is to have reliable and verifiable processes built into the core experience for better transparency and security.

[davex-ai]

hey @88nonog-dev

GitHub's strategic direction focuses on Artifact Attestations and Trusted Publishing to address the gap between platform-bound records and independent verifiability. This shift moves the source of truth from platform logs to cryptographically signed metadata that can travel with the artifact itself. [1, 2]

Independent Verifiability vs. Platform Records

GitHub views the transition toward "verifiable objects" through a few key lenses:

• Cryptographic Binding (Artifact Attestations): Instead of relying on a GitHub API call to see if a build passed, GitHub now uses Sigstore-based attestations. These are signed records that cryptographically bind an artifact to its source repository and the specific build workflow that produced it. These can be verified offline using the GitHub CLI (gh) without needing to access live platform logs.
• SLSA Compliance: To meet SLSA Build Level 3 requirements, GitHub ensures that the build provenance is non-falsifiable and exists as a standalone record. This allows auditors to verify the integrity and authenticity of software distribution independently of the GitHub UI.
• Policy-Driven Governance: Recent improvements allow for custom attestations beyond simple build provenance (e.g., attested SBOMs). This addresses your point about "cross-system validation" by allowing the CLI to evaluate and output all policies it checked during a verification process. [1, 3, 4, 5, 6]

The "Decision as an Artifact"

While current features focus heavily on how an artifact was built (provenance), GitHub is moving toward Release Attestations to ensure the decision to release was authentic. [2]

• Verifiable Signatures: Maintainers can provide signatures for release artifacts that confirm they are exactly what was intended for that specific release.
• OIDC-Based Identity: By moving away from static tokens to OIDC-based Trusted Publishing, GitHub creates a verifiable link between the platform identity and the target registry (npm, PyPI, etc.), reducing the need to trust the platform's internal state. [2, 6, 7, 8]

Current Gaps & Your Approach

GitHub acknowledges that purely platform-bound records are a security risk. While your approach of treating the release decision itself as a standalone artifact aligns with the broader industry move toward Zero Trust Supply Chains, the platform's current primary implementation of this is through Sigstore signatures and SLSA provenance. [3, 4, 9]
Are you building your verifiable decision artifact using a standard like in-toto, or are you designing a custom schema to capture the specific "logic" behind the release (e.g., specific human approvals)?

Pls mark as accepted answer if this helps