Disabling force-push on the default branch for projects hosted on GitHub

[mbarbero]

Dear Eclipse Foundation Projects committers,

As part of our ongoing commitment to help you with strengthening the security and integrity of your projects, we've recently implemented measures like enforcing two-factor authentication (2FA) and enabled self-service options. Today, we're introducing another important change: we will disable force-push on default branches across all repositories of projects hosted on GitHub.

Force-pushing allows the commit history of a repository to be rewritten, which can pose a security risk. It can obscure the tracking of changes, making it difficult to maintain a clear audit trail and potentially hiding unauthorized modifications. By disabling force-push on default branches, we aim to:

• Protect code integrity: ensuring that the commit history remains consistent and tamper-proof.
• Enhance auditing capabilities: making it easier to track changes and review the evolution of the codebase.
• Support team collaboration: preventing accidental overwrites or loss of work, and encouraging best practices like pull requests and code reviews.

This aligns our GitHub repositories with the standards already in place on our GitLab instance at https://gitlab.eclipse.org/, where force-push is disabled by default.

This change will take effect on 20 November 2024. Please adjust your workflows accordingly before this date.

You may need to modify your development practices to accommodate this change. Instead of force-pushing to the default branch, consider working within feature branches and merging changes through pull requests. This approach not only preserves the integrity of the commit history but also fosters better collaboration and code quality through peer reviews.

We understand that this may require some adjustments, and we're here to support you during this transition. If you have any questions or concerns, or if a special situation arises where force-pushing to the default branch is necessary, please feel free to reach out or comment below.

Thank you for your understanding and cooperation as we continue to improve our development processes.

Kind regards,

(Also posted on Oct 31 on eclipse.org-committers mailing list)

[boaks]

In my opinion, that will also prevent the practice ("good" or "bad" one 🙂 ), to work on new major versions and continue to use the "main" for the current/previous version until the new major is stable enough. That usually requires then to "reset" the "main", when the new major gets stable enough to become the default (main). With that, I would guess, it will be required to:

• introduce to use a "ticket" to switch the main to a new major (means reset the main to that)
• and protect also the previous main branch, now representing the (bugfix) work on previous versions (maybe named "vA.B.x").

Are there plans to do so? Or what will be the intended "workflow" for new major versions and version specific bugfix branches?

br
Achim

[mbarbero]

Nothing is perfect. With self-service, we have an audit trail of actions, and it requires approval from project leads. This approach offers flexibility while ensuring a sufficient level of control.

Additionally, preventing force-pushes on the default branch is only the bare minimum we expect all projects to implement. However, we can extend these protections further, such as by safeguarding all branches except those following a specific naming pattern (e.g., dev-*). In such cases, changing the default branch to something like dev-something should prompt further scrutiny and raise additional question. Each project will want to handle this differently, so it makes sense for us to stick with a minimal, slightly improved default.

[boaks]

In my opinion/experience, if we want to have such a protection, I guess the rules will be strict.
That works well in many cases, but not in all, so we need to check, where that may fail.
From my view, especially the "start-off-phase" of a new "major version" and the switch, when
that new major version gets mature and turns into the default, will be one of these exceptions.

I consider, after the next minor release (Eclipse/Californium next week), to start with the
work on the next major. My forecast will be, that it requires quite a lot of time until it gets stable
again. Without the possibility of such a "ticket based force" I will need to do that development on
the main adding in the "readme", that the "main" is "dev" and people should go for an other "stable" branch.

So, please be clear and decide, if "forced push" will be possible with an ticket or not.

[mbarbero]

Yes, it will be possible. To temporarily enable force-push, you will have to either open a helpdesk ticket or use the self-service option, as @netomi mentioned above.

That said, if you'd like, we can help you design a workflow that supports working on the next major version in a separate branch, without needing force-pushes. We're here to assist.

[boaks]

