RFC: Securing maintainer uploads to master.gnome.org

[Olav Vitters <olav vitters nl>]

Loads of people currently have access to master.gnome.org as to upload
tarballs. This is currently done by handing out shell access to these
people.

If any of the 350+ has their machine compromised, someone could easily
use that to reach shell on master.gnome.org. I don't want that to be
possible.

My thoughts to secure this is:
1. Get rid of shell for ideally everyone (maintainers, release team,
etc)
2. Uploads are done using:
   a. rsync over ssh using rrsync; this restricts what you can upload
   b. something like: ssh master.gnome.org install-module
   c. the install-module command looks at what you uploaded and then
   calls ftpadmin on it
   Problem:
   a. rsync might be annoying / unreliable
   b. don't think you can delete easily with rsync
   c. more annoying than e.g. sftp or scp
   Benefit:
   a. rsync over ssh is easy to secure
3. Access is determined using "doap" files
4. If you're not in the doap file of that module, you cannot upload
   Problem:
   a. some tarballs aren't on git.gnome.org, so no doap file
5. Release team can upload whatever they want

So as a maintainer you'd do something like:
$ rsync -av gtk+-2.12.7.tar.xz master.gnome.org:sources
$ ssh master.gnome.org install-module sources/gtk+-2.12.7.tar.xz

Not totally sure of the commands to be used. E.g. if you specify just
one file, might make uploading multiple files annoying (in case you move
something to gnome infra).

Further problem is that I have something more or less working for
tarballs (sources), but not for any other section (binaries, etc).

Any thoughts on above? Does it conflict with current way of doing
uploads? How much prenotice should I give if I want to make such a
change? Any other ideas?

-- 
Regards,
Olav

Note: did think of e.g. sftp, scp, chroot and few others. Think it is a
bit too much to explain all the reasoning in this email.