Protected branches

[Oreolek]

Let's say there's a branch with an ACL, so only the specified servers could checkout it and only specified users could push to it. How would that look?

[yookoala]

No one in the work group think we should do push in our protocol. Git is perfectly capable to handle push permission with password control / certificates. Code checkout is the same. Basically, if Git is doing it fine, we won't touch it.

So we're only dealing with pull request, fork and maybe issue tracking. And you might ask the same access control question about these 3. Right?

It is very hard to enforce any security policy over a federated network. Security would needed to be done by the server hosting the project. Once the source code, or any federated messages, has left the original server, there is no way to enforce ownership or readership.

I think to fork from / send PR to a remote repository, you'd have to have a way to login to that remote server to gain access information (some access token?) for you to do it.

[bill-auger]

On Fri, 13 Jul 2018 02:31:22 -0700 Koala Yeung wrote: I think to fork from / send PR to a remote repository, you'd have to have a way to login to that remote server to gain access information (some access token?) for you to do it.

but this was an excellent explanation koala git can allow anonymous read/only access over HTTP for example - authentication is typically only required to modify (e.g. push)

On Fri, 13 Jul 2018 02:10:29 -0700 Alexander Yakovlev wrote: Let's say there's a branch with an ACL, so only the specified servers could checkout it and only specified users could push to it. How would that look?

there are a few important caveats that were implicit in this question that OP should be aware of firstly, the very notion of "protected branches" is a github invention - for one thing, this spec is intending to support a wide range of VCSs and clients, even raw patches; and not all VCS have "branches" - also, "protecting" branches is not a general development practice; so even if it were feasible, this would be a forge-specific niche-feature the second thing is that the web server and the git server are two entirely separate things - neither depends on or are necessarily coupled to the other - there is no way to represent a "protected branch" in git - that is a fiction that the git server must enforce locally with hooks based on it's own local permissions mechanism as maintained by it's local users the third thing is regarding authentication - when a user initiates a cross-server clone (aka "fork") the forge website (or whatever interface it exposes) plays no role in that, other than to send a request to the user's home-server requesting that it's user has initiated the action - then that user's home-server needs to log into the source git server to do the clone on the user's behalf - note that is the source git server, not the associated web server (they may be on entirely different machines) - off-hand, im not sure if it is even possible for the home-server to indicate which user on whoms behalf the clone is being requested - in any case, it could lie about that the git server would typically only filter on IP addresses and SSH keys; and neither of those would be associated with the user, but the home-server - so yes, it could specify which servers are allowed to checkout the code; but pushing code onto a server should only be allowed for it's local verified users - no one should want foreign users to have write access; and i doubt that any forge would implememnt it - if the web server wants to reject clones initialted by a foreign users with per-user granularity, the only chance it has is to reject the initial mouse click "at the front door" - it can do that, but as koala explained, there is nothing the protocol could do to assist, nor to insist, nor to prevent anything of the like "out in the cloud"