As you found out, you will need to enable the required status checks via the Update Branch Protection API Endpoint first.
You will have to extract the current configuration first with the Get Branch Protection API Endpoint.
... View more
Bonjour! (ou Bonsoir?)
There is two parts to a pre-receive hook: The script itself which will process every commit, and in some cases, a custom environment that contains the libraries and utilities necessary for the hook to run (like the python package, for instance). You can learn more about pre-receive hooks environments in our GitHub Enterprise documentation.
The credentials are still present in the git history on the client side, and the commits in question will have to be removed from the git history. Let's not forget that credential security is not about "if" but about "when". Attackers need to be lucky only once while defenders need to be lucky every time. Having a detection and remediation framework can be used for more than only the developers' work ;)
If you really want to credentials to be leaked, then pre-commits are really the way to go. They can be rolled out quickly with your configuration management tool of choice.
We do have a hard timeout which cannot be mofidied to ensure that pages are displayed without errors, and for internal workers to not be tied by a single push. For large pushes (raw SQL data, or minified JS for instance, but it can be anything), the execution time of a non-optimised script can be in the order of minutes.
Don't hesitate to reach out at https://support.enterprise.github.com/hc/en-us if you have further questions! Our team would be happy to assist.
... View more
We recommend fast storage for backups to ensure they complete quickly, so Glacier is out of the question unless you use it to store older snapshots. You can find more about our requirements in the GitHub Enterprise Backup Utilities repository.
If you have specific questions which are not answered there, you can also open a ticket with GitHub Enterprise support.
... View more
Pre-receive hooks at glance
Git hooks are custom scripts that are fired during various Git operations. Some, like pre-commit hooks, are executed on your workstation before your changes are committed to the repository history. Some are executed server-side, like post-receive hooks that can be used to trigger updates to external services. Pre-receive hooks are executed on the server after the changes are received but before they are accepted. It is generally used to accept or reject Git commits based on specific criteria, which we will explore right now.
When to use Pre-Receive hooks
Generally, pre-receive hooks can be anything that can run server side and return an exit code of 0–when the commit is valid, and a non-zero exit code–to reject the commit. As the script will run for every single push, it needs to be lightweight and run quickly. This makes pre-receive hooks more suited for certain tasks than others.
For instance, pre-receive hooks are great to handle a commit's metadata, and as such work well for tasks such as:
Enforce specific commit messages guidelines.
Check if the author is using their corporate email.
Block specific file extensions.
Or even Restrict pushes by IP range!
They do not work so well for uses that expect a "working copy" of the Git repository where files are accessible directly. This applies for tasks such as credentials scanning or coding style checks. For the former, pre-commit hooks are recommended, as they will make sure that compromised credentials never make it to the Git history. For the latter, status checks are preferred. This will allow a submitter to push additional commits to make their code compliant, without imposing additional constraints on intermediate commits or work in progress.
Similarly, as execution speed is key, any form of validation that relies on API requests or long computations would work better as a status check.
Implement a pre-receive hook
First you will need to write a script. Pre-receive hooks process STDIN output–the Git push–so the script will be contained in while loop. For instance, using bash:
while read OLDREV NEWREV REFNAME ; do
Once armed with your script, you need to make sure you can run it on your GitHub Enterprise instance. Pre-receive hooks environments are self-contained and cannot access files or utilities on your instance. Unless you use third-party tools or utilities, the default pre-receive environment should be enough. It is included in every GitHub Enterprise instance and already has the following utilities: awk , bash , coreutils , curl , find , gnupg , grep , jq , sed .
If you require specific tools, you will need to create your own 64-bit Linux chroot environment, either using Docker to generate a chroot archive or by creating the chroot archive manually. Note that while Docker can be used to create compatible environments, it is not used server-side and your pre-receive hook is not running in a Docker image.
Once you've generated and uploaded your archive to your GitHub Enterprise instance, commit your pre-receive hook to a dedicated repository–do not include it in an existing repository!
Finally, you need to define a scope for your pre-receive hook. It can be applied to every repository or a select few, disabled or enabled by repositories administrators, enforced–which means the exit code will dictate whether the push will be rejected– or not.
I hope this has helped clarify what pre-receive hooks are, their value, and how to use them. If you have any questions, please feel free to comment below. Also, stay tuned for a more in-depth look at when not to use pre-receive hooks, coming up in a new GitHub Enterprise Best Practices article soon!
... View more