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 > > > > > > [1] https://bugs.archlinux.org/task/23010
