GoOSe Join Process
Clint Savage
After conversations with Ivan, Mike, and Derek last night and this
morning, I've come up with a fairly simple Join process. On the new
contributor side, they simply follow the READE.rst on
https://github.com/gooseproject/join. Once complete, they will submit
a pull request, which can then be easily merged into the repository.
While there are several steps that need to happen after the merge is
complete, like adding the new contributor to the GoOSe Team, another
issue is on my mind. Managing ssh public keys will be necessary for
these users to access other parts of the project. Derek and I
discussed having the contributor also submit a public key in their git
fork and pull request. While I'm not opposed to this idea since a
public key is 'public' and supposed to be shared. I'm not sure how
ours or other communities feel about placing public ssh keys into the
open.
What are your thoughts regarding this issue? I think we're open to any
alternate suggestions as well, as long as it's something that is
simple and easy to do for both the new contributor and those that have
to process and place the keys.
Cheers,
Clint
Derek Carter
> What are your thoughts regarding this issue? I think we're open to any
> alternate suggestions as well, as long as it's something that is
> simple and easy to do for both the new contributor and those that have
> to process and place the keys.
What if we encouraged the creation of a GoOSe specific key. (there's not
really any way of enforcing this I don't think).
What are the other policies we need to worry about?
* key type/size
* removal/key invalidation
Any others?
--
Derek
aka goozbach
Clint Savage
Well, we had a bit of a conversation in IRC today about this, here's the notes:
10:59 < albino> ssh keys are public, post them everywhere
11:07 < makfinsky> Even though public keys are called PUBLIC for a
good reason, there will be folks out there who will complain. It
becomes a question of how much, or how little, time we want to spend
attempting to educate those folks.
11:07 < makfinsky> If we ignore too many of them, it *could* have
negative consequences for the project. I just don't know how much and
of what kind.
11:08 < makfinsky> I don't think it'll look badly on the project, per
say.
11:09 < makfinsky> More like it'll turn off those of us that are
spending time contributing and trying to educate those, which might
give the impression that we don't care about *new* folks if we begin
ignoring them because we are burnt out on helping folks who don't know
what *public* means.
11:09 < makfinsky> Vicious circle type situation.
11:10 < makfinsky> Other than the above argument, I'm all for public
keys being posted publicly. They can only be used by a malicious
person to give ME access to THEIR systems.
11:24 <@herlo> my one big argument is to the malicious folks.
11:25 <@herlo> Because we have public keys posted in a public place,
they may have more intent to obtain our private keys and possibly hack
into our systems.
11:25 <@herlo> While I see this as a low probability
11:25 <@herlo> I do see that if someone does somehow accidentally
publish their private key, we may be in a world of hurt
11:26 <@herlo> it might be a good idea to gpg-encrypt the keys in the
git repo
11:27 <@herlo> we have a GoOSe gpg key which we publish the public
version and that way there is only one place where risk
lies and its within the project itself, not on the individual users.
11:27 <@herlo> makfinsky: goozbach: what think you of that?
11:29 < makfinsky> Hmm, you make a valid point about users publishing
private keys by default.
11:29 <@herlo> well, in the git pull request, if they do it wrong,
we're screwed
11:29 < makfinsky> Even with a goose gpg key, they might still publish
private keys by default, without gpg encrypting.
11:29 <@herlo> we'd have to reject it
11:29 < makfinsky> Right.
11:29 <@herlo> and force them to use another
11:30 < makfinsky> They've still published a private key to the world.
11:30 <@herlo> yeah, but it won't be in our servers if we do things properly
11:32 <@herlo> makfinsky: so I'm thinking more and more about a
private repository that can be cloned and some sort of
encrypted process of uploading keys.
11:32 <@herlo> but it means we have to maintain that...
11:33 < makfinsky> I think we'll have to maintain the user db no
matter what we do.
11:33 <@herlo> well, I don't
11:33 < makfinsky> Unless we decide to trust something like oauth.
11:33 <@herlo> I think we'll have to maintain a semblance of a user
db. Something like what gitolite does would suffice
11:34 < makfinsky> Well, even then, we need to be able to maintain who
is authorized to login.
11:34 <@herlo> that's on the github side
11:34 < makfinsky> Not a userdb in the traditional sense, a list of
who's allowed.
11:34 < makfinsky> Right.
11:34 <@herlo> so my thought was more like having each person commit a
ssh key to a private git repo somehow
11:35 <@herlo> each person names their key <gh-username>.pub
11:36 <@herlo> and it corresponds to the GoOSe group username
11:36 <@herlo> s/group/team
11:38 < makfinsky> The first part is the trickier part. How do we
manage that as an *open* project?
11:39 <@herlo> there isn't a requirement to make sure security is open
11:39 <@herlo> only that people we trust can get into the security
area and contribute
11:40 < makfinsky> Ok, I'll go with that.
11:40 <@herlo> :P It's the same mantra used in Fedora Infrastructure
11:40 <@herlo> they have apprentices now, which is how you get to the
trusted point. It really doesn't take long if you are driven and
smart.
11:41 < makfinsky> Gotcha.
Other thoughts?