Web front-end to manage users/repos?
Fuhrmanator
- Unregistered users to create their own accounts (assuming the server's visible only on a VPN).
- Registered users to manage the creating and sharing of their repos with other users on the same server.
Sitaram Chamarty
> Hi,
>
> I'm wondering if anyone's written a web front-end on top of it, to allow:
gitlab (which you mentioned below) is the only one I am aware of.
However, since gitlab never contacted me to tell me about the project
(at least when they switched from gitosis to gitolite) there could
well be others like them that I am not aware of.
Personally, in a uni env I expect people to be able to use wild repos
easily enough. After all, from the user's point of view it's just a
'git clone' command. Perhaps you have not read
http://sitaramc.github.com/gitolite/wild.html
>
> Unregistered users to create their own accounts (assuming the server's
> visible only on a VPN).
> Registered users to manage the creating and sharing of their repos with
> other users on the same server.
>
> I found GitLab (which is how I found gitolite!), but as far as I can tell it
> requires a super-user to create users/repos.
>
> We're looking at a solution for a university-wide environment where lots of
> users (students, researchers) have dynamic needs for version control. If
> superusers must be involved to create user accounts and/or manage repos, it
> is a huge overhead.
>
> Cheers,
>
> Cris
--
Sitaram
Javier Domingo
- You don't need sudo powers but to make the installation of rails and create the git user
- Gitolite allows to do A LOT of things. But, no official web-frontend for it.
[2]http://sitaramc.github.com/gitolite/index.html#what
Eli Barzilay
> On Mon, Apr 23, 2012 at 1:58 AM, Fuhrmanator <fuhrm...@gmail.com> wrote:
> > Hi,
> >
> > I'm wondering if anyone's written a web front-end on top of it, to allow:
>
> gitlab (which you mentioned below) is the only one I am aware of.
> However, since gitlab never contacted me to tell me about the project
> (at least when they switched from gitosis to gitolite) there could
> well be others like them that I am not aware of.
>
> Personally, in a uni env I expect people to be able to use wild repos
> easily enough. After all, from the user's point of view it's just a
> 'git clone' command. Perhaps you have not read
> http://sitaramc.github.com/gitolite/wild.html
Yeah, that isn't a big problem.
Probably the main PITA for a CS dept setting is people who want to
collaborate with Some Random Guy, and they need to ask for SRG's
pubkey to be added for that. I'd love to see a solution for that too,
but no idea how it would look like.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Sitaram Chamarty
> Hi fuhrmanator,
>
> As far as I have read the little documentation (of GilLab), you don't need
> to be superuser to do anything but install (and only the dependencies). The
I think he meant "super user within gitlab's set of virtual users" not
"root on the box".
Stafford Brunk
I also tend to agree with Sitaram that wild card repos would work really well. Before the gitlab rollout that's how we managed git repos. It was relatively little in administration.
Yeah, that isn't a big problem.
Probably the main PITA for a CS dept setting is people who want to
collaborate with Some Random Guy, and they need to ask for SRG's
pubkey to be added for that. I'd love to see a solution for that too,
but no idea how it would look like.
On Mon, Apr 23, 2012 at 1:58 AM, Fuhrmanator <fuhrm...@gmail.com> wrote:Hi, I'm wondering if anyone's written a web front-end on top of it, to allow:gitlab (which you mentioned below) is the only one I am aware of. However, since gitlab never contacted me to tell me about the project (at least when they switched from gitosis to gitolite) there could well be others like them that I am not aware of. Personally, in a uni env I expect people to be able to use wild repos easily enough. After all, from the user's point of view it's just a 'git clone' command. Perhaps you have not read http://sitaramc.github.com/gitolite/wild.html
Unregistered users to create their own accounts (assuming the server's visible only on a VPN). Registered users to manage the creating and sharing of their repos with other users on the same server. I found GitLab (which is how I found gitolite!), but as far as I can tell it requires a super-user to create users/repos. We're looking at a solution for a university-wide environment where lots of users (students, researchers) have dynamic needs for version control. If superusers must be involved to create user accounts and/or manage repos, it is a huge overhead. Cheers, Cris
Hi,I'm wondering if anyone's written a web front-end on top of it, to allow:
Eli Barzilay
> [...] My environment is not as complicated as yours seems to be,
> however.
It's not really complicated -- it's just a common request that people
tend to have frequently in a dept setting. Alice is a user in the
dept who wants to work on a project (often a paper) with Bob who is
from someplace else -- and to do that she has to ask me (the GL admin)
to add a username for him. Now I need to find a good username for
Bob, and mail him to send me a pubkey, then worry about Alice
forgetting about the whole thing in a few months -- I'd mail her then
about it and she'd worry about losing the repo etc etc.
A good solution would make it possible for her to add a username for
Bob herself, where the username ends up being subbed from her username
somehow to avoid clashes. But I don't see an easy way to do that, at
least not without some made-up username like `alice:bob' which will
most likely confuse Bob and I end up with complaints about stuff not
working.
I think that it could be hacked somehow with allowing a username of
`bob' but somehow converting it internally to `alice:bob' if the key
that gets used belongs to that Bob (rather than another `bob' who is
in the dept). Getting https users too would be fun... (Actually,
maybe it's easier than I imagine.)
Also, off-topic, but I can't help barfing here:
> #
> April 22, 2012 8:54 PM
>
> Yeah, that isn't a big problem.
> #
> April 22, 2012 8:25 PM
Seriously??? There's an email client that intentionally takes my
nicely formatted bottom-post email and butcher it into a top-post
mess??? This is some kind of a new record in software being
obnoxious, making you rewrite my emails. (No wonder it's coming from
a Mac, and touted as "Awesome Email"...)
Stafford
Sitaram Chamarty
> 20 minutes ago, Stafford Brunk wrote:
>> [...] My environment is not as complicated as yours seems to be,
>> however.
>
> It's not really complicated -- it's just a common request that people
> tend to have frequently in a dept setting. Alice is a user in the
> dept who wants to work on a project (often a paper) with Bob who is
> from someplace else -- and to do that she has to ask me (the GL admin)
> to add a username for him. Now I need to find a good username for
> Bob, and mail him to send me a pubkey, then worry about Alice
> forgetting about the whole thing in a few months -- I'd mail her then
> about it and she'd worry about losing the repo etc etc.
>
> A good solution would make it possible for her to add a username for
> Bob herself, where the username ends up being subbed from her username
> somehow to avoid clashes. But I don't see an easy way to do that, at
> least not without some made-up username like `alice:bob' which will
> most likely confuse Bob and I end up with complaints about stuff not
> working.
Bob won't see that his user name is "alice:bob" unless he does "info".
And in g3 that is external so you can hack it to munge its output for
special cases.
> I think that it could be hacked somehow with allowing a username of
> `bob' but somehow converting it internally to `alice:bob' if the key
> that gets used belongs to that Bob (rather than another `bob' who is
> in the dept). Getting https users too would be fun... (Actually,
> maybe it's easier than I imagine.)
Http is better; then you can devolve the whole thing to some central
LDAP, have apache use LDAP auth, and then everything *already* works.
Alice just has to do the http eqvt of 'ssh git@host perms + WRITERS
bobs-official-LDAP-name".
(Although, TBH, I have not really tested remote commands via http --
they work, but the "+" would be a challenge. Might have to URI-escape
it)
> Also, off-topic, but I can't help barfing here:
>
>> #
>> Eli Barzilay
>> April 22, 2012 8:54 PM
>>
>> Yeah, that isn't a big problem.
>> [...]
>> #
>> Sitaram Chamarty
>> April 22, 2012 8:25 PM
>> [...]
>
> Seriously??? There's an email client that intentionally takes my
> nicely formatted bottom-post email and butcher it into a top-post
> mess??? This is some kind of a new record in software being
> obnoxious, making you rewrite my emails. (No wonder it's coming from
> a Mac, and touted as "Awesome Email"...)
I've grown to hate Macs more than Windows, over the years. And I
would consider Stafford's response to you (in a later email, something
about pine) to be needlessly snarky, since he didn't append at least a
smiley.
Part of the reason I hate Macs is the attitude of people who use them.
Eli Barzilay
A few minutes ago, Stafford wrote:
>
> Gitlab allows users to manage their own pubkeys. However, speaking
> from experience (especially with Windows users), pubkeys are a royal
> pain when the user is not as proficient technically (among other fun
> issues with Git on Windows).
> [...] Also, gitlab does not support teams/organizations like
> a per-project basis and for occasional collaboration it supports
> pull requests.
such ad-hoc spontaneous projects.
> I think Github will be less of an administrative effort for you. I
> know they offer good (sometimes free) deals to academic
> institutions.
stuff, and if you don't mind the price or making it public, and if
your collaborators don't mind getting a GH account.
[OT resumed
> Sorry, didn't realize my client actually reformatted the sent
> emails, thought it was display only (I prefer my email threads
> top-down). Also, it doesn't look too bad on Google. Maybe you
> should try using something other than Pine.
horse has already died); (b) especially on gmail the email butchering
is bad since it's trying to look like gmail's layout, which ends up
being confusing; (c) No, I'm not using pine, I'm using a much more
powerful mail client, yet I *choose* to do email a certain way
(because chances are that I'm dealing with much more email than you
do).
]
Eli Barzilay
> On Mon, Apr 23, 2012 at 7:10 AM, Eli Barzilay <e...@barzilay.org> wrote:
> >
> > A good solution would make it possible for her to add a username
> > for Bob herself, where the username ends up being subbed from her
> > username somehow to avoid clashes. But I don't see an easy way to
> > do that, at least not without some made-up username like
> > `alice:bob' which will most likely confuse Bob and I end up with
> > complaints about stuff not working.
>
> Bob won't see that his user name is "alice:bob" unless he does
> "info". And in g3 that is external so you can hack it to munge its
> output for special cases.
needs to be some more functionality beyond the "info" munging:
probably something that does sanity checking for setting permissions,
maybe even with a reply that says how you can add a user if you name
someone who is unknown. And of course there should be some way for
Alice to add the account, and that might get a bit tricky with the
model of all key changes going through commits to the admin repo.
> > I think that it could be hacked somehow with allowing a username
> > of `bob' but somehow converting it internally to `alice:bob' if
> > the key that gets used belongs to that Bob (rather than another
> > `bob' who is in the dept). Getting https users too would be
> > fun... (Actually, maybe it's easier than I imagine.)
>
> Http is better; then you can devolve the whole thing to some central
> LDAP, have apache use LDAP auth, and then everything *already*
> works. Alice just has to do the http eqvt of 'ssh git@host perms +
> WRITERS bobs-official-LDAP-name".
> (Although, TBH, I have not really tested remote commands via http --
> they work, but the "+" would be a challenge. Might have to URI-escape
> it)
Eli Barzilay
things when I started playing with computers throughout the 80s,
indifferent to them throughout the 90s, then slowly moved from that to
actively disliking them. Active in the sense that I explain whenever
I can why buying apple products is bad.
> And I would consider Stafford's response to you (in a later email,
> something about pine) to be needlessly snarky, since he didn't
> append at least a smiley.
>
> Part of the reason I hate Macs is the attitude of people who use
> them.
ruby "brogrammers".
[checking]
Sure enough, "Web developer ... specializing in Ruby".
Eli Barzilay
> [off-list]
[Messed that up. Please avoid flaming.]
Stafford
Stafford
Sitaram Chamarty
> work with you to get it done. I do know that currently my interface
> supports nearly everything the gitolite.conf file supports (with a couple
> exceptions).
github; just to get a feel for what they're doing, and to see if I
could spot any gitolite issues (as opposed to gitlab issues) that
needed fixing.
I am reasonably sure I saw a thread that indicates that gitlab does
not use the power that gitolite provides (even if your gem allows it
to). I even remember seeing a strong "-1" (vote down) on that when
someone asked.
Stafford
Sitaram Chamarty
> Just now, Sitaram Chamarty wrote:
>> Http is better; then you can devolve the whole thing to some central
>> LDAP, have apache use LDAP auth, and then everything *already*
>> works. Alice just has to do the http eqvt of 'ssh git@host perms +
>> WRITERS bobs-official-LDAP-name".
>
> But that assumes that Bob is on the same LDAP DB no?
in the same university" (plus the assumption that every large
organisation has a central LDAP of some kind, which is not always true
but increasingly so). If you meant some random guy anywhere in the
world then I would be very wary of doing without all the "3-way email
handshake" authentication that any publicly accessible service
currently does.
Eli Barzilay
> On Mon, Apr 23, 2012 at 7:58 AM, Eli Barzilay <e...@barzilay.org> wrote:
> > Just now, Sitaram Chamarty wrote:
>
> >> Http is better; then you can devolve the whole thing to some central
> >> LDAP, have apache use LDAP auth, and then everything *already*
> >> works. Alice just has to do the http eqvt of 'ssh git@host perms +
> >> WRITERS bobs-official-LDAP-name".
> >
> > But that assumes that Bob is on the same LDAP DB no?
>
> Yes. I assume when you said "some random guy" it's "some random guy
> in the same university" (plus the assumption that every large
> organisation has a central LDAP of some kind, which is not always
> true but increasingly so).
would make it trivial. The reason this is easy is that the LDAP
server is essentially providing each person with a unique identity.
> If you meant some random guy anywhere in the world
*extremely* common.
> then I would be very wary of doing without all the "3-way email
> handshake" authentication that any publicly accessible service
> currently does.
to be manual. Every such person means that I need to mail them
instructions, and at that point I'm obviously the git guru in the
conversation so I need to explain things like why I need their public
key, how it should be used, etc etc. Later, if I want to GC old users
I need to explain to the people in the group that it doesn't mean that
anything is lost. All of that is a huge hassle. (Not in my case
though: since we're a research group, communication tends to be pretty
efficient; but if I was a sysadmin for a whole department, I can see
how this becomes too much to be practical.)
So as a dept sysadmin, I'd need to have a way of letting people choose
their collaborators and manage them themselves, otherwise I'd probably
just say that nobody from the outside is getting in. As for security,
it's up for the users to secure their own repos and not give random
people read permissions. I'd probably come up with some quota
facility to avoid obvious issues (and that's easy with some rule like
"repo CREATOR/.*"), but no need for anything other than that. (And
yes, I'm sure that in a commercial company sysadmins would not like
that -- but in those cases I expect that the "nobody else gets inside"
policy to be the common one, and an acceptable one.)
Sitaram Chamarty
> Two hours ago, Sitaram Chamarty wrote:
>> On Mon, Apr 23, 2012 at 7:58 AM, Eli Barzilay <e...@barzilay.org> wrote:
>> > Just now, Sitaram Chamarty wrote:
>> If you meant some random guy anywhere in the world
>
> That's exactly what I meant -- and in a CS department it is
> *extremely* common.
>
>
>> then I would be very wary of doing without all the "3-way email
>> handshake" authentication that any publicly accessible service
>> currently does.
>
> The problem is not in doing the handshake -- it's the fact that it has
> to be manual. Every such person means that I need to mail them
system. The kind that we're all used to from dealing with github etc.
You pass them a URL and that's basically it.
Why would it be any worse (in terms of the admin's time) than what
github does when you sign up?
> instructions, and at that point I'm obviously the git guru in the
the creds they now have. That's always going to be a problem but
teaching git is out of scope of this discussion. There's no finite
end to that...
> conversation so I need to explain things like why I need their public
> key, how it should be used, etc etc. Later, if I want to GC old users
> I need to explain to the people in the group that it doesn't mean that
> anything is lost. All of that is a huge hassle. (Not in my case
> though: since we're a research group, communication tends to be pretty
> efficient; but if I was a sysadmin for a whole department, I can see
> how this becomes too much to be practical.)
>
> So as a dept sysadmin, I'd need to have a way of letting people choose
> their collaborators and manage them themselves, otherwise I'd probably
> just say that nobody from the outside is getting in. As for security,
> it's up for the users to secure their own repos and not give random
> people read permissions. I'd probably come up with some quota
> facility to avoid obvious issues (and that's easy with some rule like
> "repo CREATOR/.*"), but no need for anything other than that. (And
> yes, I'm sure that in a commercial company sysadmins would not like
> that -- but in those cases I expect that the "nobody else gets inside"
> policy to be the common one, and an acceptable one.)
>
> --
> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
> http://barzilay.org/ Maze is Life!
Sitaram
Eli Barzilay
> On Mon, Apr 23, 2012 at 12:22 PM, Eli Barzilay <e...@barzilay.org> wrote:
> > Two hours ago, Sitaram Chamarty wrote:
> >> then I would be very wary of doing without all the "3-way email
> >> handshake" authentication that any publicly accessible service
> >> currently does.
> >
> > The problem is not in doing the handshake -- it's the fact that it
> > has to be manual. Every such person means that I need to mail
> > them
>
> I meant something along the lines of a web-based, self-service,
> system. The kind that we're all used to from dealing with github
> etc. You pass them a URL and that's basically it.
>
> Why would it be any worse (in terms of the admin's time) than what
> github does when you sign up?
Ah, in that case sure -- that would be the right thing. The question
is how hard it would be to implement such a thing. For example, the
obvious way of such a system editing and pushing a new gitolite config
file is not practical since then it becomes a potential security
hole. Doing some kind of a parallel system which can allow more
usernames in but not touch other stuff seems better, but not easy to
do.
And in case it's not clear -- it's not something that I need, just
something that would make such CS (and other) depts much happier about
embracing GL (and git).
Sitaram Chamarty
>
> 20 minutes ago, Stafford Brunk wrote:
> > [...] My environment is not as complicated as yours seems to be,
> > however.
>
> It's not really complicated -- it's just a common request that people
> tend to have frequently in a dept setting. Alice is a user in the
> dept who wants to work on a project (often a paper) with Bob who is
> from someplace else -- and to do that she has to ask me (the GL admin)
> to add a username for him. Now I need to find a good username for
from procmail that achieve a 3-way handshake -- at the end, you have
validated that whoever sent you the public key owns (or at least can
read/reply) the email address from which the key was first received.
The next step (which I did not do) would be to piggy-back on sskm and
add this "email confirmed" key as a "waiting to be added" key. Such a
key can only make it into the normal keydir only when someone runs
"ssh git@host sskm confirm-add" using the corresponding private key!
All without http ;-)
Eli Barzilay
>
> Just use the email address.
identify the outside user, and for this either an email or the public
key (or equivalent) work fine. But you also need to connect the
outside user with the inside user who granted access to the outsider.
The good "news" is that the sskm thing looks like it's doing that
nicely.
> I hacked a couple of scripts to be called from procmail that achieve
> a 3-way handshake -- at the end, you have validated that whoever
> sent you the public key owns (or at least can read/reply) the email
> address from which the key was first received.
automating the whole thing, though just the sskm thing looks fine too.
-- Just consider how the Alice/Bob interaction looks like: Alice asks
Bob for his public key, he mails it to her and she adds it, and after
that Bob needs to ssh to the server to confirm. Actually, I don't
think that there's any more security needed for this kind of
interaction: Bob authenticates himself using his private key which
should be secure enough.
> The next step (which I did not do) would be to piggy-back on sskm
> and add this "email confirmed" key as a "waiting to be added" key.
> Such a key can only make it into the normal keydir only when someone
> runs "ssh git@host sskm confirm-add" using the corresponding private
> key!
discussed but didn't connect the dots until now. After reading the
doc page, I think that it's not exactly the right thing for what I'm
talking about, but it's *very* close. Here's what I think should be
done to get it to what I'm talking about (which could come in addition
to sskm keys). I'll use `foo' for this imaginary new command. This
is going to be long, partly because I want to have a record of it in
case I try to implement it at some point.
* Each user has their main key as usual -- Alice has alice.pub, for
example. That key should not be editable by the `foo' script at
all -- changes to it should go via the GL admin. (And if this is
done in addition to sskm, then sskm could be used for such edits.)
* A user can add any random user as a subkey, for example, Alice would
add a key for Bob which would be called something like
"alice@@bob.pub". (Or some other separator, maybe "alice/bob.pub";
as long as it doesn't clash with the sskm keys.)
* As I said above, I don't think that there's any need for additional
security via a confirmation email, and I also don't think that
there's any need to confirm via ssh-ing with the new key. So the
new "alice@@bob.pub" key would be immediately active. Bob can now
log in as usual, including running git commands right away.
* Bob should have no power at all -- he should not be able to act with
the same privileges as Alice, which means that he can't access
internal repos that she has access to, he can't delete her key (with
sskm), he can't create new repos, and he can't invite other people
to the party. In short, "alice@@bob" should be treated as a new
unprivileged username, separate from "alice", and from "alice@foo"
if sskm is used. Unprivileged except for repos where it was added
by the owner.
The only thing that might be reasonable to allow is the ability to
change the "alice@@bob.pub" key. (There's no security issues here
either, IMO -- it's possible that someone hacked Bob's account, but
in that case the hacker could just as well fake emails from Bob, etc
-- so the usual ssh security issue about securing your private keys
hold.)
This is probably something that requires the biggest change to the
system. Hopefully g3 makes it possible to do with no changes to the
core, but the `foo' script itself would be quite different from
`sskm'.
* Alice should still have power over the key, specifically, she can
delete it any time she wants. Again, no need for confirmation --
the key is just deleted. There's no danger in that, since the `foo'
command is intended only for these sub-keys, so Alice's own key(s)
are fine. So "alice@@bob" is a new unprivilged user that is
different from "alice", but it's a user than can be deleted by her.
(IOW, this is another new concept in the system, and hopefully g3
can accomodate this, but maybe not.)
* The "alice@@bob" name (or whatever it is) should be almost
completely internal. The only place where it would be used is when
Alice adds the permission to her repos.
In addition, it's likely that some other insider (Charlie) knows Bob
and knows that Alice added him, so Charlie can use the "alice@@bob"
username for his repos. One option is to allow this; another is to
add some command so that Charlie can say "create a charlie@@bob key
which is the same as charlie@@alice". For what I'm talking about,
allowing it is a little better, since it's common to have some
project or paper who is written by all three people, so Bob doesn't
need to go through the hassle of two additions. But since either
Alice or Charlie must be the owner of the repo, then the owner can
just as well be the one who adds Bob, and the "copy key" command
could be used only if later on Charlie wants to work on something
with Bob and Alice is no longer involved.
* Finally, there are a bunch of obvious changes to the "sskm" script
when it's edited into "foo". For example, when Bob ssh's into the
machine, either directly or via git, he should be referred to as
"bob", not as "alice@@bob" and certainly not as "alice".
* There might be some other things that are needed -- maybe some
sanity check that makes sure that for all "foo@@bar" keys the "foo"
user exists, so if alice leaves it's possible to identify and remove
her dependencies.
I don't know how doable all of that is, but if/when I get to move to
g3, I'll probably be tempted to try. (But the combination of me &
Perl can be dangerous.)
Sitaram Chamarty
reference to this:
(1) usage:
# add a key
cat bob.pub | ssh git@host foo add b...@domain.com
# delete a key
ssh git@host foo del b...@domain.com
(2) pseudo code:
# prologue
check if $GL_USER starts with 'guest--'; if so, die.
clone the admin repo to a temp dir and cd to it.
if arg1 is 'add'
take STDIN and copy it to
keydir/zzz/guest-keys/alice/guest...@domain.com.pub
else if arg1 is 'del'
delete key of the same name as above
end
# epilogue
git add etc., then 'gitolite push'
(that's really all there is!)
(3) notes:
- the 'zzz' is to make sure these keys always appears after
"official" keys, in case someone is trying to DOS an
official user (intentionally or otherwise) by adding his key
with a different username, in such a way that it appears
earlier in the conf file.
Even if you think no one will do this, trust me you'll be
happy you prevented it :)
- the 'guest--' prefix is useful so that gitolite can quickly
disable some functions for such users, as in the first line
above.
Now to your email:
On Mon, Apr 23, 2012 at 08:25:27AM -0400, Eli Barzilay wrote:
> An hour ago, Sitaram Chamarty wrote:
> > I hacked a couple of scripts to be called from procmail that achieve
> Yeah, hooking that into a procmail script is an obvious ingredient of
> automating the whole thing, though just the sskm thing looks fine too.
> -- Just consider how the Alice/Bob interaction looks like: Alice asks
> Bob for his public key, he mails it to her and she adds it, and after
> that Bob needs to ssh to the server to confirm. Actually, I don't
> think that there's any more security needed for this kind of
> interaction: Bob authenticates himself using his private key which
> should be secure enough.
Do we not care about Alice impersonating Bob completely? Maybe
I'm being too paranoid...
> So I've looked at this sskm script, which I vaguely remember being
> discussed but didn't connect the dots until now. After reading the
> doc page, I think that it's not exactly the right thing for what I'm
> talking about, but it's *very* close. Here's what I think should be
I think they should be quite separate. I wouldn't even try to
mold sskm into "foo".
> done to get it to what I'm talking about (which could come in addition
> to sskm keys). I'll use `foo' for this imaginary new command. This
> is going to be long, partly because I want to have a record of it in
> case I try to implement it at some point.
> * Each user has their main key as usual -- Alice has alice.pub, for
> example. That key should not be editable by the `foo' script at
> all -- changes to it should go via the GL admin. (And if this is
Easy. All guest keys go in keydir/zzz/guest-keys/$GL_USER
(where GL_USER is the current user running the foo command), and
the main admins know not to fiddle with that.
Conversely, foo does not fiddle with anything outside that
space. So they're mutually exclusive in terms of key handling.
The names are also mutually exclusive due to the "guest--"
prefix (to prevent clashes with an "official" bob), as well as
bob having his full email address (to prevent clashes with
someone else's guest, also called Bob).
> done in addition to sskm, then sskm could be used for such edits.)
> * Bob should have no power at all -- he should not be able to act with
> the same privileges as Alice, which means that he can't access
> internal repos that she has access to, he can't delete her key (with
> sskm), he can't create new repos,
he can do all these things if "guest...@domain.com" is given
such permissions. If the admin is sane, he will never give any
permissions to any user whose name starts with "guest--".
That leaves only Alice, using "perms" to make him part of the
"READERS" or "WRITERS" list for some wild repo she owns.
He can also run the 'info' command. Most all other commands
would throw him out as being unauthorised but only because the
commands are checking permissions. You can't stop gitolite from
*running* those commands just because he's a guest user.
(I split your quoted sentence in the middle of a line here)
> and he can't invite other people
And *that* is where the first line of the pseudo code above
comes in.
> to the party. In short, "alice@@bob" should be treated as a new
> unprivileged username, separate from "alice", and from "alice@foo"
> if sskm is used. Unprivileged except for repos where it was added
> by the owner.
(via the perms command)
> The only thing that might be reasonable to allow is the ability to
> change the "alice@@bob.pub" key. (There's no security issues here
> either, IMO -- it's possible that someone hacked Bob's account, but
> in that case the hacker could just as well fake emails from Bob, etc
> -- so the usual ssh security issue about securing your private keys
> hold.)
>
> This is probably something that requires the biggest change to the
Why allow bob -- a guest -- to change his key? He has a
contact, alice. She already has the power to delete his key so
she can delete his current key and add it again.
Nothing wrong with what you suggest, but this should be rare
enough that my alternative is not a real hassle for anyone.
Keep "foo" simple.
> system. Hopefully g3 makes it possible to do with no changes to the
> core, but the `foo' script itself would be quite different from
> `sskm'.
> * Alice should still have power over the key, specifically, she can
> delete it any time she wants. Again, no need for confirmation --
> the key is just deleted. There's no danger in that, since the `foo'
> command is intended only for these sub-keys, so Alice's own key(s)
> are fine. So "alice@@bob" is a new unprivilged user that is
> different from "alice", but it's a user than can be deleted by her.
> (IOW, this is another new concept in the system, and hopefully g3
> can accomodate this, but maybe not.)
As we saw, this has nothing to do with gitolite per se.
Gitolite, when told to "compile" the conf, will just take all
the keys in keydir/, sort them by filename, and process them.
foo and sskm and such animals mangle keydir as they like and
then invoke the "compile" behaviour.
No changes to gitolite (even the older version; although the
mechanics of invoking the push on the server have changed).
> * The "alice@@bob" name (or whatever it is) should be almost
> completely internal. The only place where it would be used is when
> Alice adds the permission to her repos.
>
> In addition, it's likely that some other insider (Charlie) knows Bob
> and knows that Alice added him, so Charlie can use the "alice@@bob"
> username for his repos. One option is to allow this; another is to
> add some command so that Charlie can say "create a charlie@@bob key
> which is the same as charlie@@alice". For what I'm talking about,
> allowing it is a little better, since it's common to have some
> project or paper who is written by all three people, so Bob doesn't
> need to go through the hassle of two additions. But since either
> Alice or Charlie must be the owner of the repo, then the owner can
> just as well be the one who adds Bob, and the "copy key" command
> could be used only if later on Charlie wants to work on something
> with Bob and Alice is no longer involved.
All these name shenanigans go away if you use the guys full
email address, with guest-- prefixed.
Most important: even if Charlie *also* adds him, things work out
fine. (Otherwise Alice and Charlie have to co-ordinate who is
creating his id, and if both do it and with different userids he
loses the one which was alphabetically later!)
> * Finally, there are a bunch of obvious changes to the "sskm" script
> when it's edited into "foo". For example, when Bob ssh's into the
As I said, foo is quite distinct from sskm.
> machine, either directly or via git, he should be referred to as
> "bob", not as "alice@@bob" and certainly not as "alice".
The only time *any* user sees their name is when access is
denied to some resource, or when they run 'info'. Bob will see
"guest...@domain.com".
We could mangle 'info' to hide the "guest--" but we can't do
that to the part that generates the "... DENIED to
guest--bob@..." message -- that part is "core" gitolite.
(Well we can but we won't!)
> * There might be some other things that are needed -- maybe some
> sanity check that makes sure that for all "foo@@bar" keys the "foo"
> user exists, so if alice leaves it's possible to identify and remove
> her dependencies.
Since they're all in "zzz/guest-keys/alice", that's easy enough
to do.
> I don't know how doable all of that is, but if/when I get to move to
> g3, I'll probably be tempted to try. (But the combination of me &
> Perl can be dangerous.)
What makes you think you need perl to do all this? The only
time you *must* use perl in g3 is if you want to write "sugar"
(syntactic sugar helpers for the conf file parsing).
Everything else can be done in shell just as easily, which in
turn means (with slight adjustments) from any other language via
shell.
:-)
Eli Barzilay
> OK consider this pseudo code, then we'll get to your email with
> reference to this:
>
> (1) usage:
>
> # add a key
> cat bob.pub | ssh git@host foo add b...@domain.com
>
> # delete a key
> ssh git@host foo del b...@domain.com
(And *possibly* also
ssh git@host foo copy alice/b...@domain.com.pub
for Charlie. There's a minor issue of him discovering if Alice is
working with Bob, so yet another alternative is for Alice to do
ssh git@host foo copy-to charlie b...@domain.com.pub
which has the reverse issue of adding someone even if Charlie didn't
ask for it. Both are minor when you assume that the insiders are all
in the same dept.
But I think that it's likely that there's no need for all of this
anyway -- if we really don't want to avoid hassling Bob, then Alice
can send the public key to Charlie directly.)
> (2) pseudo code:
>
> # prologue
> check if $GL_USER starts with 'guest--'; if so, die.
> clone the admin repo to a temp dir and cd to it.
>
> if arg1 is 'add'
> take STDIN and copy it to
> keydir/zzz/guest-keys/alice/guest...@domain.com.pub
> else if arg1 is 'del'
> delete key of the same name as above
> end
>
> # epilogue
> git add etc., then 'gitolite push'
>
> (that's really all there is!)
>
> (3) notes:
>
> - the 'zzz' is to make sure these keys always appears after
> "official" keys, in case someone is trying to DOS an
> official user (intentionally or otherwise) by adding his key
> with a different username, in such a way that it appears
> earlier in the conf file.
>
> Even if you think no one will do this, trust me you'll be
> happy you prevented it :)
Oh, I'm certainly not doubting that such problems can happen
unintentionally... But let me clarify the problem since I'm not sure
that I have it right: the problem is that you can only identify people
based on the public key that they're using, therefore if Bob's public
key turns out to be identical to Dave's GL will end up mapping it to
"guest--bob..." thereby Dave loses his access. Is that right?
If so, then I can tell you exactly a common situation where this
happens: Bob works with Alice for a year, and then he moves into the
dept. The GL admin adds him as usual, yet he continues to have
limited access...
But I'll take your paranoia from such things and raise it: I dislike
relying on "zzz" being sorted last. In addition to being a hack (and
one that sounds obscure), there's always the chance of some smartass
who choses "zzz..." as their username. So instead (and assuming that I
got things right above), I'd rather see a test in `foo' that the newly
added public key doesn't already exist somewhere, if it does:
- with some non "guest--" prefix, then print back an error message
saying that the guy already has a "bob" account which you should
use instead.
- if it has a "guest--<different-email>" then barf about it. (And
to avoid revealing information, just put the error with the
offending key file in the log and refer the user to the GL admin.)
- if it has the correct email, just re-create the new one. This way
it'll be known in the system until all insiders remove it.
That still doesn't cover the above scenario, when Bob moves into the
dept. For that, I would like a similar test that happens when keys
are updated (which means in the post hook for the admin repo).
In such a case the admin can get an error, which he'd then resolve by
(for example) removing all "guest--bob@..." keys manually, and
possibly running something on the server that changes all occurrences
of that in permission files into "bob". That's not ideal, but it's
relatively rare.
IIUC, this test would need to be part of the core? Even if you did
add the option for a user hook for admin updates, it's something that
people will forget to add. But the test seems sane enough to have,
and is independent of this guest functionality. (Eg, someone decides
to change their username, I create a new file with the same public
key, and we're now in the same mess.)
With this, there's no need for the "zzz" hack. And it looks like sskm
is already doing something similar, and it won't be needed there too.
> - the 'guest--' prefix is useful so that gitolite can quickly
> disable some functions for such users, as in the first line
> above.
Yes, it serves the same role as "@@", and I completely agree that it
looks better.
> Now to your email:
>
> On Mon, Apr 23, 2012 at 08:25:27AM -0400, Eli Barzilay wrote:
> > An hour ago, Sitaram Chamarty wrote:
>
> > > I hacked a couple of scripts to be called from procmail that achieve
>
> > Yeah, hooking that into a procmail script is an obvious ingredient of
> > automating the whole thing, though just the sskm thing looks fine too.
> > -- Just consider how the Alice/Bob interaction looks like: Alice asks
> > Bob for his public key, he mails it to her and she adds it, and after
> > that Bob needs to ssh to the server to confirm. Actually, I don't
> > think that there's any more security needed for this kind of
> > interaction: Bob authenticates himself using his private key which
> > should be secure enough.
>
> Do we not care about Alice impersonating Bob completely? Maybe
> I'm being too paranoid...
I think that you'd worry about that if she can start messing around
with Bob's shared work on Charlie's repo -- but that would require
Bob's private key, so I don't think that there's anything to worry
about. Also, she could have interfered there if she removes Bob's key
and he can no longer work with Charlie -- but since they created a
guest-keys/charlie/guest---bob@... copy then that's not a problem
either.
> > So I've looked at this sskm script, which I vaguely remember being
> > discussed but didn't connect the dots until now. After reading
> > the doc page, I think that it's not exactly the right thing for
> > what I'm talking about, but it's *very* close. Here's what I
> > think should be
>
> I think they should be quite separate. I wouldn't even try to
> mold sskm into "foo".
Yeah, that was my guess. I just thought that basic operations could
be borrowed from it.
> > done to get it to what I'm talking about (which could come in addition
> > to sskm keys). I'll use `foo' for this imaginary new command. This
> > is going to be long, partly because I want to have a record of it in
> > case I try to implement it at some point.
>
> > * Each user has their main key as usual -- Alice has alice.pub, for
> > example. That key should not be editable by the `foo' script at
> > all -- changes to it should go via the GL admin. (And if this is
>
> Easy. All guest keys go in keydir/zzz/guest-keys/$GL_USER
> (where GL_USER is the current user running the foo command), and
> the main admins know not to fiddle with that.
>
> Conversely, foo does not fiddle with anything outside that
> space. So they're mutually exclusive in terms of key handling.
>
> The names are also mutually exclusive due to the "guest--"
> prefix (to prevent clashes with an "official" bob), as well as
> bob having his full email address (to prevent clashes with
> someone else's guest, also called Bob).
Yeah, all that makes sense. (The bit about identifying users via the
public key (which I forgot about earlier) makes it nice in having a
single "guest--some@email" be the identity regardless of being created
by whoever.)
> > done in addition to sskm, then sskm could be used for such edits.)
>
> > * Bob should have no power at all -- he should not be able to act with
> > the same privileges as Alice, which means that he can't access
> > internal repos that she has access to, he can't delete her key (with
> > sskm), he can't create new repos,
>
> he can do all these things if "guest...@domain.com" is given such
> permissions. If the admin is sane, he will never give any
> permissions to any user whose name starts with "guest--".
This sounds fine too. (In addition, I can see how some sysadmins
might want to give some priviliges to "guest--.*@our.own.domain"...)
> That leaves only Alice, using "perms" to make him part of the
> "READERS" or "WRITERS" list for some wild repo she owns.
>
> He can also run the 'info' command. Most all other commands
> would throw him out as being unauthorised but only because the
> commands are checking permissions. You can't stop gitolite from
> *running* those commands just because he's a guest user.
Yeah, all of that sounds fine too.
> > The only thing that might be reasonable to allow is the ability
> > to change the "alice@@bob.pub" key. (There's no security issues
> > here either, IMO -- it's possible that someone hacked Bob's
> > account, but in that case the hacker could just as well fake
> > emails from Bob, etc -- so the usual ssh security issue about
> > securing your private keys hold.)
> >
> > This is probably something that requires the biggest change to
> > the
>
> Why allow bob -- a guest -- to change his key? He has a contact,
> alice. She already has the power to delete his key so she can
> delete his current key and add it again.
Yes, that's why I said "might" in the above... But one thing to
consider here is what happens when he wants to do that change after he
was added by both Alice and Charlie. If the above check is in place,
then this is not a problem too -- when she adds the new key she'll get
an error, and will ask the GL admin to resolve it, and he can now
change the other key too, possibly confirming with Bob.
> Nothing wrong with what you suggest, but this should be rare enough
> that my alternative is not a real hassle for anyone. Keep "foo"
> simple.
Yes. (But note that the test that does complicate it a bit seems even
more important to me...)
> [...]
> No changes to gitolite (even the older version; although the
> mechanics of invoking the push on the server have changed).
Right -- I think that it's a cute result of letting the key directory
structure be open so that such utilities can do their own thing.
> [...]
> All these name shenanigans go away if you use the guys full
> email address, with guest-- prefixed.
>
> Most important: even if Charlie *also* adds him, things work out
> fine. (Otherwise Alice and Charlie have to co-ordinate who is
> creating his id, and if both do it and with different userids he
> loses the one which was alphabetically later!)
Right.
> The only time *any* user sees their name is when access is denied to
> some resource, or when they run 'info'. Bob will see
> "guest...@domain.com".
>
> We could mangle 'info' to hide the "guest--" but we can't do that to
> the part that generates the "... DENIED to guest--bob@..." message
> -- that part is "core" gitolite.
>
> (Well we can but we won't!)
I completely agree that it's better to show that.
> > * There might be some other things that are needed -- maybe some
> > sanity check that makes sure that for all "foo@@bar" keys the
> > "foo" user exists, so if alice leaves it's possible to identify
> > and remove her dependencies.
>
> Since they're all in "zzz/guest-keys/alice", that's easy enough to
> do.
Yeah, it's possible to consider this at the same level of removing her
repos too.
> > I don't know how doable all of that is, but if/when I get to move
> > to g3, I'll probably be tempted to try. (But the combination of
> > me & Perl can be dangerous.)
>
> What makes you think you need perl to do all this? The only time
> you *must* use perl in g3 is if you want to write "sugar" (syntactic
> sugar helpers for the conf file parsing).
>
> Everything else can be done in shell just as easily, which in turn
> means (with slight adjustments) from any other language via shell.
Sure -- I thought that more code would need to be borrowed from sskm,
and I thought that more core code might need to change. So far, it
looks like it's all simple to do in a shell script.
Sitaram Chamarty
> A few minutes ago, Sitaram Chamarty wrote:
> > (3) notes:
> >
> > - the 'zzz' is to make sure these keys always appears after
> > "official" keys, in case someone is trying to DOS an
> But I'll take your paranoia from such things and raise it: I dislike
> relying on "zzz" being sorted last. In addition to being a hack (and
> one that sounds obscure), there's always the chance of some smartass
> who choses "zzz..." as their username. So instead (and assuming that I
(1) no one can *choose* their username, not in gitolite anyway
(you may be thinking github and such?)
And why would someone *choose* a username that -- if this were
not handled properly -- would be *denied* access? Wouldn't they
choose "aaa" so they can deny someone else access?
(Plus if he's a smartass, do we really care?)
(2) Hack? Maybe. Obscure? Not at all.
The sort was added into the ssh-authkeys to allow people with
thousands of ssh keys to optimise their most frequent users to
the top, because sshd does a linear scan. It was designed to be
used thus, and zzz *will* go to the bottom.
> got things right above), I'd rather see a test in `foo' that the newly
> added public key doesn't already exist somewhere, if it does:
Sure. This assumes someone does not *preemptively* add a guest
key via foo, so the problem appears *later*, when the adds the
real user.
And sshkeys-lint does not run by default and catch these things
so you'd have to make that happen, then *remember to* look at
those errors. Every time you add a key.
And then you (the admin) would have to figure out if this was
unintentional or malicious, and based on that decide whom to
contact and how and how big of a LART you need to bring to the
meeting...
fun fun fun!
> - with some non "guest--" prefix, then print back an error message
> saying that the guy already has a "bob" account which you should
> use instead.
>
> - if it has a "guest--<different-email>" then barf about it. (And
> to avoid revealing information, just put the error with the
> offending key file in the log and refer the user to the GL admin.)
>
> - if it has the correct email, just re-create the new one. This way
> it'll be known in the system until all insiders remove it.
>
> That still doesn't cover the above scenario, when Bob moves into the
mine does cover that scenario. His guest userid becomes defunct
and his main one now works.
> dept. For that, I would like a similar test that happens when keys
> are updated (which means in the post hook for the admin repo).
> In such a case the admin can get an error, which he'd then resolve by
> (for example) removing all "guest--bob@..." keys manually, and
> possibly running something on the server that changes all occurrences
> of that in permission files into "bob". That's not ideal, but it's
> relatively rare.
yes; what I said above (before I read this).
> IIUC, this test would need to be part of the core? Even if you did
*Nothing* to do with ssh is part of core in g3 :-) Here's an
extract from the rc file:
# comment out or uncomment as needed
# these will run in sequence after post-update
POST_COMPILE =>
[
'post-compile/ssh-authkeys',
'post-compile/update-git-configs',
'post-compile/update-gitweb-access-list',
'post-compile/update-git-daemon-access-list',
],
The input condition is that the keys and conf files are
"checkout"-ed into ~/.gitolite/keydir and conf respectively.
You can add stuff before the first program if you wish, or
after. Or completely replace that first one with your own code;
gitolite doesn't care.
(Just don't do something that again clones the admin, makes
changes, and pushes back; you'll cause a loop unless you do some
fancy locking etc.)
> add the option for a user hook for admin updates, it's something that
> people will forget to add. But the test seems sane enough to have,
> and is independent of this guest functionality. (Eg, someone decides
> to change their username, I create a new file with the same public
> key, and we're now in the same mess.)
>
> With this, there's no need for the "zzz" hack. And it looks like sskm
Technically true. I still think zzz is better; too many things
to take care of otherwise.
But hey it's your code, so it's your call if you want to take
the scenic route around "zzz" ;-)
[We agree on most everything else so I snipped it all].
sitaram
Eli Barzilay
> On Mon, Apr 23, 2012 at 11:17:55AM -0400, Eli Barzilay wrote:
> > A few minutes ago, Sitaram Chamarty wrote:
>
> > > (3) notes:
> > >
> > > - the 'zzz' is to make sure these keys always appears after
> > > "official" keys, in case someone is trying to DOS an
>
> > But I'll take your paranoia from such things and raise it: I dislike
> > relying on "zzz" being sorted last. In addition to being a hack (and
> > one that sounds obscure), there's always the chance of some smartass
> > who choses "zzz..." as their username. So instead (and assuming that I
>
> (1) no one can *choose* their username, not in gitolite anyway
> (you may be thinking github and such?)
>
> And why would someone *choose* a username that -- if this were
> not handled properly -- would be *denied* access? Wouldn't they
> choose "aaa" so they can deny someone else access?
>
> (Plus if he's a smartass, do we really care?)
I'm talking about a different kind of smartassness... Users choosing
weird usernames "for fun". (I once had a student who used something
like "FooTheGreat" as a username, later he couldn't submit homework
because he kept trying "foothegreat"...)
It's true that the GL admin needs to add the main names, but in a dept
situation it would be crazy to use different usernames than what they
have, and in any case the GL admin is likely to not remember that such
usernames are problematic.
> (2) Hack? Maybe. Obscure? Not at all.
>
> The sort was added into the ssh-authkeys to allow people with
> thousands of ssh keys to optimise their most frequent users to
> the top, because sshd does a linear scan. It was designed to be
> used thus, and zzz *will* go to the bottom.
No problems with sorting in general -- it's fine for sanity (avoid
weirdness when file entries are sorted differently on disk), and it's
fine for optimization. Using them as a feature is what's bad. (I
have yet to see any system with names as features that didn't hold up.
/etc/rc is probably the best example for something that exploded in a
huge flame. (And still burning, AFAICT...))
> > got things right above), I'd rather see a test in `foo' that the
> > newly added public key doesn't already exist somewhere, if it
> > does:
>
> Sure. This assumes someone does not *preemptively* add a guest key
> via foo, so the problem appears *later*, when the adds the real
> user.
Yes, that's exactly the situation that I mentioned, and exactly why I
said that the test should be done when in the hook for the admin repo.
> And sshkeys-lint
Ah, it's already there...
> does not run by default and catch these things so you'd have to make
> that happen, then *remember to* look at those errors. Every time
> you add a key.
...right -- again, I would really like to see this running in a hook
to avoid bogus pushes. (Which are already possible.)
> And then you (the admin) would have to figure out if this was
> unintentional or malicious, and based on that decide whom to contact
> and how and how big of a LART you need to bring to the meeting...
(Yeah, that's exactly why I want to run that check early, avoiding
such problems in the first place.)
> > - with some non "guest--" prefix, then print back an error message
> > saying that the guy already has a "bob" account which you should
> > use instead.
> >
> > - if it has a "guest--<different-email>" then barf about it. (And
> > to avoid revealing information, just put the error with the
> > offending key file in the log and refer the user to the GL admin.)
> >
> > - if it has the correct email, just re-create the new one. This way
> > it'll be known in the system until all insiders remove it.
> >
> > That still doesn't cover the above scenario, when Bob moves into the
>
> mine does cover that scenario. His guest userid becomes defunct
> and his main one now works.
It doesn't because he lost his access to the work he did with Alice.
He'll complain to her, and she'll swear that she didn't touch
anything... (I'm talking about real people here -- I'm *sure* that
this exact thing is an extremely likely way it will go.)
> > dept. For that, I would like a similar test that happens when
> > keys are updated (which means in the post hook for the admin
> > repo). [...]
(That should have been *pre*.)
> > IIUC, this test would need to be part of the core? Even if you did
>
> *Nothing* to do with ssh is part of core in g3 :-) Here's an extract
> from the rc file:
>
> # comment out or uncomment as needed
> # these will run in sequence after post-update
> POST_COMPILE =>
> [
> 'post-compile/ssh-authkeys',
> 'post-compile/update-git-configs',
> 'post-compile/update-gitweb-access-list',
> 'post-compile/update-git-daemon-access-list',
> ],
Um, so that's much better -- even if you insist on not having the lint
check by default[*], then you can add the lint line there and have it
commented out. If your issue with this is that the current
sshkeys-lint can't be used as is there, I will be very happy to make a
version that does work, use it for a while, and report back when it
looks fine.
[*] I really, *REALLY*, don't see any reason to not add such sanity
checks that are cheap in the time the take, and can potentially save a
ton of time sorting out the mess later. (I almost never use all-caps,
BTW.)
> [...] But hey it's your code, so it's your call if you want to take
> the scenic route around "zzz" ;-)
(To make that "*REALLY*" even more capitalized, IMO you should have an
even better motivation for detecting such problems as soon as
possible, since they can easily make people come here and complain
that GL is broken in some way. A quick grep for "gitolite" and "lint"
through my mailbox shows 20 threads -- that's a lot of text... I
imagine that if the lint was is done on every commit to the admin
repo, you'd have saved yourself a bunch of time with these messages.)
Sitaram Chamarty
> that GL is broken in some way. A quick grep for "gitolite" and "lint"
> through my mailbox shows 20 threads -- that's a lot of text... I
> imagine that if the lint was is done on every commit to the admin
> repo, you'd have saved yourself a bunch of time with these messages.)
ignorance during *install*, affecting admin key/first clone of admin
repo.
Which does get checked now (in g3, as well as toward the end of the g2
dev timeline).
There's also https://github.com/sitaramc/gitolite/blob/master/src/VREF/DUPKEYS,
which I completely forgot about! Duh!
Sitaram Chamarty
> There's also https://github.com/sitaramc/gitolite/blob/master/src/VREF/DUPKEYS,
> which I completely forgot about! Duh!
which hasn't been tested; I now see old variables mixed in with new
(g3) stuff! Uggh...
Maybe tomorrow :-(
--
Sitaram
Eli Barzilay
> On Mon, Apr 23, 2012 at 10:26 PM, Eli Barzilay <e...@barzilay.org> wrote:
>
> > that GL is broken in some way. A quick grep for "gitolite" and
> > "lint" through my mailbox shows 20 threads -- that's a lot of
> > text... I imagine that if the lint was is done on every commit to
> > the admin repo, you'd have saved yourself a bunch of time with
> > these messages.)
>
> I can't recall a single time when it was something other than ssh
> ignorance during *install*, affecting admin key/first clone of admin
> repo. Which does get checked now (in g3, as well as toward the end
> of the g2 dev timeline).
when possible... I offered to implement it (which seem potentially
trivial if the script already does work), and test it -- not much else
that I can do. (Maybe set up a mailing list monitor that will post a
link to http://www.youtube.com/watch?v=rX7wtNOkuHo when it comes up?)
> There's also
> https://github.com/sitaramc/gitolite/blob/master/src/VREF/DUPKEYS,
> which I completely forgot about! Duh!
default, or include it in a template config?)
Sitaram Chamarty
> 20 minutes ago, Sitaram Chamarty wrote:
>> On Mon, Apr 23, 2012 at 10:26 PM, Eli Barzilay <e...@barzilay.org> wrote:
>>
>> > that GL is broken in some way. A quick grep for "gitolite" and
>> > "lint" through my mailbox shows 20 threads -- that's a lot of
>> > text... I imagine that if the lint was is done on every commit to
>> > the admin repo, you'd have saved yourself a bunch of time with
>> > these messages.)
>>
>> I can't recall a single time when it was something other than ssh
>> ignorance during *install*, affecting admin key/first clone of admin
>> repo. Which does get checked now (in g3, as well as toward the end
>> of the g2 dev timeline).
>
> Well, I still think that there's no reason to do more sanity checks
> when possible... I offered to implement it (which seem potentially
> trivial if the script already does work), and test it -- not much else
> that I can do. (Maybe set up a mailing list monitor that will post a
> link to http://www.youtube.com/watch?v=rX7wtNOkuHo when it comes up?)
happened, I will:
(a) reply to him with [1], telling him to see the second example and
(b) reply to you with [2], pointing out the very first line, and then
possibly the section "so you're basically saying you won't support
'X'".
:-)
[1]: http://sitaramc.github.com/gitolite/vref.html
[2]: http://sitaramc.github.com/gitolite/auth.html
>> There's also
>> https://github.com/sitaramc/gitolite/blob/master/src/VREF/DUPKEYS,
>> which I completely forgot about! Duh!
>
> (Even better... It's implemented twice, why not just make it on by
> default, or include it in a template config?)
lint program is 150+ lnes of perl. I'd hardly call them equivalent,
let alone implemented twice.
I would *still* place all user-generated keys (whether by sskm or foo)
into zzz. Doing so lets the admin not really care about those keys
because they will never interfere with his "official" ones, and to
deal with problems, if any, on a non-urgent basis ("I don't care; I'll
get to it when I get to it").
This (i.e., dealing with problems on a non-urgent basis) is also the
reason why the dupkeys vref is not the default. If someone complains,
you run lint, use its nice/detailed output to see what happened, and
send off emails to the appropriate people. The actual resolution only
happens after they reply.
Meanwhile your admin push for other, unrelated, changes is not held up.