Re: RFC: Securing maintainer uploads to

   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

Other than that I think the only interaction I ever needed with
was to hook the autogeneration of 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 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 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]