Come up with an update hook to mitigate abuse of sandboxes

Subscribe. Sounds like fun, i'd like to make time to contribute to this piece. Where would these pre-commit hooks live and how should they be implemented?

we already give people barely restricted sandboxes. why exactly is this a "hard requirement". controls are good, but i see no need to inject dependencies. i may be missing something tho.

Moshe: currently you only get a sandbox if you go through the "I want an CVS account" procedure. That's a mitigating factor as this limits the number of people to get one. The new workflow would be "create account on d.o", "click button", "commit stuff".

I would be happy with the following minimalistic checks:

- no file > 1MB
- total size of the sandbox < 100MB

Oh, and this is called an "update" hook in Git.

I wouldn't consider this enough. We should check d.o if there's any file that nees to be in the vicinity of 1 MB, but I think that a 100k limit might be more what we'll end up with.

We should also make sure that anything that you upload isn't easily exposed to third parties. Maybe only make stuff available over got based checkout.

A bit information for an update hook can be found here:
http://book.git-scm.com/5_git_hooks.html
Also every git repo has an example update hook in .git/hooks/update.sample which should be something to look at.
Besides doing this forced checking on the server, it would be nice to have a real pre-commit hook, which is run locally on the client when an user commits something, which rejects the commit. A pre-commit hook is optional, as every user can choose to install it (or not), but it would be nice to have one. From reading the documentation, one would probably have to check the staging area against the rules the update hook enforces.
What we also need to investigate is that if we use per-branch level access, gitolite already installs an update hook, and git natively doesn't support multiple update hooks, so we need some (bash) glue logic there.

@CorniI: as far as I know, the hooks are local to a repository, and are not carried over when you clone a repository. An pre-commit hook would be pretty much useless.

Yes, I know. A pre-commit hook would just reject commits, if installed, not forcing the user to rebase when he committed something not under the d.o rules, as with just an update hook, the user will be notified of his rule violation at push time instead of at commit time. Sure, it'll be totally optional, and thus of less priority than an update hook.

Ah and can we turn this into a general d.o-update hook?
I'm pretty sure that we want the project and issue repositorys to be locked down tightly as well, and you do similiar things there which you'd do in your sandbox.
And while we're there and forbidding stuff to be pushed, can we please deny non-annotated tags with a reasonable message?
Background:
Git supports two different kind of tags, annotated and non-annotated. Non-annotated tags are a simple information which associate the tag name with a given commit id. Annotated tags contain information like the tag date, a tag message, the tagger and they can be GPG-signed if necessary. Given that we don't have even a tag creation date for the non-annotated tags, they're a PITA to support in the vcs_git module and don't look nearly as nice annotated tags.
The update.sample hook from .git/hooks/ even contains a sample implementation of how to forbid non-annotated tags.

The original post suggests limiting file name extensions - any reason not to do that?

tagging

In addition to a precommit hook, we can also have a nightly check via script that runs from cron, and check the overall disk utilization per user, sorted. This could be emailed to some mailing list (infra?) if anyone exceeds a certain threshold.

Something like:

cd /where/git/lives
du -sm * | sort -nr | awk '{if ($1 > 100) { print $0 }}'

I've been thinking quite a bit about this recently. I've got some basic ideas about what to put into our hook scripts, but the problem tends to be that git repository size can vary significantly depending on how many packed vs. loose objects it has. Git repacks (pseudo-)automatically every once in a while, but it's a non-trivial operation that we shouldn't be running on every push. There are tools for differentiating between packed/unpacked size, and we can take advantage of those, too, but...yeah, some things to consider.

What's pretty clear, though, is that I absolutely do NOT want to do this on cron. We already have plenty of wasted IO & cpu due to dumb cron-based infra processes that have to iterate tons of data. This system can easily be event-based, so that's how we should build it.

Is there a separate issue for blocking non-annotated tags?

Could you stagger accounts? A Basic sandbox for everyone and an advanced sadbox for "verified" users?

Then you could impose the restrictions such as files <1mb but lift them when the account is verified. It means the restrictions will not have to accept literally every possible drupal module.

Closing old issues. Please re-open if needed.