a very weeny construct đ
Cassandralgernon#Forgejo (& #Codeberg) + AGit support remains one of my favourite ways to send pull requests.
No email, no fork, just a branch and a push.
Csepp đĸ
!
Stefan Sperling@algernon I have been wondering about the ramifications of granting repository write access to random strangers which seems to be how agit works in forgejo (please correct me if I am wrong about this). I realise they are writing to a restricted reference namespace. But it might still allow for scenarios like filling the disk on the server or getting arbitrary code execution in CI or on developer's machines.
@stsp Filling the disk is a concern, yes.
But: that is also a concern in the traditional fork & PR model, except even worse: the repository is copied in that case, which can use a lot of disk space, even if only a single branch is copied to the fork. It also creates a bunch of metadata, and is, in general, rather noisy.
In contract, AGit only uses as much space as the pushed data, there is no copy involved.
Yes, Forgejo lets you limit how many forks a person can make, to lessen the impact of big repos. But Forgejo also lets you set quotas on the size of a repo (and AGit pushes will count towards that), so mitigations exist.
Same for CI: CI can run on pull request, whether AGit or not. CI jobs for AGit PRs run with the same privileges and permissions as traditional, "external" PRs. Just because the branch is technically in the same repo, it does not have access to more things.
@algernon Makes sense, though this design encourages a model where all the important data lives at one centralized hub which will be some particular instance of forgejo.
We have no tooling at the Game of Trees Hub yet for code reviews, which is why I am pondering about eventually implementing something like Agit.
For now, I'm still convinced that a model which forces previously unknown contributors to host their own forks and make them available for upstream projects to pull from provides better security boundaries and encourages people to host a fork somewhere which is fully under their own control. The latter might be considered a hurdle but I think it can also be empowering especially in cases where working with the upstream project doesn't turn out well.
This approach won't mix well with centralized CI checks. But while I do think automated testing is essential, I wouldn't really want to provide hosted runners as a service, again both for security reasons and to distribute the load. I'd rather merely be coordinating the work done by self-hosted runners.
Makes sense, though this design encourages a model where all the important data lives at one centralized hub which will be some particular instance of forgejo.
Yep. It's far from perfect, it's merely an improvement over the fork model.
For now, I'm still convinced that a model which forces previously unknown contributors to host their own forks and make them available for upstream projects to pull from provides better security boundaries and encourages people to host a fork somewhere which is fully under their own control. The latter might be considered a hurdle but I think it can also be empowering especially in cases where working with the upstream project doesn't turn out well.
It's always a tradeoff, I think. People hosting their own forks (either on the same forge, or somewhere else) does have better security properties, and provides more control for the contributor indeed. For cases where one is or plans to contribute longer term, I think that model can work better than AGit.
It's a huge pain in the backside for drive-by contributions. If I just want to drop a quick patch, I'd rather email upstream1 than fork & PR, the latter requires too many steps: fork, branch, send PR, keep track of if/when PR gets merged, delete fork. With agit, it's clone & branch2 & push, and forget.
I hate emailing patches. âŠī¸
Branching is optional too. I branch, because my helper script does it for me anyway. âŠī¸
@algernon Yeah I see how direct write access can be very convenient for this use case. Your initial description of being satisfied with this is what brought me back into this line of thought...
I'll think more about it. Maybe allowing write access to copies on a separate isolated machine or something could be done. Though it seems like this would need constant operator attention. I immediately start worrying about spam, abuse, malware, people using it as a free online storage cache, inappropriate content being uploaded and becoming exposed on the web, etc.
@stsp Oh, anonymous write access would be a big no-no. For Forgejo, a local account is required - that limits abuse, because an account can be banned, and signing up requires effort.
...which is another reason why AGit is mostly useful for centralized forges.
@algernon Oh right, they have a global user namespace. I completely forgot about that.
At the Game of Trees Hub we run one dedicated VM per subscription, which are essentially project spaces. User accounts and repositories are specific to each VM and are created by the project space admin(s). It's a bit like the "organization" structure on other forges. Anyone can create an organization, but people need to be invited to become part of an existing organization and get write access to one or more of the org's repositories.
In any case, putting all those differences aside, the reference naming conventions used by Agit could be adopted by us to make the code review workflow similar to how it works in forgejo.