What I'm missing is a different security model than the current `If an endpoint can push to gitlab, it is trusted and can execute code server-side`.

There is no (current) way to enforce a 2fa step in order to push to a repository, and while you can technically implement them, that doesn't mean much, due to the nature of `git push`.

What I want is a 2fa-enabled review boundary between "commit" and "execute", which currently isn't possible.

Protected branches can be unprotected without an auth step.

There's nothing on the server-side that signs `gitlab` generated merge-commits in the commit graph, so no way to distinguish them from other merges.

There's no security boundary to change the deployment details, or to modify the deployment pipeline to run from a different branch.

Basically, I'd want a way to ensure that there's an authenticated hand-off between "commit" and "deploy" steps on the chain.

Also, it'd be nifty if one could get gitlab to maintain a version number, increasing with every merge request merged, in order to get smooth tagged builds when MR's are used.