Git HTTPS Protocol - New Branch Creation Rule Not Blocking Push from CLI but Works via UI

[ysicing]

Description:

When using the Git HTTPS protocol, I have set a rule to prohibit the creation of new branches. After cloning the repository locally and checking out a new branch, I am able to push the new branch without any restrictions from the command line. However, the UI correctly enforces this rule. Additionally, key scanning exhibits similar behavior; enabling or disabling it has no effect. This inconsistency is affecting our workflow.

Steps to Reproduce:

• Set up a rule to prohibit new branch creation on the repository.
• Clone the repository locally using the HTTPS protocol.
• Create a new branch locally.
• Push the new branch to the remote repository via the command line.

Expected Behavior:

The push operation should be blocked due to the rule prohibiting the creation of new branches, consistently across both CLI and UI.

[johannesHarness]

Hey @ysicing, thanks your for reporting the above findings.

Branch rules bypassed by user via CLI

Some context on the difference in behavior you are seeing in the UI vs CLI:

• The UI is providing a two step process where it first checks whether any rules are blocking the action and if the user can bypass them. If there's no rules blocking the action, the branch is created. However, if there's a rule blocking it and the user can bypass it, the UI then first gets confirmation from the user before making a call to create the branch and requesting to bypass the rules. That is to ensure the user is aware that they are bypassing a rule in case they have permission to do so.
• On the CLI we are bound by git capabilities - when a user with permission to bypass the rules is making a call it will automatically assume the call is trying to bypass the rules (there's no confirmation step) - This is similar to Github. We are however showing a warning message indicating that a rule has been bypassed:

As for why you were able to bypass the rules without having the explicit permission to bypass it:
It looks to me like you were running the operation as system admin. In the initial version the system admin was always allowed to bypass rules.
We've evaluated the current behavior and change it in this commit such that system admins aren't allowed to bypass rules unless the bypass configuration of the rule allows it. This will be part of the next release.

Secret scanning not enabled

I'm unable to reproduce the scenario you are describing - the secret is blocked both via UI and via CLI.
Can you try with a secret that's known to be detected and let me know if it works (e.g. example from https://github.com/gitleaks/gitleaks: AWS_ACCESS_KEY="AKIAIOSFODNN7EXAMPLE").
If that works and the secret you expect to be blocked still isn't blocked, can you try detecting the secret with gitleaks?

Note: The feature only blocks secrets that are part of the changes of the push - existing untouched secrets are not detected. For more details see the documentation: https://docs.gitness.com/repositories/guides/secret-scanning

[ysicing]

I'll try again.