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. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
