On Thu, 09 Jan 2014 at 12:10:27, Techlive Zheng wrote:
[...]
I don't think we should support `git-push` at all, the reasons are simple:
* Git allows overwriting the history by doing a force push `git push -f`. As a community PKGBUILD publishing platform, the git history of a PKGBUILD should not be allowed to be tampered with, whether accidently or intentionally, it should reflect how the PKGBUILD envloved from the start, not the one someone carefully crafted.
* Changed history will cause conflit on `git pull`, which is not something we want to deal with everyday.
You can reject non-fast-forwards by enabling receive.denyNonFastforwards on the server.
Instead, we should stick on the `src.tar.gz` tarball submitting, and make the Git commit on the server.
At least, push access should not be granted to normal user, only to TUs.
Why? I agree that keeping the tarball submission form and doing Git commits on the server is a nice first step but providing Git push access is much more convenient...
Also, if we allow normal user to push directly with Git, it will be harder to do sanity check. One can push anything, not just the packaging files, but anything, binaries, compressed source/build tarballs, even files unrelated to Arch packaging at all. These malformed files can exist not only in the Git HEAD, but can be intentionally hided in the history, makes it hard to control the space quotas.
I guess this could be done in a pre-receive hook. We also need to perform these checks when committing tarball contents -- I don't think it will be much harder to do it inside a Git hook.
We'd better only access 'src.tar.gz' tarball and control the commit process on the server on our own, so that we can do necessary sanity check to ensure files to be commited are really what they claim to be.
Any comments and suggestions are welcome!
Regards, Lukas