Prevent release edit

[matejkriz]

Select Topic Area

Product Feedback

Body

Is there any way how to prevent edit of releases for those with write permissions to the repository? I can't find that permission even on Enterprise plan. Protected tags are great, but once the release exists there is no way to prevent marking the release as Latest or changing files? Would be really great if there is some possibility to require four eyes for that.

[matsmalmberg]

In addition, I would like to also restrict the capability of even creating a release. Granting a person the permissions to contribute on a repository does not automatically mean that I trust that same person to make releases.

[b00f]

I wrote to Github support about this. Here is my message:

Hi GitHub Support,

I need to make releases, including binaries, read-only within my repository, with only admins being able to modify or delete them. I've looked into existing permissions and protections but can't find a way to do this.

Is there a feature or workaround to achieve this? Your guidance would be much appreciated.

They responded:

Thanks for contacting GitHub Support!

I'm afraid permissions for editing Releases cannot be set separately from permissions to write to the repository - anybody that can edit the repo content can also edit the Releases.

Repository collaborators and people with write access to a repository can create, edit, and delete a release.

You might want to make a feature request for this to be made possible on our public discussion board so that other users can add their support to it!

I believe this will not be implemented unless many users request it.

[b00f]

@mishmanners @queenofcorgis @faridnec @Shahnawazk7944 @fury-05 @YuheshPandian @yoannchaudet

Please forgive me if I've tagged you here. Based on your valuable contributions to the GitHub discussion page, you appear to be one of the most helpful members in the community. I would like to seek your assistance and opinion. Do you believe that by making this issue go viral, GitHub would be more likely to implement it for users?

[fury-05]

@b00f Thanks for considering me helpful! The feature you want is useful taking the scenario and context, many users would be looking for similar solution.

I vouch for pinning this post to get support of users looking for similar solution, In this way we can know if users want this feature or not. Also we will get more suggestions from community.

For now I don't have Authority / Permission to Pin Post Staff will look into this 😅

[Shahnawazk7944]

Hey @b00f, thank you for your appreciation.

As far as I know, GitHub doesn't currently offer this feature. However, I was considering a workaround for this, and then I discovered that we can add GitHub Actions Workflows which can assist us in adding necessary reviews or approvals for actions such as marking a release as "Latest" or changing release files.

Suppose we create a workflow for editing releases with approvals. The workflow would be triggered by either pushing to the main branch or receiving an "edit-release" event through repository dispatch. It would then update the release asset and notes accordingly, and create a pull request for review to allow further discussion and control over the changes. Finally, we could merge the pull request to automatically update the release.

It's a long and challenging process, but if you're determined, you can give it a try. This is all based on my knowledge and research, so please feel free to correct me if I'm mistaken.

Resources

Official Github Guide on Implementing release approvals
https://docs.github.com/en/actions/managing-workflow-runs/reviewing-deployments

Video tutorial on Release Automation with GitHub Actions
https://m.youtube.com/watch?v=qy_HaIaNbkE

GitHub Actions documentation on creating releases
https://github.com/actions/create-release

List of popular GitHub Actions for release management
https://github.com/npalm/action-docs

[b00f]

@Shahnawazk7944 I got what you said, but it looks to hard to implement. Let me try... Thanks for this brilliant idea.

[bburky]

I'm glad to see that implementing restrictions on Releases is being considered by GitHub in this discussion. Branch protection → Require a pull request before merging → Require approvals works well to protect the git repository contents, but does not protect other areas of the GitHub repository.

For supply chain security, I would like to enforce that all published artifacts (Packages and Releases) are generated by Actions, and are not manually uploaded by users. I am otherwise fine with users having "write" permissions to the repository, they may edit unprotected branches, tags, issues, etc.

In addition to restricting Release write permissions, I would also request a way to restrict Packages similarly. This is technically possible today, but requires disabling "Inherit access from source repository (recommended)" which breaks all users' read access to the repository (instead of just breaking their write access which is my intent). To do this today you would have to disable this setting and manually add back all users' read access, and do this separately on each package.

Also, the contents:write and packages:write Actions permissions allow editing packages and releases. It is currently possible for a user with "write" permissions to create a new unprotected branch and then create and run a new actions workflow with these requested permissions. Today this is not a privilege escalation because the user's write role already implies these other permissions too. If you do implement a way to restrict users' Release and Package permissions, this will need to be addressed somehow. (You might be able to use the "Allowing select actions and reusable workflows to run" settings to exclude unprotected branches, but this would be very difficult.)

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[matejkriz]

