Just tested this on a test repo, and unfortunately it doesn't work the way I would like it to.

The ruleset:

The test when not using LFS correctly blocks this 25MB file due to extension and size.

But the test when using LFS still blocks it due to extension:

testrepo> git push
Uploading LFS objects: 100% (1/1), 24 MB | 3.0 MB/s, done.
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 2 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 546 bytes | 42.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: error: GH013: Repository rule violations found for refs/heads/master.
remote: Review all repository rules at http://github.com/BLA/testrepo/rules?ref=refs%2Fheads%2Fmaster
remote:
remote: - GITHUB PUSH PROTECTION
remote:   —————————————————————————————————————————
remote:     Resolve the following violations before pushing again
remote:
remote:     - Files cannot include restricted file extensions.
remote:       Found 1 violation:
remote:
remote:       testlargeapks/foo.apk
remote:
To github.com:BLA/testrepo.git
 ! [remote rejected] master -> master (push declined due to repository rule violations)
error: failed to push some refs to 'github.com:BLA/testrepo.git'

We evaluate each rule independently, so pushes cannot contain any *.apk or any file over 5MB. and because the apk hit the rule it will get blocked regardless of LFS.

Can a rule be overridden by an admin on a case by case basis to push an exception to the rule?

Not today, but it sure is something we are thinking a lot about as these rules do introduce new points of friction.

We evaluate each rule independently, so pushes cannot contain any *.apk or any file over 5MB. and because the apk hit the rule it will get blocked regardless of LFS.

In this case, sadly this system is not powerful enough right now. Please consider more complex rules that would AND instead of OR.

Thanks for the feedback!

Thanks, that's a good note.

Comma is a valid file name (and therefore extension) character, please don't block it outright.

Thanks.

That API is not yet ready, but should be available quite soon.

But we got it in advance 😎
integrations/terraform-provider-github#2235

The REST and GraphQL endpoints are available for push rules.

Thanks for the suggestion. How common would the removal be for folks that don't have bypass? Would you see that as a daily occurrence, weekly?

Once per repository, really, just to clean up the instances where we already such a file committed.

Where do you see that it's only available for private repos?

Rulesets are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, and GitHub Enterprise Cloud. For more information, see "GitHub’s plans."

Push rulesets are available for the GitHub Team plan in internal and private repositories, and forks of repositories that have push rulesets enabled.

@archon810
https://github.blog/changelog/2024-04-18-push-rules-public-beta/

Push rules are now available for private and internal repositories for GitHub Teams, and across organizations for GitHub Enterprise Cloud.

Public repos don't even have a menu item for push rulesets:

Oh, right, push rulesets specifically, not rulesets in general. Disregard me!

Hopefully, they'll bring them to public repos after the beta period once it hits GA.

Great question.

The limitation for public repo is driven by the behavior with forks. As push rules are designed to protect a repo and it's fork there are some concerns we have about how this would be received in the open source community. So we opted away from it for now. The public beta is a good way to listen to the feedback if we need to change that stance.

I think this feature would be good for open-source repos as well.

It would help against security escalation and downstream attacks by locking down certain files and filetypes.

😬 Whoops. Thats should only be on the new push rule beta page. We'll get that fixed up soon.

If you want to provide feedback on the existing branch and tag rules, feel free to jump into this discussion post.

Hey @siMobin,

Push rules are available for private and internal repos for GitHub Team and across organizations for GitHub Enterprise.

@chrisxaustin Are you aware of this GitHub feature? It might not do exactly what you're after, but it's actually a more powerful way of protection in my reading. If your workflows call just a single command or script from your clone on the runner, your repository is vulnerable to external code execution, because an actor can raise a PR with the script/build script changed and that will execute even without touching the workflow files.

We were also getting this with Renovate, I think that's probably the same issue, in case anyone comes along.

@patrick-knight +1, we found evaluate mode restricting pushes of blobs during our automation that uploads blobs during PR creation.

Following up on the known restrictions on trees and blobs (especially during evaluate mode), @patrick-knight do we have a timeline for when a fix will be provided for this?

Thanks!

We have an agree upon plan internally, roughly looking at a couple weeks.

We rolled out a fix to resolve this behavior yesterday. Can you re-enable the rules causing this and let me if you are still seeing the same error(s)? Thanks!

Great question @rcmarques3.

There's a lot of threads to pull here, but at the moment we don't have plans to move those into push rules. There are scenarios for large monorepos where keeping some of these behaviors as branch level rules continues to make sense.

Of course having this as an option in the push rules doesn't mean it should be removed from branch rules :) because different use cases do need different policies.
Just wanted to bring this to your attention since IIRC the branch rulesets did suffer some small adjustments to their behavior in beta regarding signatures, but never really fixed the problem for us.
Push rulesets seem like the perfect lifecycle spot to enforce this validation - and I did suggest something along those lines at the time, but no such hook existed back then.
I understand if there's no bandwidth to address everything, but do hope this manages to get implemented at some point. Thanks!

We do have a know issue with the usage of both the /git/trees and /git/blobs API endpoints and rules. Do you know if those are in use in your scenario?

heya thanks for reply, yes, the github app is using these endpoints. is there any plan to support by passing the github app, we use it in quite a few scenarios. hopefully the new feature can support it as well?

