Re: RFC: Securing maintainer uploads to master.gnome.org

[Tristan Van Berkom <tvb gnome org>]

   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 <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
> 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
>