| 03:47.00 | *** join/#utos josePHPagoda (~josePHPag@24-116-177-210.cpe.cableone.net) |
| 04:44.03 | *** join/#utos mindjuju (~mindjuju@173-10-26-193-BusName-utah.ut.hfc.comcastbusiness.net) |
| 04:44.03 | *** join/#utos Nafai (~nafai@travishartwell.net) |
| 04:44.04 | *** join/#utos goozbach (~goozbach@fedora/goozbach) |
| 04:44.04 | *** join/#utos herlo (~clints@fedora/herlo) |
| 04:44.04 | *** mode/#utos [+o herlo] by niven.freenode.net |
| 13:10.45 | *** join/#utos bmac2 (~bmac2@63.230.14.10) |
| 13:10.45 | *** join/#utos Tungsten_Jack (~Tungsten_@pdpc/supporter/active/jnbek) |
| 14:17.22 | *** join/#utos redbeard2 (~jphall@173-10-19-106-BusName-utah.ut.hfc.comcastbusiness.net) |
| 14:19.06 | *** join/#utos fugue88 (~dsowen@173-165-137-65-utah.hfc.comcastbusiness.net) |
| 14:24.52 | *** join/#utos josePHPagoda (~josePHPag@24-116-177-210.cpe.cableone.net) |
| 14:50.33 | *** join/#utos sinuhe (~sinuhe@ip65-44-231-178.z231-44-65.customer.algx.net) |
| 15:12.15 | *** join/#utos macnewbold (~Adium@76.8.223.101) |
| 15:18.41 | *** join/#utos redbeard2 (~jphall@BEYOND-OBLI.car1.SaltLakeCity1.Level3.net) |
| 15:19.41 | *** join/#utos littleidea (~littleide@pool-72-95-239-40.pitbpa.east.verizon.net) |
| 15:20.53 | *** join/#utos mindjuju (~mindjuju@173-10-26-193-BusName-utah.ut.hfc.comcastbusiness.net) |
| 16:09.38 | *** join/#utos cro (~cro@204-228-149-217.ip.xmission.com) |
| 16:10.05 | *** join/#utos xtrementl (~xtrementl@neutroninteractive-xmission.xmission.com) |
| 17:47.20 | *** join/#utos josePHPagoda (~josePHPag@24-116-177-210.cpe.cableone.net) |
| 19:04.12 | herlo | josePHPagoda: ping |
| 19:06.50 | josePHPagoda | herlo: pong! |
| 19:07.44 | herlo | josePHPagoda: hi |
| 19:07.57 | josePHPagoda | you pinged me? |
| 19:08.01 | josePHPagoda | :D |
| 19:08.08 | herlo | I did |
| 19:08.25 | herlo | have an interesting question for you, and possibly anyone else in this group |
| 19:08.28 | josePHPagoda | kk |
| 19:08.29 | herlo | s/group/channel/ |
| 19:08.49 | herlo | The question has a bit of explanation before it |
| 19:09.13 | josePHPagoda | no time like the now |
| 19:09.16 | josePHPagoda | :D |
| 19:09.36 | herlo | First off, as you know, we are working on GoOSe Project using github as our main point for repos, issues and even their wiki in places |
| 19:09.59 | herlo | we're using github pages to create our new gooseproject.org site and a bunch of other tools, like skein, chase and grapple |
| 19:10.24 | josePHPagoda | aight |
| 19:10.27 | herlo | in our quest to gain more contributors, we wanted to make it easy for them to join and get involved |
| 19:10.34 | herlo | so we came up with a simple schema to join |
| 19:10.51 | herlo | first, fork the https://github.com/gooseproject/join repository |
| 19:11.01 | herlo | second, add your contributor information to the contrib file |
| 19:11.07 | herlo | thrid, submit a pull request |
| 19:11.14 | josePHPagoda | kk |
| 19:11.33 | herlo | after submitting, we will add the user (manually currently) to the GoOSe github team |
| 19:11.37 | herlo | but |
| 19:11.48 | herlo | we also want to have them provide a ssh public key |
| 19:12.01 | herlo | and this is where our dilemma starts |
| 19:12.23 | herlo | one thought was to just have them upload their public key to the join repo in a keys/ directory |
| 19:12.32 | herlo | and that would be all well and good |
| 19:12.42 | herlo | except that people are human, and make mistakes |
| 19:13.06 | josePHPagoda | you could have them email the private key? |
| 19:13.08 | herlo | some would accidentally or unknowingly upload their private key |
| 19:13.14 | herlo | josePHPagoda: hang on |
| 19:13.16 | josePHPagoda | :-P |
| 19:13.23 | josePHPagoda | (whoops, i said private... now I feel evil) |
| 19:13.31 | herlo | with the same fork and pull request process |
| 19:14.04 | herlo | once they perform a push to their fork, the private key is public and for all intents and purposes compromised |
| 19:14.30 | herlo | another thought was to create a goose gpg key and have each contributor encrypt their pubkey with that and commit the values tha tway |
| 19:15.16 | herlo | and in another conversation, having contributors email their key was brought up. But that way doesn't scale too well unless we write a bunch of hooks to verify and push the keys |
| 19:15.34 | herlo | josePHPagoda: so I ask you (and anyone else here) for thoughts on the process. |
| 19:15.54 | herlo | josePHPagoda: specifically I ask you because I wanted to know how pagodabox does ssh key management for your systems |
| 19:17.22 | josePHPagoda | ah |
| 19:17.28 | josePHPagoda | we actually have a db with all of the keys in it |
| 19:17.36 | josePHPagoda | and we modified our ssh server to auth against that db |
| 19:17.36 | herlo | a real db? |
| 19:17.41 | josePHPagoda | yeah |
| 19:17.45 | herlo | wow |
| 19:17.51 | josePHPagoda | why wow? |
| 19:18.06 | herlo | so your users create a pagodabox account, and upload their ssh keys how? |
| 19:18.14 | josePHPagoda | right now, they don't |
| 19:18.18 | josePHPagoda | this is all in preperation |
| 19:18.23 | josePHPagoda | it's very similar to how github does it though |
| 19:18.47 | herlo | hmm, gh does it by having them copy/paste the key into the user's account |
| 19:18.52 | josePHPagoda | yeah |
| 19:18.57 | josePHPagoda | you could also have them browse to the file |
| 19:19.02 | josePHPagoda | and verify that it isn't in .pub |
| 19:19.04 | josePHPagoda | if you really wanted to |
| 19:19.12 | herlo | which is what we want to have, but those aren't for the organization to see. If it was, I think life would be much simpler. |
| 19:19.29 | josePHPagoda | err... i mistyped |
| 19:19.33 | josePHPagoda | but I think you understand |
| 19:19.44 | herlo | no, I'm confused actually by your statement |
| 19:20.02 | josePHPagoda | you could have them browse to the file and upload it, and only let them upload files ending in.pub |
| 19:20.17 | josePHPagoda | to help ensure to accidental private keys being uploaded |
| 19:20.21 | herlo | josePHPagoda: I think the verification process isn't the problem |
| 19:20.33 | herlo | it's the simplicity and trying to avoid reinventing the wheel |
| 19:20.41 | josePHPagoda | yeah |
| 19:21.04 | herlo | as it is, contributors are going to have to upload their key to github and to goose in some fashion |
| 19:21.13 | josePHPagoda | yeah |
| 19:21.50 | herlo | which isn't ideal to me, but seems like we can't avoid it |
| 19:22.26 | herlo | fedora does this with the Fedora Account System (fas) |
| 19:22.39 | herlo | but it seems like overkill for us |
| 19:22.44 | herlo | at least for now |
| 19:23.00 | josePHPagoda | yeah |
| 19:24.19 | herlo | josePHPagoda: I'm kind of leaning toward the gpg-encrypted-armored solution |
| 19:24.36 | josePHPagoda | hmm |
| 19:25.53 | herlo | it makes it secure enough to put on a github public repo, meaning that the only way to obtain said public keys (which really wouldn't be at risk as long as the corresponding private key isn't compromised) would be to have the gpg private key which only goose core would have, or something like that |
| 19:29.04 | josePHPagoda | damage control in the event of a key leakage would be a pain though |
| 19:29.07 | josePHPagoda | really really really messy |
| 19:29.37 | josePHPagoda | but I dunno |
| 19:29.53 | josePHPagoda | if I'm understanding this right, the only way it could be leaked is if someone accidentally grabbed the wrong key yes? |
| 19:32.22 | herlo | no |
| 19:32.43 | herlo | only if someone compromised both the private gpg key owned by goose AND the private ssh key owned by a contributor |
| 19:32.57 | herlo | both of which should be kept private |
| 19:34.20 | herlo | josePHPagoda: there is a possibility still that individuals will not follow instructions, but I don't think you can prevent against that completely |
| 19:35.41 | fugue88 | s/possibility/certainty/ |
| 19:35.56 | herlo | lol |
| 19:36.04 | herlo | fugue88: do you have any thoughts on this? |
| 19:36.27 | goozbach | gpg + armor |
| 19:36.31 | goozbach | my vote |
| 19:36.32 | fugue88 | Nope. I haven't really read any of this. Just enough to interject snarky comments. |
| 19:36.33 | herlo | goozbach: for sure |
| 19:36.56 | herlo | goozbach: it is the same convo being had in #gooseproject, just looking for alternate perspectives |
| 19:37.12 | fugue88 | I can read it in a bit, if you want. |
| 19:37.17 | herlo | sure |
| 19:37.21 | herlo | always looking for input |
| 19:37.38 | herlo | goozbach: that's the direction I'm leaning |
| 19:40.41 | fugue88 | herlo: Yeah, accidental exposure of private key material is bad. :( |
| 19:40.48 | herlo | indeed |
| 19:40.55 | fugue88 | I like e-mail stuff, then at leasts things stay mostly-private. |
| 19:41.15 | fugue88 | I think on either SSH or GPG keys you ought to be able to tell automatically whether you got a public or private key. |
| 19:41.43 | fugue88 | It *is* one extra step (and the github pull request is *cool* thinking), but it's also fairly easy and 1-time. |
| 19:41.47 | herlo | email doesn't scale so well though after about 10 a day |
| 19:42.05 | fugue88 | Less well than dealing with pull requests? |
| 19:42.17 | herlo | pull requests are git pull <url> master |
| 19:42.28 | herlo | and it already comes through an email |
| 19:42.41 | herlo | but I only have to read that there is one and perform a simple task |
| 19:43.13 | fugue88 | What about setting up a simple web form, wherein they can paste their key? |
| 19:43.24 | fugue88 | LP does that. |
| 19:43.29 | fugue88 | LP=Launchpad. |
| 19:44.03 | herlo | fugue88: yeah, in fact github does that |
| 19:44.17 | herlo | I just wish we could grab the key for users in our org directly from github |
| 19:44.38 | herlo | fugue88: it's still on my list of ideas, but I am hoping to avoid using other infrastructure |
| 19:44.49 | fugue88 | While encrypting to a goose key is also cool, if you can trust your contributors to do that correctly, you can trust them to get their public key correctly. |
| 19:45.25 | fugue88 | As in, you'd probably get people who forget to encrypt to the goose key. *And* maybe also send in their private key. |
| 19:45.37 | herlo | fugue88: true, but at least with an additional gpg encryption, we can better protect ourselves from compromise |
| 19:46.08 | herlo | not so much on the 'can a contributor do the right thing' as much as 'what if their machines is compromised' front |
| 19:46.32 | fugue88 | So, protecting goose if the contributor's machine is compromised? |
| 19:46.39 | fugue88 | hmm... |
| 19:47.14 | fugue88 | I don't see how having public ssh/gpg keys encrypted to a public goose key for a join-the-project-pull request helps with that. |
| 19:47.32 | fugue88 | But I'm also not familiar with github. |
| 19:48.21 | herlo | well, the ssh pubkey is the contributors |
| 19:48.30 | herlo | the gpg would be goose's pubkey |
| 19:48.52 | herlo | and we'd gpg encrypt the ssh pubkey with the goose gpg-pubkey |
| 19:49.28 | fugue88 | Yep, I'm still not seeing the aforementioned benefit. |
| 19:49.45 | herlo | um |
| 19:49.55 | herlo | so it's all in a public git repo |
| 19:50.19 | fugue88 | Let me put it this way. |
| 19:50.29 | herlo | isn't sure what fugue88 is getting at yet |
| 19:50.32 | fugue88 | Assume their public ssh keys are left in the repo, unencrypted. |
| 19:50.40 | fugue88 | Then, a developer's machine is compromised. |
| 19:50.47 | fugue88 | What's the attack vector you're worried about? |
| 19:51.20 | herlo | well, if their machine is compromised and someone wants to do malicious things to the goose servers where the corresponding public lives... |
| 19:51.35 | herlo | they NOW CAN!! </scary voice> |
| 19:51.48 | fugue88 | How does having an unencrypted public ssh key in the repo give the attacker access to anything? |
| 19:52.35 | herlo | fugue88: because the point of having the ssh pubkey in the repo is only the first step to gaining access to goose's servers. We will be taking those and distributing them at some point into places so the contributor can access certain machines |
| 19:53.07 | fugue88 | But, the repo itself isn't the weakness? |
| 19:53.08 | herlo | once the ssh pubkey is on a goose server, whoever has the private key can now access |
| 19:53.47 | herlo | fugue88: correct. There's a fairly common standard however, to not directly publicize the pubkey even though it's said it can be public |
| 19:53.57 | herlo | standard may not be the right word |
| 19:54.13 | fugue88 | herlo: Oh, I see. |
| 19:54.35 | fugue88 | Having the unencrypted public key in a public repo tells attackers where to focus their efforts in compromising developer machines. |
| 19:54.38 | fugue88 | Right? |
| 19:54.45 | herlo | aye |
| 19:54.48 | *** join/#utos mindjuju (~mindjuju@173-10-26-193-BusName-utah.ut.hfc.comcastbusiness.net) |
| 19:54.48 | fugue88 | Weak. |
| 19:54.53 | fugue88 | They can watch the mailing list. |
| 19:54.58 | fugue88 | ;P |
| 19:55.09 | herlo | lol, if we did it by email, it wouldn't be to a ml |
| 19:55.32 | fugue88 | No, the project mailing-list. They'll see who's participating anyway, by watch the project ml. |
| 19:55.50 | herlo | fugue88: true, but then they have to have two private keys, not just one |
| 19:55.56 | fugue88 | Why two? |
| 19:56.06 | herlo | ssh private key, and gpg private key |
| 19:56.11 | herlo | one from the contributor, one from goose |
| 19:56.17 | fugue88 | Why would they need a private gpg key? |
| 19:56.26 | herlo | to decrypt the gpg encrypted ssh key |
| 19:56.43 | herlo | how else would you decrypt a gpg encrypted bit of text? |
| 19:56.44 | fugue88 | Why would they need to decrypt a public ssh key? |
| 19:56.49 | fugue88 | herlo: heheheh |
| 19:56.55 | herlo | same point I made amoment ago |
| 19:56.59 | fugue88 | I don't think it is. |
| 19:57.11 | herlo | but it is |
| 19:57.20 | herlo | let's back up just a bit |
| 19:57.21 | fugue88 | The point you made is that the unencrypted keys in the repo form a directory, where an attacker can see who the devs are. |
| 19:57.30 | herlo | that is *one* point |
| 19:57.34 | fugue88 | So they know whose personal machines to attack. |
| 19:57.38 | herlo | true |
| 19:57.47 | fugue88 | But that same participation directory is available publicy in several other places. |
| 19:57.59 | fugue88 | No use plugging one source unless you plug them all. |
| 19:58.06 | herlo | hmm |
| 19:58.56 | herlo | the point I was getting at was that the gpg encryption would be just another layer, but you are saying that if the contributor is compromised we are screwed anyway |
| 19:59.03 | fugue88 | Right. |
| 19:59.05 | herlo | can see that now |
| 19:59.20 | herlo | which is why it's good to have this conversation :) |
| 20:00.40 | herlo | fugue88: so it seems that pushing the ssh key to a public location isn't the problem |
| 20:00.55 | herlo | but I don't think we can prevent the other problem |
| 20:01.11 | fugue88 | other problem being accidentally pusing an *private* ssh key? |
| 20:01.15 | herlo | we can mitigate it |
| 20:01.27 | herlo | fugue88: well, there's that |
| 20:01.33 | herlo | which is another concern altogether |
| 20:01.59 | herlo | and the gpg encryption would prevent, but if they can't push a ssh pubkey in the first place, they may not do the encryption properly |
| 20:02.10 | herlo | heroku deals with this by looking only in certain places |
| 20:02.34 | herlo | so writing a little tool to do it might be possible as well. |
| 20:03.02 | herlo | and using a simple form to post might also be viable |
| 20:15.31 | goozbach | having a pre-recieve hook check to see if it's a pubkey may help mitigate the 'push private key' problem |
| 20:19.45 | herlo | goozbach: well, that would imply we don't use the fork and pull request method |
| 20:51.25 | *** join/#utos macnewbold1 (~Adium@76.8.223.101) |
| 21:23.03 | *** join/#utos xtrementl (~xtrementl@69.80.96.49) |
| 21:31.38 | *** join/#utos xtrementl_ (~xtrementl@neutroninteractive-xmission.xmission.com) |
| 23:02.30 | goozbach | anyone done anything with python-paramiko? |
| 23:03.53 | herlo | yes |
| 23:04.02 | herlo | I use it in my Silver project |
| 23:04.48 | goozbach | I need to exec a command but with forcing a tty on the far side |
| 23:05.12 | herlo | I think I did something similar |
| 23:05.15 | herlo | hagn on |
| 23:05.17 | goozbach | ie this command works: |
| 23:05.27 | goozbach | ssh -t root@host <COMMAND> |
| 23:05.32 | goozbach | but this one doesn't |
| 23:05.39 | goozbach | ssh root@host <COMMAND> |
| 23:05.50 | herlo | kk |
| 23:05.53 | goozbach | and I really don't want to get into pyexpect for this one usage |
| 23:07.02 | herlo | are you trying to do something with screen? |
| 23:07.20 | herlo | why do you need the -t? |
| 23:09.31 | goozbach | not with screen |
| 23:09.35 | goozbach | it's a nexenta box |
| 23:09.43 | goozbach | and I'm trying to install a solaris package instead of a deb |
| 23:09.53 | herlo | I use paramiko very minimally |
| 23:09.54 | goozbach | and something the solaris package does needs a tty |
| 23:10.09 | herlo | but iirc, it does have some sort of functionality like that |
| 23:10.10 | goozbach | if I don't pass the -t switch the install just hangs |
| 23:10.16 | herlo | ahh |
| 23:10.17 | goozbach | I know paramiko does |
| 23:10.29 | goozbach | but I don't want to do a full blown interactive terminal |
| 23:10.38 | goozbach | just want the danged tty to be alocated |
| 23:10.45 | herlo | yeah |
| 23:11.12 | herlo | can you put the -t option in the .ssh/config?? |
| 23:11.29 | goozbach | I suppose |
| 23:11.50 | herlo | this may help then: http://www.saltycrane.com/blog/2010/02/python-paramiko-notes/ |
| 23:11.51 | goozbach | but I don't know if paramiko honors that |
| 23:12.38 | herlo | it should |
| 23:12.45 | herlo | according to that blog post for sure |
| 23:16.43 | goozbach | ok |
| 23:16.49 | goozbach | let me try the ssh config trick |
| 23:19.18 | herlo | brb |
| 23:21.30 | goozbach | doesn't look like you can force tty with .ssh/config |
| 23:27.24 | goozbach | I've tried this to no availhttp://stackoverflow.com/questions/2909481/paramiko-and-pseudo-tty-allocation |
| 23:43.46 | herlo | looks |
| 23:44.22 | herlo | yeah, that kind of looks like what I did |
| 23:44.37 | herlo | goozbach: the other option is to use Popen.call |
| 23:46.05 | goozbach | popen? |
| 23:47.21 | herlo | yeah, hang on, I'll get you an example |
| 23:48.28 | herlo | goozbach: I do it like this for uploading the srpm sources to the lookaside cache |
| 23:48.30 | herlo | args = ["/usr/bin/rsync", "-loDtRz", "-e", "ssh", "%s/%s" % (self.name, source), "%s@%s:%s/" % ( sks.lookaside_user, sks.lookaside_host, sks.lookaside_remote_dir)] p = subprocess.call(args, cwd="%s" % (sks.lookaside_dir), stdout = subprocess.PIPE) |
| 23:48.48 | herlo | that was supposed to be two lines |
| 23:49.01 | goozbach | eek |
| 23:49.02 | herlo | p = subprocess.call(args, cwd="%s" % (sks.lookaside_dir), stdout = subprocess.PIPE) |
| 23:49.21 | herlo | goozbach: it's just calling what you would on the command line with python |
| 23:49.26 | goozbach | yeah |
| 23:49.33 | herlo | what's wrong with that? |
| 23:49.41 | goozbach | this is only a stopgap |
| 23:49.51 | herlo | import subprocess |
| 23:49.54 | goozbach | as we'll be replacing ssh with some other communitcation medium |
| 23:49.57 | herlo | that's the only other thing you hve to do.. |
| 23:50.07 | herlo | goozbach: yeah, so doing this is pretty simple |
| 23:50.14 | herlo | your command can be split into args |
| 23:50.22 | herlo | then submitted to subprocess.call |
| 23:50.35 | herlo | the one I did is a bit more complex than it needs to be |
| 23:50.52 | herlo | ssh -t root@host <COMMAND> would be |
| 23:51.37 | herlo | args = ["/path/to/ssh", "-t", "user@host", "'command'"] |
| 23:51.54 | herlo | p = subprocess.call(args) |
| 23:52.07 | herlo | the p is the pid |
| 23:52.40 | goozbach | that'll work for now I suppose |
| 23:52.41 | goozbach | thanks |
| 23:53.18 | herlo | :) |
| 23:53.34 | herlo | I can play with paramiko for you and get the other way to work too |
| 23:54.06 | goozbach | I just need to get this to work |
| 23:54.12 | goozbach | so I'll punt |
| 23:54.16 | goozbach | with subprocess |
| 23:54.30 | goozbach | I'm thinking I need to avoid worrying about paramiko and just get it done |
| 23:55.19 | herlo | yeah, I just meant I can look at it and hack it for you later tonight/tomorrow |