Re: RFC: Securing maintainer uploads to master.gnome.org
- From: Tristan Van Berkom <tvb gnome org>
- To: Maciej Marcin Piechotka <uzytkownik2 gmail com>, desktop-devel-list gnome org
- Subject: Re: RFC: Securing maintainer uploads to master.gnome.org
- Date: Thu, 10 Nov 2011 19:47:26 -0500
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...).
On Thu, Nov 10, 2011 at 10:36 AM, Olav Vitters <olav 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
>> > 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.
> desktop-devel-list mailing list
> desktop-devel-list gnome org
] [Thread Prev