1 |
* Michael Orlitzky <mjo@g.o> [150923 08:31]: |
2 |
> On 09/23/2015 04:40 AM, Todd Goodman wrote: |
3 |
> > |
4 |
> > We haven't had too many problems with it. Most of our problems seem to |
5 |
> > be with people having issues with git itself (it was new to almost |
6 |
> > everyone on the team) and not embracing a good workflow with it (or |
7 |
> > trying to only use git via Eclipse.) |
8 |
> > |
9 |
> > We have 80 or so Android repos and a much smaller handful of proprietary |
10 |
> > repos in use. |
11 |
> > |
12 |
> |
13 |
> Sorry to harp on this, but does your single gerrit user have write |
14 |
> access to all 80 of your repos? Yours is internal so the risk is |
15 |
> limited, but naturally, if we set one up, it would have to be public. |
16 |
|
17 |
No, there are Projects (repos) which can have project owners and other |
18 |
levels of permissions. There's no need to allow wide open access. |
19 |
|
20 |
We do have most of our small set of developers able to push reviews for |
21 |
any of our repos but nothing can be committed without review so people |
22 |
don't tend to "stupid" things (it's also a company so there's the whole |
23 |
"do something stupid and you're likely to lose your job.") |
24 |
|
25 |
Some branches are set up to require "gatekeeper" approval in addition to |
26 |
reviewer approval. And as I mentioned it's tied into our bug tracking |
27 |
system as well so one can't even push a review unless the ticket has had |
28 |
appropriate fields filled out, etc. |
29 |
|
30 |
> |
31 |
> If there's a bug in the web UI somewhere and someone figures out how to |
32 |
> make it run code, that would put all of our repos at risk. Even without |
33 |
> being able to run code, a bug might allow privilege escalation: someone |
34 |
> outside the e.g. portage project might figure out how to push to that |
35 |
> repo because all of the logic is in Java and not the filesystem. |
36 |
|
37 |
Yes, as I said we haven't had any formal security audit conducted. |
38 |
|
39 |
I'd personally expect exploits against Google's accessible Gerrit |
40 |
instances, but that's obviously not a formal security audit either. |
41 |
|
42 |
For security of large chunks of software you either pay someone to |
43 |
perform a formal security audit of it for you or else you get as many |
44 |
people as you can that you trust to do so. |
45 |
|
46 |
To me, it's a similar problem to your web server or database or anything |
47 |
else running on a machine that's on a network. |
48 |
|
49 |
> |
50 |
> The way we have it now, push access is granted through SSH and is |
51 |
> therefore tied to your user. Implementing users/groups/permissions in |
52 |
> code would really be a step backwards; this isn't a theoretical argument. |
53 |
|
54 |
I'm certainly not arguing for or against Gentoo using Gerrit. It was |
55 |
mentioned and I just brought up my experience with it. |
56 |
|
57 |
Though I don't see it as a step backwards. A user authenticates in |
58 |
either case and gets permissions based upon that. |
59 |
|
60 |
Either you trust the authentication mechinism in each case or you don't. |
61 |
|
62 |
Yes, I agree more complicated permission systems have the ability to |
63 |
cause problems if set up improperly. |
64 |
|
65 |
But with both SSH and Gerrit your authentication and permissions are "in |
66 |
code." |
67 |
|
68 |
> |
69 |
> These issues can totally be fixed -- I'm not saying they're endemic to |
70 |
> web-based git hosting. But to move access control down to the filesystem |
71 |
> deviates from how everyone else does things. So first you need to spend |
72 |
> time getting familiar with the project, then you have to overhaul the |
73 |
> way it works, and finally you have to get upstream to acknowledge that |
74 |
> you aren't crazy and accept your docs/patches. That's a lot more work |
75 |
> than just setting it up. |
76 |
|
77 |
I don't understand why you said earlier the access control was in code |
78 |
and now you're saying it's moved to the filesystem? |
79 |
|
80 |
Filesystem access control for Gerrit is the most basic form you'd use |
81 |
for any system. e.g., database files are accessible to the database |
82 |
user/group only not to anyone else and then per user/group access is |
83 |
controlled via the "in code" methods. |
84 |
|
85 |
Again, I'm not arguing for or against Gerrit, just relating my |
86 |
experience with it. |
87 |
|
88 |
Todd |