Mail Archives: geda-user/2012/11/16/15:10:34
Sorry, I don't follow part of your first mail.
DJ Delorie wrote:
> > Repo-per-user wouldn't (and must not!) be different. Depending on if
> > users should access any other repository than their gedasymbols one
> > both user and repository can be created in one go.
>
> Changing someone's admin permissions
Which admin permissions do you mean?
> means adding/removing that user on every single git repo (plus
> adding them on new repos).
Which repos do you mean by "every single git repo" and "new repos" ?
> Must deal with conflicts if the top-level repo happens to have
> stuff in a per-user directory.
The top-level repo wouldn't have content, it would only tie per-user
repos together. A top-level repo isn't strictly needed actually - but
could be a natural place to store scripts and maybe non-user parts of
the website.
> If you use gitk, adding a user means committing to multiple
> repositories.
Hm? Only if the user is actually supposed to write to multiple repos?
For gedasymbols that wouldn't make much sense if we decide that
symbol repos are per user, those repositories would only ever be
written to by their respective owners.
Of course the owners can also have permission to write to other,
non-gedasymbols, repositories on the same server.
There are two popular ways to deal with multiple users and git, and
one, or both, or even something else might be a good fit for us.
One way is gitolite. I find that a bit fragile and complicated, but
it does allow very fine-grained control of who does what where. There
is only one system user, authentication is by public key SSH, all
repo permissions are managed per SSH key.
Another way, and the way I strongly prefer, is to create actual
system users for each user, and manage permissions with repository
granularity using groups and filesystem permissions. A POSIX ACL,
specifically a default mask, is required in order to avoid umask
problems. The shell is set to git-shell, which allows no other
operations on the system besides git actions.
I use the latter approach for successfully hosting several projects
with different usage patterns (single shared repo, as well as
per-user repos) since a few years.
> > What's the current authentication method? pserver or SSH?
>
> pserver
OK, yes, that would indeed change, but another method must of course
remain as easy to manage! Fortunately, that's not a big problem. :)
DJ Delorie wrote:
> > > That separates authentication from attribution. Too easy to put
> > > someone else's name on a file and commit it.
> >
> > I'm sorry, but I don't get why that is a bug and not a feature?
>
> If you steal a footprint and put my name on it, I get in trouble.
Aha! But since I can only put symbols in my own repository it's very
easy for everyone to see that in fact you had nothing to do with it.
If we wanted to, we could easily make per-user gedasymbol
repositories reject any commits with author != repo owner.
I would suggest to match only full name, not email, since people may
change email. The owner would be the value of pw_gecos, as set when
the user is created. (And can be updated if someone changes their
name.)
Another possibility, allowing less checking and relying more on
trusting each other, would be to require every commit to be
Signed-off-by: similar to Linux kernel commits.
And yet another possibility to think of is pgp-signed commits.
I personally think that rejecting author!=owner commits is already
going really far, but it's so easy to do that I wouldn't mind
doing it.
//Peter
- Raw text -