Changes between Version 9 and Version 10 of GitolitePlan


Ignore:
Timestamp:
Jul 30, 2013 8:38:46 AM (9 months ago)
Author:
hvr
Comment:

fix markup

Legend:

Unmodified
Added
Removed
Modified
  • GitolitePlan

    v9 v10  
    1515 * Every user needs a full shell account.  
    1616 
    17    * While we probably *won't* be forkbombed by someone, few people actually *need* a full shell account, and the *principle of least privilege* applies here. Really, everybody is just pushing to Git. 
     17   * While we probably ''won't'' be forkbombed by someone, few people actually ''need'' a full shell account, and the ''principle of least privilege'' applies here. Really, everybody is just pushing to Git. 
    1818 
    1919 * Because of the previous point, group and access permissions on the repositories regularly get screwed up, causing situations where people don't have access (and can't push,) or we have to have `post-receive` hooks that modify the permissions. Both of these suck (this doesn't affect e.g. the Linux kernel developers, who have pull-based development models, because they can afford to.) 
    2020 
    21    * Due to the current permission scheme, all users in the `darcs` group are effectively at the level of Trac admins, which can manipulate the `trac.db` database (this is needed by the Git hooks to update the Trac tickets). Again, the *principle of least privilege* should apply here. 
     21   * Due to the current permission scheme, all users in the `darcs` group are effectively at the level of Trac admins, which can manipulate the `trac.db` database (this is needed by the Git hooks to update the Trac tickets). Again, the ''principle of least privilege'' should apply here. 
    2222 
    2323   * Moreover, people invariably fix this but it's always slightly patchy, and so the repositories that need 'fixing' for things like permissions are inconsistent, and it's hard to keep track of what needs to be maintained. 
     
    2727 * Git admins need to perform risky direct manipulations in the file-system, even for the simplest Git repository administration tasks. 
    2828 
    29 The proposed remedy is to use the Git-access wrapper [[https://github.com/sitaramc/gitolite/wiki|**Gitolite**]] which provides an authorization layer on top of Git, and is executed as a separate system user (thus accessing the git repositories with only one Unix UID).  Users accessing git repositories via ssh are discriminated by their ssh public key. 
     29The proposed remedy is to use the Git-access wrapper [[https://github.com/sitaramc/gitolite/wiki|'''Gitolite''']] which provides an authorization layer on top of Git, and is executed as a separate system user (thus accessing the git repositories with only one Unix UID).  Users accessing git repositories via ssh are discriminated by their ssh public key. 
    3030 
    3131Gitolite also greatly simplifies user management, as a user management is little more than adding/removing a file containing the user's public key, and pushing that the administrative "`gitolite-admin`" git repository (Gitolite is administrated via git itself!). Similarly, adding a new git repository comes down to adding a few lines to the central Gitolite repository config file and pushing that file to the "`gitolite-admin`" Git repository. 
     
    6565   * We can leave `darcs.haskell.org` as-is for legacy reasons, while creating new VHOST on `http://git.haskell.org/` which would expose only the Gitolite-owned git repositories (and maybe also a Cgit front-page as e.g. on http://git.kernel.org) 
    6666 
    67  * Who's actively committing, and does anybody beyond that actually *need* a shell account? It's unclear who uses `ghc.haskell.org` for what at the moment, beyond push access. 
     67 * Who's actively committing, and does anybody beyond that actually ''need'' a shell account? It's unclear who uses `ghc.haskell.org` for what at the moment, beyond push access. 
    6868 
    6969 * Tangential: The current directory setup is a total mess on `darcs.haskell.org`, especially since the old darcs repos hang around there. Maybe we should clean it up if we're going to use it for a browseable directory.