As long as there will be two branches representing a different major version, and different commits are pushed to both, I don't see, how the branch "main" will be changed from the old to the new major version with out a "forced push" on that branch. The different commits are usually the result of different scopes, the new major branch will address the new developments, while the old one will only address bug fixes and maybe a small number of back-ported features. That seems to be natural for me. If you know how to do that different, your welcome.

Overall, in my opinion, it's more important, to "freeze" the "release tag", which in my opinion implicitly "freezes" the commit history to that tag. I tried to check it (I'm not that sure), but for now, the "commit" is not included in the "signed files" of a release jar. The (class-) files them self are signed, but a file "representing the git commit" seems to be missing. Maybe adding such a "versioning" file in the build process somehow in the future, brings even more security.

[mbarbero]

That seems to be natural for me. If you know how to do that different, your welcome.

As I understand it, your priority is to present a default branch on GitHub that offers stable code for your community to clone. To achieve this, I suggest moving away from always using the main branch as a default and instead adopting different branch names for the various release streams. When a new major stream becomes stable enough, simply switch the default branch (for cloning and GitHub display) to the branch corresponding to that major version.

What are your thoughts?

Overall, in my opinion, it's more important, to "freeze" the "release tag", which in my opinion implicitly "freezes" the commit history to that tag

I’ve created a PR with self-service that implements this approach. Let me know what you think: eclipse-californium/.eclipsefdn#1

[KerstinKeller]

Hi @mbarbero, could you please clarify the term "main branches"?
Does that mean the default branch? Or maybe protected branches?
Sometimes we do force pushes on feature development branches. E.g. we branch from master, to feature_1 and work on that. In the meanwhile, feature_2 and feature_3 are merged, so we rebase feature_1 on the new master and force push, to resolve possible conflicts but at the same time keep the PR open and keep all comments there. Will this flow still be possible?

[mbarbero]

Hi @mbarbero, could you please clarify the term "main branches"?
Does that mean the default branch? Or maybe protected branches?

Indeed, referring to the main branch is misleading. Sorry about that. What we meant is the default branch, regardless of its name (main, master, dev, etc.).

Sometimes we do force pushes on feature development branches. E.g. we branch from master, to feature_1 and work on that. In the meanwhile, feature_2 and feature_3 are merged, so we rebase feature_1 on the new master and force push, to resolve possible conflicts but at the same time keep the PR open and keep all comments there. Will this flow still be possible?

As far as I understand, you force-push the branch feature_1 and not the master branch, so yes, this workflow will still be possible.

[waynebeaton]

I'm actually surprised that force push is allowed at all. I recall that, at least at some point, force push was allowed only on branches named with a committer id, e.g., wbeaton/do_stuff.

IMHO, trying to decide which branches are "main" branches, or attempting to capture that in some metadata is going to be a game of whack-a-mole.

Wouldn't it be better to set a policy by which force push is allowed only on branches that follow certain naming conventions? I believe that there are existing conventions of allowing force push on branches named, for example, feature/*, debug/*, bug/*, or dev/*.

[mbarbero]

I'm actually surprised that force push is allowed at all. I recall that, at least at some point, force push was allowed only on branches named with a committer id, e.g., wbeaton/do_stuff.

That was the case on Gerrit, but it has never been a default on GitHub.

IMHO, trying to decide which branches are "main" branches, or attempting to capture that in some metadata is going to be a game of whack-a-mole.

We rely on the "default" branch concept, which is the branch displayed by default in a repository and the branch to be checked out on new clones. While this does not mean that it is the "main" branch, it is a good enough default IMO (no pun intended).

Wouldn't it be better to set a policy by which force push is allowed only on branches that follow certain naming conventions? I believe that there are existing conventions of allowing force push on branches named, for example, feature/*, debug/*, bug/*, or dev/*.

It would certainly be better, but this would be a much bigger change, far more intrusive to the current project workflows. So, I would only go with a recommendation using those patterns.