| 1 |
On 09/23/2015 04:40 AM, Todd Goodman wrote: |
| 2 |
> |
| 3 |
> We haven't had too many problems with it. Most of our problems seem to |
| 4 |
> be with people having issues with git itself (it was new to almost |
| 5 |
> everyone on the team) and not embracing a good workflow with it (or |
| 6 |
> trying to only use git via Eclipse.) |
| 7 |
> |
| 8 |
> We have 80 or so Android repos and a much smaller handful of proprietary |
| 9 |
> repos in use. |
| 10 |
> |
| 11 |
|
| 12 |
Sorry to harp on this, but does your single gerrit user have write |
| 13 |
access to all 80 of your repos? Yours is internal so the risk is |
| 14 |
limited, but naturally, if we set one up, it would have to be public. |
| 15 |
|
| 16 |
If there's a bug in the web UI somewhere and someone figures out how to |
| 17 |
make it run code, that would put all of our repos at risk. Even without |
| 18 |
being able to run code, a bug might allow privilege escalation: someone |
| 19 |
outside the e.g. portage project might figure out how to push to that |
| 20 |
repo because all of the logic is in Java and not the filesystem. |
| 21 |
|
| 22 |
The way we have it now, push access is granted through SSH and is |
| 23 |
therefore tied to your user. Implementing users/groups/permissions in |
| 24 |
code would really be a step backwards; this isn't a theoretical argument. |
| 25 |
|
| 26 |
These issues can totally be fixed -- I'm not saying they're endemic to |
| 27 |
web-based git hosting. But to move access control down to the filesystem |
| 28 |
deviates from how everyone else does things. So first you need to spend |
| 29 |
time getting familiar with the project, then you have to overhaul the |
| 30 |
way it works, and finally you have to get upstream to acknowledge that |
| 31 |
you aren't crazy and accept your docs/patches. That's a lot more work |
| 32 |
than just setting it up. |
Archives