I think it's nice that currently we can upload win32 and osx builds of gnome modules/apps and have them available on gnome servers, if we take away shell access then perhaps the install-module/ftpadmin script should be enhanced to allow this (afaik the only way currently is to manually place a file somewhere on master.gnome.org).
Other than that I think the only interaction I ever needed with master.gnome.org was to hook the autogeneration of glade.gnome.org website to a git commit hook or such (and it probably shouldn't have been me doing that anyway...). Cheers, -Tristan On Thu, Nov 10, 2011 at 10:36 AM, Olav Vitters <o...@vitters.nl> wrote: > On Thu, Nov 10, 2011 at 03:19:07PM +0000, Maciej Marcin Piechotka wrote: >> On Thu, 2011-11-10 at 12:47 +0100, Olav Vitters wrote: >> > 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 >> >> I may be wrong but IIRC ssh can be configured to allow only scp >> connections. Maybe solution would be (instead of rsync): >> >> - Allow scp >> - Allow install-module as default (and only) login shell > > scp is shell commands, only sftp has a bit more of a protocol. But I > don't want people to be able to modify anything than uploading a > tarball (e.g. ~/.bash*). Intention is just allowing exactly what is > needed. > >> > 3. Access is determined using "doap" files >> >> Hmm. Isn't access to git open to everyone who have key? The malicious >> attacker who compromise account one of 350+ user may alter the doap file >> (I guess it would be much easier to miss then say unexpected release >> which is followed by public e-mail). > > ftpadmin informs all existing maintainers when a tarball is uploaded. > I'm intending to inform all existing + new maintainers on any changes > to the doap file. I could (but don't want) to restrict doap file updates > solely to people already marked in the doap file. > > If master.gnome.org is compromised, the attacker could pretend > everything is fine. If it instead follows the process I think is secure > enough, then it just is our policy that is wrong. > > Reason I choose for lax is same reason any gnome git account can modify > any repository: eases development imo. > -- > Regards, > Olav > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list