The question is probably answered. Currently, there is no proper way to handle it, so it has become more of a product feedback or feature request.

[JulianStiebler]

Sadly. Were there no bad hickups with people making unwanted releases ever? Seems such an oversight.
I can PR my code and wait for days for approval but can make a release which atleast users are more likely to use, allowing to infilitrate malicious content more easy. Lets revive this discussion!

[b00f]

In term of security, this feature is really important. I hope we can have it soon.

[bburky]

Without the ability to restrict editing releases and packages, the CODEOWNERs feature provides questionable security:
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

The people you choose as code owners must have write permissions for the repository

1. Users must have "write" permission to be CODEOWNERs, which is one of the ways to force code review on all PRs.
2. However, users with "write" permission can bypass the code review process entirely and create a binary release asset or publish a package directly.

Similarly, branch protection (or rulesets) can be required for all branches with required approval steps. These features are designed to apply additional restrictions to users with "write" permissions. But release assets have no restrictions.

There also a few other repository roles that require "write" permissions. Users end up needing "write" permissions to review and approve PRs to repos. But granting users "write" permissions without the ability to restrict package and releases, means that it is not possible to enforce that all published artifacts went through code review.
https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization

Perhaps could the new "rulesets" feature be extended to packages and releases please?

[mara004]

I concur that an ability to freeze releases, and proof that release artifacts were really generated by a workflow, would be quite a valuabe security improvement for any projects that depend on external release binaries.

Unfortunately, I'm maintainer of such a project, and wondering what to do about this.
Of course, we could mirror the other repository and make our own builds, but this only shifts the problem: it still requires blind trust that releases won't be edited, except you'd have to trust us instead of the other maintainer. Inherent safety that releases can't be edited in the first place would be better.

From what I can gather, unlinke comments, releases don't even show edits, which makes this issue even more problematic.

[Maharshii5]

Hi there,

Thanks for posting this feedback! You've hit on a really important point regarding release management.

You are absolutely right currently, the ability to edit a release (including marking as latest or changing assets) is tied to having write permissions on the repository. Unlike protected branches or tags, there isn't a built-in, granular permission or a mandatory review process specifically for editing an already created release.

This is a valid need! Having a "four eyes" principle or a dedicated permission for release edits would provide much greater control and ensure the integrity of published releases, preventing accidental or unauthorized changes after they've been created.

While process and automation can help, they don't offer the same level of enforcement as a platform-level permission.

I fully support this as a product feedback request. Hopefully, this is something the GitHub team can consider for future development to give repository maintainers more fine-grained control over their release workflows.

Thanks again for raising this!

[sandstrom]

Releases now support immutability in public preview

https://github.blog/changelog/2025-08-26-releases-now-support-immutability-in-public-preview/

[mara004]

@b00f See bblanchon/pdfium-binaries#206 (comment) for a screenshot.

Also, GitHub's docs point out where to find it:
https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/preventing-changes-to-your-releases#enforcing-immutable-releases-for-your-repository

Since it's a rollout, I can't rule out it might not be available to some repos yet.

[b00f]

@sandstrom

Thanks for this update, GitHub team.

I tried to enable it, but I ran into an issue with our current release process.
We use several actions to publish binaries as release artifacts. After enabling immutable release publishing, the artifact upload step returned this error:

target_commitish cannot be changed when release is immutable

What’s important for us is the ability to upload artifacts, while preventing them from being deleted or re-uploaded.

[mara004]

@b00f First a disclaimer: Neither I am not affiliated with GitHub team, nor do I know if sandstrom is.

As for your issue: That's just how immutable releases currently are. You might need to reconsider your workflows to aggregate all artifacts first and publish them in one go.

I guess the idea might be that there is less room for confusion if releases are entirely frozen.

[b00f]

to aggregate all artifacts first and publish them in one go.

That is far from the reality. However in my case, the first artifact didn't publish. When a release consider as "published" ?

[mara004]

However in my case, the first artifact didn't publish. When a release consider as "published" ?

Indeed, our upstream ran into the same issue.
I think, if you're using the ncipollo release action, you may need to update it and set immutableCreate to true.

It was also mentioned that one can keep attaching artifacts while the release is draft.