[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] RFI: A better workflow for github pull requests
From:       Todd Goodman <tsg () bonedaddy ! net>
Date:       2015-09-24 9:59:00
Message-ID: 20150924095900.GC30683 () ns1 ! bonedaddy ! net
[Download RAW message or body]

* Michael Orlitzky <mjo@gentoo.org> [150923 08:31]:
> On 09/23/2015 04:40 AM, Todd Goodman wrote:
> > 
> > We haven't had too many problems with it.  Most of our problems seem to
> > be with people having issues with git itself (it was new to almost
> > everyone on the team) and not embracing a good workflow with it (or
> > trying to only use git via Eclipse.)
> > 
> > We have 80 or so Android repos and a much smaller handful of proprietary
> > repos in use.
> > 
> 
> Sorry to harp on this, but does your single gerrit user have write
> access to all 80 of your repos? Yours is internal so the risk is
> limited, but naturally, if we set one up, it would have to be public.

No, there are Projects (repos) which can have project owners and other
levels of permissions.  There's no need to allow wide open access.

We do have most of our small set of developers able to push reviews for
any of our repos but nothing can be committed without review so people
don't tend to "stupid" things (it's also a company so there's the whole
"do something stupid and you're likely to lose your job.")

Some branches are set up to require "gatekeeper" approval in addition to
reviewer approval.  And as I mentioned it's tied into our bug tracking
system as well so one can't even push a review unless the ticket has had
appropriate fields filled out, etc.

> 
> If there's a bug in the web UI somewhere and someone figures out how to
> make it run code, that would put all of our repos at risk. Even without
> being able to run code, a bug might allow privilege escalation: someone
> outside the e.g. portage project might figure out how to push to that
> repo because all of the logic is in Java and not the filesystem.

Yes, as I said we haven't had any formal security audit conducted.

I'd personally expect exploits against Google's accessible Gerrit
instances, but that's obviously not a formal security audit either.

For security of large chunks of software you either pay someone to
perform a formal security audit of it for you or else you get as many
people as you can that you trust to do so.

To me, it's a similar problem to your web server or database or anything
else running on a machine that's on a network.

> 
> The way we have it now, push access is granted through SSH and is
> therefore tied to your user. Implementing users/groups/permissions in
> code would really be a step backwards; this isn't a theoretical argument.

I'm certainly not arguing for or against Gentoo using Gerrit.  It was
mentioned and I just brought up my experience with it.

Though I don't see it as a step backwards.  A user authenticates in
either case and gets permissions based upon that.

Either you trust the authentication mechinism in each case or you don't.

Yes, I agree more complicated permission systems have the ability to
cause problems if set up improperly.

But with both SSH and Gerrit your authentication and permissions are "in
code."

> 
> These issues can totally be fixed -- I'm not saying they're endemic to
> web-based git hosting. But to move access control down to the filesystem
> deviates from how everyone else does things. So first you need to spend
> time getting familiar with the project, then you have to overhaul the
> way it works, and finally you have to get upstream to acknowledge that
> you aren't crazy and accept your docs/patches. That's a lot more work
> than just setting it up.

I don't understand why you said earlier the access control was in code
and now you're saying it's moved to the filesystem?

Filesystem access control for Gerrit is the most basic form you'd use
for any system.  e.g., database files are accessible to the database
user/group only not to anyone else and then per user/group access is
controlled via the "in code" methods.

Again, I'm not arguing for or against Gerrit, just relating my
experience with it.

Todd

[prev in list] [next in list] [prev in thread] [next in thread]