| *** dabukalam has quit IRC | 05:39 | |
| *** dabukalam has joined #baserock | 05:39 | |
| *** paulwaters_ has joined #baserock | 07:14 | |
| *** jonathanmaw has joined #baserock | 07:46 | |
| *** CTtpollard has joined #baserock | 08:03 | |
| *** rdale has joined #baserock | 08:08 | |
| *** anahuelamo has joined #baserock | 08:13 | |
| pedroalvarez | paulsherwood: if you run `git fetch https://gerrit.baserock.org/baserock/baserock/definitions refs/changes/78/2278/3 && git checkout FETCH_HEAD` in a definitions checkout | 08:14 |
|---|---|---|
| pedroalvarez | (command taken from the dowload dropdown menun in the top right) | 08:14 |
| paulsherwood | pedroalvarez: tvm | 08:15 |
| pedroalvarez | :) | 08:16 |
| * paulsherwood has forgotten everything about gerrit since he has been working primarily with gitlab and github | 08:17 | |
| jjardon | paulsherwood: hi, did you have, by any chance, time to work on the tar problem with gitlab? | 08:29 |
| jjardon | Well, gitlab public runners | 08:30 |
| *** locallycompact has joined #baserock | 09:13 | |
| paulsherwood | jjardon: sadly, no. i think i'm going to need help with that | 09:18 |
| *** paulwaters_ has joined #baserock | 09:33 | |
| *** brlogger has joined #baserock | 11:17 | |
| *** rdale has quit IRC | 11:22 | |
| *** rdale has joined #baserock | 11:23 | |
| paulsherwood | rjek: not sure i understand what you mean by "I don't think it should implement SSL/TLS. There are too many gotchas | 13:53 |
| paulsherwood | and pitfalls here." | 13:53 |
| rjek | You'll get it wrong. | 13:54 |
| paulsherwood | i was only re-using an existing library implementation | 13:54 |
| rjek | Just let a web server handle it | 13:54 |
| paulsherwood | so you'd vote -1 against enabling cherrypy https support? | 13:55 |
| rjek | I would. | 13:55 |
| paulsherwood | :/ | 13:55 |
| paulsherwood | given cherrypy supports it, and the patch i linked to 'seems to work', what could i be getting wrong? | 13:58 |
| paulsherwood | (note - i'm ok with the idea that it's better to leave this to a web server, but there may be folks who would rather not have to set one up) | 13:59 |
| rjek | How are you configuring the cipher selection? The DH parameters? | 13:59 |
| rjek | People who can't be arsed deserve no security | 13:59 |
| paulsherwood | lol | 13:59 |
| paulsherwood | rjek: i want to improve kbas in this area. figuring out how to configure a web server seems a long way off my track, tbh | 14:04 |
| * rjek has stated his position, you are free to ignore his opinion | 14:04 | |
| paulsherwood | i'm not ignoring it. i'm seeking help | 14:05 |
| rjek | Including the configuration snippets for a range of popular httpds in your README seems popular | 14:05 |
| paulsherwood | rjek: i don't have any experience with httpds | 14:07 |
| rjek | Learning is good for the mind! :) | 14:08 |
| rjek | nginx snippet: | 14:08 |
| rjek | location /kbas/ { | 14:08 |
| rjek | auth_basic "Restricted"; | 14:08 |
| rjek | auth_basic_user_file /etc/nginx/.htpasswd; | 14:08 |
| rjek | proxy_pass http://kbas-server.admin.colo.codethink.co.uk:8000/; | 14:08 |
| rjek | } | 14:08 |
| paulsherwood | rjek: would you mind writing up actual instructions for how to setup a kbas with nginx? | 14:09 |
| rjek | I would :) | 14:10 |
| paulsherwood | why? | 14:10 |
| rjek | Ever increasing todo list | 14:10 |
| paulsherwood | sadly i guess i'll have to ignore your opinion on this after all, then | 14:12 |
| rjek | http://docs.cherrypy.org/en/latest/deploy.html#reverse-proxying | 14:12 |
| rjek | Somebody's already documented how to do it | 14:13 |
| paulsherwood | ironically, i took the openssl parameters for the ssl implementation from that very page | 14:20 |
| paulsherwood | http://docs.cherrypy.org/en/latest/deploy.html#ssl-support | 14:20 |
| paulsherwood | i assume it's just as likely (more likely in fact) that i can get the nginx setup wrong, as the ssl. | 14:22 |
| rjek | a) there are no SSL/TLS protocol parameters on that page, b) the page suggests using a snakeoil certificate | 14:22 |
| rjek | So basically wrong. | 14:23 |
| paulsherwood | :) | 14:23 |
| paulsherwood | what do you mean by snakeoil certificate? (i'm trying to understand, here, i really am) | 14:25 |
| rjek | It's not created by a recognised certificate authority so the end user has no mechnism to assign trust to it unless they have been told the certificate's fingerprint out-of-band. | 14:25 |
| rjek | Without additional configuration, wget and curl will refuse to talk to it, and most web browsers will make it difficult | 14:26 |
| paulsherwood | so it's the self-signed cert you're calling snakeoil? | 14:27 |
| rjek | It is. | 14:27 |
| paulsherwood | ok. for the limited usecase where kbas server originator doesn't care whether users trust or not (use at your own risk... but i self-certify) | 14:28 |
| paulsherwood | and the users are only running ybd, would self-cert be sufficient? | 14:28 |
| rjek | Will you implement all the needed certificate checking and server certificate storage logic in ybd? | 14:30 |
| paulsherwood | i don't know what that involves, tbh. aiui i'm only trying to establish an encypted pipe so that ybd can access kbas with a password that isn't plaintext | 14:31 |
| paulsherwood | why would ybd need to care about the certificate etc? | 14:31 |
| rjek | How else would you know you're talking to the real kbas? | 14:32 |
| paulsherwood | url | 14:33 |
| * rjek poisons paulsherwood's DNS cache | 14:33 | |
| paulsherwood | if that happens, i've got bigger problems than ybd-kbas | 14:33 |
| rjek | If you trust your traffic to never be man-in-the-middled, then you don't need TLS | 14:33 |
| jmacs | Would it be any easier to use SSH to secure this and tunnel kbas traffic over a forwarded port? | 14:34 |
| paulsherwood | i think pedroalvarez suggested something like that | 14:35 |
| richard_maw | doesn't that have the same authentication problem, just with ssh keys instead of ssl certificates? | 14:35 |
| rjek | Also means a dedicated UNIX user, any of which can add or remove which keys are acceptable | 14:35 |
| jmacs | Probably; it's a case of which you understand. I have a better understanding of SSH keys than HTTPS certificates, and maybe others do too. | 14:36 |
| rjek | a) use an acceptable certification authority, b) have a web server with known-good TLS cipher and DH param defaults, c) have the ability to have more than one password/token | 14:36 |
| rjek | a) can be avoided if the client can be told to trust the self-signed snakeoil certificate | 14:37 |
| rjek | (But not just blindly trust any certificate) | 14:37 |
| rjek | Then you can use a trusted, out-of-band method of communicating that certificate | 14:38 |
| richard_maw | could bake that signature into ybd, but that makes kbas a singleton | 14:38 |
| paulsherwood | can't we just add a conf value? | 14:38 |
| rjek | That also means every kbas has the same private key, and thus anyone can impersonate anyone else's kbas, and in turn obtain the passwords/tokens | 14:38 |
| paulsherwood | so what would ybd need to know, for a given self-signed cert? | 14:40 |
| rjek | I am still advocating that if you want security for a permanent kbas installation, you do it properly and spend the 20 minutes it takes to read the docs of your chosen web server and have it off-load it | 14:40 |
| paulsherwood | and i am ok with that. i just want to understand what is possible/sensible without having to install a web server. there is at least one established kbas instance where no webserver is chosen | 14:42 |
| paulsherwood | adding a webserver increases the attack surface, after all | 14:43 |
| richard_maw | the alternative is expanding kbas' attack surface with something that isn't so widely peer reviewed and battle-tested isn't it? | 14:45 |
| rjek | And in a way that consumes a whole port/IP address | 14:47 |
| paulsherwood | richard_maw: i don't see how anything i'm suggesting expands anything - kbas already uses cherrypy, but only via http | 14:48 |
| richard_maw | adding https support is expanding the attack surface, as is adding a config option for certificate selection | 14:49 |
| paulsherwood | so you would see that as worse than leaving the current plaintext implementation? | 14:53 |
| rjek | It may give a false sense of security. | 14:53 |
| rjek | We know the current system is unsecure against man-in-the-middle. It would be a shame to imagine doing this made it more secure when infact it added nothing. | 14:54 |
| paulsherwood | lol. i've used that argument myself, about automated tests :) | 14:54 |
| richard_maw | plus, if there's an SSL vulnerability that allows remote code execution, then that's worse than just being allowed to upload and download files it shouldn't | 14:54 |
| rjek | So, let the extensively-tested peer-reviewed thing do the difficult bit | 14:54 |
| richard_maw | and if there is a mitigation to the SSL vulnerability, then there would be guides on how to reconfigure your web server to mitigate it, not so for applications that do their own SSL | 14:55 |
| richard_maw | but no, I wasn't intending to say that adding SSL expanding the attack surface is worse than leaving it unsecure, just that it's a false equivalence to say that doing so via a web server is adding an attack surface where adding it to the application isn't | 14:56 |
| paulsherwood | ack | 14:57 |
| richard_maw | but just because it's not the argument I was trying to make, doesn't mean it's not true | 14:58 |
| * paulsherwood struggles to parse the triple negative | 15:07 | |
| * richard_maw wasn't arguing that not implementing SSL is better, but not implementing SSL might be better anyway | 15:08 | |
| paulsherwood | that's still three negatives :) but i understand now, thanks | 15:09 |
| * richard_maw could have sworn he cut it down to two non-overlapping ones | 15:11 | |
| locallycompact | having no negatives often doesn't unconceal the same point as not having them | 15:11 |
| paulsherwood | gaaaaaaaah :) | 15:11 |
| *** mwilliams_ct has joined #baserock | 15:13 | |
| mwilliams_ct | Hi folks. Is it possible to spin up a Baserock VM on AWS? I'd like to deploy a trove In The Cloud | 15:15 |
| richard_maw | mwilliams_ct: not unless things have changed since I last tried | 15:16 |
| rjek | Has anyone tried getting Trove running on Debian/Ubuntu recently? | 15:16 |
| mwilliams_ct | richard_maw: ack, I seemed to remember it wasnt possible. Any recollection of what the issue was? | 15:16 |
| mwilliams_ct | also what rjek said | 15:16 |
| locallycompact | I thought AWS just offers their own supported images and that was it | 15:16 |
| locallycompact | I didn't see anything you could upload an iso | 15:16 |
| richard_maw | mwilliams_ct: the blockers were a lack of Xen drivers and that my attempt didn't include cloud-init | 15:16 |
| richard_maw | locallycompact: it's possible to do your own images, but rigourously undocumented | 15:17 |
| locallycompact | I see | 15:17 |
| richard_maw | (though I did write up how to make the images at one point) | 15:17 |
| mwilliams_ct | richard_maw: ok, that sounds delightfully painful. thanks for answering though! | 15:17 |
| mwilliams_ct | So to echo what rjek asked, could I run Trove on Debian/Ubuntu? | 15:19 |
| richard_maw | mwilliams_ct: http://paste.baserock.org/ucubowitat is what I had written up | 15:20 |
| richard_maw | mwilliams_ct: I don't know about running it on Debian, but if you were to try it on Ubuntu it wouldn't work because they miscompiled one of the libraries gitano depends on | 15:21 |
| mwilliams_ct | richard_maw: nice. does upstream Gitano know? | 15:21 |
| richard_maw | yes | 15:21 |
| richard_maw | wem | 15:21 |
| richard_maw | we do | 15:21 |
| mwilliams_ct | ack, so I can't even complain in #gitano :). OK, looks like I'm going to have to try it on debian | 15:22 |
| richard_maw | you'll have to do local installs of all the bespoke components and I have no idea if the other components have sufficient versions packaged in debian | 15:22 |
| mwilliams_ct | richard_maw: ok, thanks for the help. I think I'm just going to have to play around with it and see what happens at this point. At any rate, Trove In The Cloud seems a really useful thing to have | 15:25 |
| richard_maw | it already is if you're using an openstack rather than AWS | 15:25 |
| mwilliams_ct | true, I am being bad and using The Cloud to mean AWS, which is specifically useful to me at this moment in time | 15:26 |
| leeming | I'm assuming no, but... anyone supporting sandboxlib currently? https://github.com/CodethinkLabs/sandboxlib | 16:11 |
| leeming | I have a feeling it breaks normal usage of python's loggers | 16:12 |
| *** jonathanmaw has quit IRC | 16:53 | |
| *** locallycompact has quit IRC | 17:21 | |
| *** rdale has quit IRC | 19:04 | |
| *** rdale has joined #baserock | 21:55 | |
| *** rdale has quit IRC | 22:13 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!