View source for GitHub/Repository Security/Problems and Options

Some of the [[GitHub/Repository Security|Guidelines]] can appear to be excessively disruptive to workflows. This page lists options and workarounds folks have found for some circumstances. Please add additional ones that you have used successfully! (It's a wiki!)

The first 2 sections list problems and options per guideline. If a guideline isn't listed, no one has (yet) had a problem. It's fair game to list a problem you actually have without a solution - other folks in the community may have ideas, even if they do not experience that particular problem. (No hypothetical problems though, please.)

= Membership Guidelines =

= Repository Guidelines =
== Committing (or merging) to a production branch should be limited to the smallest reasonable set of people. ==
=== Problem: There is currently no way to grant a GitHub app permission to push to "limited commiters" branch. ===

GitHub is aware of the issue, but [https://platform.github.community/t/repositories-which-have-protected-branches-with-push-restrictions-have-no-ability-to-grant-push-rights-to-integrations/1376/47 no firm date] has been announced.

In the interim, the GitHub Apps can open PRs, but a human committer will need to merge them (or a bot using old style OAuth permissions).

== Branch protection should be enabled for production branches ==
Enabling branch protection both (a) prevents branch deletion, and (b) dis-allows force pushes to the branch.
=== Problem: Our workflow uses force pushes to production to ensure we know what will be deployed. ===
There is another way to achieve the same goal, ''and'' make it easier for developers to update from production. The not well know [https://git-scm.com/docs/merge-strategies#merge-strategies-ours "ours" merge strategy] provides a way to achieve both:
* Ensuring the head contains exactly the files you need, and
* Allowing developers (and systems) to always apply Fast Forward updates.

An example of using this workflow is [https://stackoverflow.com/a/9690693/5128493 described] on Stack Overflow.

== Commits (including merges) to the production branch should be GPG signed. ==
=== Problem: Needing to setup GPG for use on GitHub might dissuade contributors ===
The guidance "require signed commits" only targets the production branch(es). Other branches (such as feature or topic branches) need not require signing. However, having unsigned commits in a branch means you need to handle merges in a certain way. In particular, you will not be able to rebase unsigned commits onto a production branch. You will need to merge ("squash-merge" is a GitHub feature that is incompatible with requiring signing).

One option:
* create a "feature branch", used only for merges (no signing required)
* create a "shadow branch", used only for merges (no signing required)
* whomever does the merge, merges via shadow branch using GitHub web UI:
[[File:Mermaid-diagram-20180531130011.svg|framed|center|Merging unsigned commits into signed-commits-required branch]]

=== Problem: I can't squash merge PRs generated by 3rd party services ===
This often occurs with dependency management tools, and is a [https://github.com/renovateapp/renovate/issues/1828 known problem]. The commits in the PR are signed, they just can't be included via any method that modifies that signed commit. Only the "merge" technique meets that requirement.

= General Notes =
For tips that don't fit nicely above, please list them here.

== GitHub web UI Challenges ==