We rolled out a fix to resolve this behavior yesterday. Can you re-enable the rules causing this and let me if you are still seeing the same error(s)? Thanks!

Thanks @DrNeil great suggestion. We're taking a look at data across the beta on how we best help with scenarios like this as well as "bundling" common file and path types for future itterations.

Hey @bodgit is there use of the trees or blobs endpoints in that tool? Based on the behavior of blocking on evaluate it seems like it might be the same behavior we are working on.

I can't easily tell, but the error message I get is something like:

Error: release-please failed: Error adding to tree: <commit sha>

So based on the presence of "tree", perhaps that is the case?

We rolled out a fix to resolve this behavior yesterday. Can you re-enable the rules causing this and let me if you are still seeing the same error(s)? Thanks!

Sorry, Ive only just seen your reply.

I've just re-enabled the ruleset and tested and I can confirm it now seems to work as expected; the ruleset blocks writes unless they are authored by the release-please workflow via our GitHub App.

Thanks for the update!

I can also imagine it complicating contributing by others.

That drove our initial work to support just private and internal repos to limit the scope of impact there.

You can 100% apply push and branch/tag rules to all repos in an org when on GitHub enterprise today, with the exception of Enterprise Server where push rules are not currently availible.

We are targeting a GA sometime between June and August assuming everything goes to plan.

https://github.com/orgs/community/discussions/118843#discussioncomment-9182731

Hey @figi44 thanks for the patience while I replied here.

One thing to clarify is that push rules are not applicable to any public repos. There is some work we need to complete in the beta to ensure that message is consistent in the documentation as well as the UI, as there are a few area where that distinction is not clear.

As far as a future state on full public repos support, I'd be interested to understand your "security" perspective on public repos and how you'd like the interaction with contributors on your public repos? So for any files/path you'd want a push rule for is there an expectation that a contribution for those could come from a fork or are they "sensitive" enough you'd generally never accept that PR

@patrick-knight any update on the most recent comment above? Trying to merge from branches with previously bypassed changes seems to be breaking the intended ruleset functionality, and at least for us, is a blocker for implementing this in a more formal manner.

👀 thanks for the reminder to follow up here.

This is a bug we are working to resolve. So when a commit is cherry picked or merged, associated blobs included in these commits are still considered in push rule evaluation, even when unchanged. Which as you point out makes it hard to fully adopt push rules. It's on the short list of things we are resolving before making push rules generally available.

@patrick-knight do we happen to have a date for when GA is expected? I didn't see a date on the Github Public Roadmap after a cursory search. Knowing this would help us with project prioritization in this space. Thanks!

We're targeting August. Don't have an exact date yet, but likely mid-month.

@electrofelix and @technologik I wanted to follow up on this thread as we rolled out some changes recently that should alleviate the concerns. Let me know one way or the other if you are seeing issues.

Would an allowlist glob for large files be a reasonable feature request? @patrick-knight

Its depends what you mean by that? Is there a specific example you are thinking about?

For instance, in one of our repos, we'd like to have strict file size limits in general, but we have a couple really massive javascript lock files that are somewhat frequently updated. We'd like for the push rule to not reject updates to just those large lock files.

@patrick-knight what did you think of this feature request?

For that specific case delegated bypass which is a beta for push rules can help there, as it gives a way for a manually gated check.

There's some deeper nuance we need to explore internally about how rules can be bypassed for paths.

I saw the post from you above this one, but will consolidate my reply here.

Agreed, we need to drive clarity in the UI to make sure you rule works right the first time without manually testing. We're thinking about ways to do that well inclusive of links to docs.

As far as the specifics behavior here. my/folder/** will only block file paths directly underneath it (i.e. my/folder/foo.bar) but not nested files (i.e. my/folder/foo/bar.baz). To accomplish that **/* is the fnmatch pattern needed, so my/folder/**/* will recursively matches all file paths underneath my/folder.

At the moment it's an experience for push rules and secret scanning bypass, which were good areas for us to start with. Because blocking pushes has a lot of friction and we wanted to be mindful of that. We also know there is a lot of utility beyond those two use cases, but want to learn from those area first and then we'll see where we go next.

Push rules are designed to only look for changes to a files based on the git object ID. There are a few scenarios I mentioned here where that is not always true, but we are making head way on resolving that behavior.

The logic and enforcement for push rules happen before any merge evaluations occur. That said we've gotten feedback on that behavior for branch rules, but have not prioritized any work around that.

CODEOWNERS with branch&tag rulesets allows you to ensure certain paths have reviewers.

You can achieve a lot of that dsl style customization today with with GitHub actions. By requiring a status check in branch and tag rulesets there is a myriad of decisions you can make and actions workflows are stored as YAML.

especially considering that all GitHub users are developers

Just wanted to mention there are plenty of folks who use GitHub on a daily basis that have range of skills and backgrounds that may not consider themselves developers just yet.

Thank you for suggesting the branch&tag ruleset! Unfortunately, it doesn't quite work for us (unless I'm missing something), since the only way that I see how to block CODEOWNERS-files is to require a pull request for all commits, and then turn on "require review from code owners". We do not want to require a pull request for commits touching non-CODEOWNERS files.

For the same reason, I think the GitHub actions approach does not work for us (since we want to allow straight pushes to main for most files).

I get that this might be a niche use case :). Which is why we'd love more flexibility in the rules!