Artifact attestations are no longer found after transferring a repository to an organization

[kroxiksut]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Other

Discussion Details

After I transferred a public repository from my personal account to an organization, the attestations API stopped finding the attestations that were created before the transfer, and gh release verify fails for an immutable release. Is this expected?

Setup (public test repositories, kept for reproduction):

• kroxiksut/pchi-test (repository ID 1429109739, owner ID 2264172) published the immutable release v0.1.0 on 2026-10-22. Its asset has a release attestation and build provenance from actions/attest-build-provenance.
• I renamed it to kroxiksut/pchi-test-renamed and then transferred it to the organization pchi-test-org (2026-10-22, about 06:08 UTC). The repository ID did not change; the owner ID changed to 346117935.

Observed. I rechecked about 40 minutes, about 4 hours and about 19 hours after the transfer and got the same results each time:

Request	Result
GET /repos/pchi-test-org/pchi-test-renamed/attestations/sha256:8fcda58d824b4fea8f98e036083f398f497941af4b8c15de5dac02dd900576fd	404
GET /repositories/1429109739/attestations/sha256:8fcda58d…	404
GET /orgs/pchi-test-org/attestations/sha256:8fcda58d…	404
GET /users/kroxiksut/attestations/sha256:8fcda58d…	200, 2 attestations, repository_id: 1429109739
GET /repos/pchi-test-org/pchi-test-renamed/attestations/sha1:6ee0f9f53e5a296bd19904188d055608f32ffd82 (tag commit)	404
gh release verify v0.1.0 -R pchi-test-org/pchi-test-renamed (gh 2.103.0)	fails: no attestations for tag v0.1.0

The release still reports immutable: true. As a control, a fork in my account finds its own attestations normally. Bundles saved before the transfer still verify offline, so the signatures are fine. The lookup seems to stay keyed to the previous owner.

Questions and suggestions

1. Is it intended that attestations stay with the account that owned the repository when they were created? The certificates already carry the repository ID, so I would expect GET /repositories/{id}/attestations/... and GET /repos/{owner}/{repo}/attestations/... to find them under any later owner, without moving any data.
2. If the current behaviour is intended, could it be documented? The most useful places seem to be the list of what a transfer changes ("Transferring a repository") and the artifact attestation and immutable release pages, next to gh release verify.
3. Is there a supported way to make attestations of a transferred repository visible again, for example a migration on transfer or an admin action to re-associate them? Until then, is downloading the bundles (gh attestation download) and verifying offline with --bundle the recommended workaround?

Possibly the same case: Aquaticats/Monochromatic#1015.

[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. ⭐