12:12:48 <ennael> #startmeeting 12:12:48 <Inigo_Montoya> Meeting started Thu Sep 13 12:12:48 2012 UTC. The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:12:48 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:13:36 <ennael> sorry for the focus but I guess everybody has zillions of things to do so let start 12:13:54 <ennael> so 12:14:09 <ennael> we had a meeting last week with mandriva guys 12:14:18 <ennael> especially oden and lfazio 12:14:36 <ennael> lfazio is the guy in charge of enterprise distribution in mandriva 12:15:16 <oden> i'm the "klingon"... 12:15:25 <MrsB> welcome both of you 12:15:25 <ennael> so mandriva proposed to contribute in secteam 12:15:38 <ennael> and oden will be the main guy around 12:15:56 <ennael> we already have security policy in the wiki 12:16:06 <ennael> this should not change too much 12:16:17 <ennael> the very new thing is about updates under embargo 12:16:42 <ennael> we do not have process and infrastructure to manage it for now 12:17:14 <ennael> what was proposed during this meeting is to have a server dedicated for thius kind of update 12:17:28 <ennael> at least until it's offically released in repository 12:17:40 <ennael> meaning a way to commit stuff, build locally 12:17:58 <ennael> have encrypted ML and IRC if needed 12:18:06 <ennael> does it look reasonable ? 12:18:10 <MrsB> we have some spare now don't we? 12:18:14 <ennael> nope 12:18:40 <leuhmanu> there was no server planned for packager ? 12:18:42 <oden> ennael: hmm, just thought of something. mandriva could donate titan.mandriva.com to mageia. then all is fine, except the server is physically located in my office, jokkmokk, sweden. 12:18:42 <leuhmanu> (hi) 12:18:52 <Luigi12_lappy> probably just a way to log into one of the build nodes and do an iurt build locally would be good 12:19:00 <MrsB> what became of the ones which were replaced recently? 12:19:04 <ennael> wait 12:19:06 <ennael> one at a time 12:19:09 <Luigi12_lappy> leuhmanu: oh yeah I forgot about that one 12:19:27 <ennael> oden: about titan 12:19:37 <ennael> my opinion is it's not a good thing for now 12:19:41 <Luigi12_lappy> leuhmanu: sukuc or something it was called? 12:19:52 <ennael> if for one reason mdv contribution stops we will not have access anymore 12:20:08 <oden> wrong. 12:20:11 <ennael> it should be a server in Mageia infrastructure 12:20:18 <MrsB> i agree 12:20:35 <ennael> oden: your home is not part of Mageia infrastructure 12:20:36 <oden> you would deal with nux ab. and my company could donate the server space and all that. 12:20:38 <ennael> for now :) 12:22:14 <ennael> hum 12:22:22 <ennael> sleeping or killed ? :) 12:22:59 <ennael> oden: so we could have a contract for it ? 12:23:09 <oden> http://n1.nux.se/work/2.6.39.4/supermicro-x7sb4-e/ <- that's the server 12:23:10 <[mbot> [ Index of /work/2.6.39.4/supermicro-x7sb4-e ] 12:23:12 <oden> sure. 12:23:32 <ennael> the thing is it's not very convenient to have servers everywhere on earth 12:23:47 <ennael> tmb: wdyt ? 12:25:08 <oden> it has an ipmi interface too. never used :) 12:25:09 <tmb> well, the idea I had was at some point using the same buildsystem for security updates too, but with locked svn and only internal repos like infra_* and locked monitoring page :) 12:26:04 <ennael> is it enough regarding requires about security? 12:26:35 <oden> yes, and access only by secteam people. 12:26:41 <tmb> that way we always ensure clean builds that matches everything else we build.... 12:27:09 <oden> w8 12:27:21 <oden> ah, tired. 12:27:25 <tmb> and bugzilla must be configured to be able to lock bugreports 12:28:57 <tmb> but I guess we could use either sucuk or new rabbit for starters to test it out 12:29:00 <oden> sure, you can use the mageia bs. but it will be difficult to release embargoed stuff in time to avoid leakage. you must build the package, etc. 12:29:32 <guillomovitch> hello 12:29:43 <Luigi12_lappy_> geez freenode is not working well this morning 12:30:14 <oden> or, we can screw the idea of interacting with vs-sec and the consept of embargo and just react, and catch up. 12:30:34 <tmb> oden: well, that's the point... as soon as you have embargoed stuff to build, submit it to the locked BS, and it gets built and put on loced internal mirror, so secteam can test and go on 12:30:58 <tmb> (and locked svn for that matter) 12:31:35 <ennael> again will it be secure enough regarding what oss-sec asks 12:32:02 <ennael> ? 12:32:12 <oden> titan works the other way. it builds in private. then commits the changes to svn at the time you push the packages (to paris). 12:32:14 <tmb> well, what exactly does vs-sec ask? 12:32:29 <ennael> oden: can you give ore details ? 12:32:45 <oden> ennael: oss-sec = public = already too late :) 12:33:11 <ennael> well the step before 12:33:22 <oden> = reacting. 12:34:14 <oden> there is no written guideline to make the infrastructure secure enough. just be paranoid enough and you're fine. 12:35:19 <oden> the only risk you face is that someone leaks an embargoed issue, the members of vs-sec tracks it to you, then you are evicted. 12:36:12 <oden> unless there is some legal aspect of it that i'm unaware of. 12:36:30 <ennael> let speak about technical aspects first :) 12:36:42 <ennael> boklm: any proposal ? 12:36:54 <ennael> ( boklm was part of the mail for the meeting) 12:36:57 <boklm> maybe an other solution would be to have members of secteam build test updates in a VM on their computer, and discuss the issue on a private ML, during the embargo 12:37:07 <boklm> and as soon as embargo is finished, submit to build system 12:37:36 <oden> speaking of that. PoCs (Proof Of Consept) should be private. at least in sweden it's illegal to share harmful code. 12:37:46 <ennael> oden: wait 12:37:51 <ennael> one thing at a time :) 12:37:57 <oden> yep. 12:38:07 <ennael> t_m_b: still alive ? 12:38:43 <t_m_b> sort of... freenode keeps screwing my connection 12:38:56 <ennael> have you seen boklm proposal ? 12:39:10 <oden> boklm: like with libreoffice. it could mean 4-8h of lag compared to other distros. 12:39:14 <t_m_b> nope, I didn't see anything since my question to oden 12:39:27 <ennael> 14:34 < oden> there is no written guideline to make the infrastructure secure enough. just be paranoid enough and you're fine. 12:39:32 <ennael> 14:35 < oden> the only risk you face is that someone leaks an embargoed issue, the members of vs-sec tracks it to you, then you are evicted. 12:39:37 <ennael> 14:36 < boklm> maybe an other solution would be to have members of secteam build test updates in a VM on their computer, and discuss the issue on a private ML, during the embargo 12:39:41 <ennael> 14:37 < boklm> and as soon as embargo is finished, submit to build system 12:40:15 <oden> <oden> boklm: like with libreoffice. it could mean 4-8h of lag compared to other distros. 12:40:19 <Luigi12_lappy> it would be better to have a mageia system you could log into and run a local iurt 12:40:42 <oden> yes. 12:40:45 <t_m_b> well, rebuilding it again after tests mean pretty much it's untested again 12:40:53 <oden> yes. 12:41:05 <Luigi12_lappy> since the build system builds with stuff in updates_testing included (and I, for example, don't mirror that locally), and things like libreoffice aren't buildable on regular machines (and FF barely is too) 12:42:28 <t_m_b> how about we restrict access to new rabbit for iso builders and secteam, so secteam can build stuff with iurt on that host 12:42:28 <oden> i think the mga iurt version can handle repos better. i patched the one on titan to avoid sucking in unwanted repos. 12:42:49 <MrsB> . 12:42:50 <MrsB> .. 12:43:24 <MrsB> gah server lag 12:45:06 <oden> in the libreoffice example. here's how i usually do it. build the package on titan as usual. then push it to some url at testing.mandriva.com for the qateam to test. if all is fine i just push that package to the mirrors. 12:45:56 <Luigi12_lappy> hmm, yeah how would we handle QA being a community distro? How would we say, ok these are the people that can QA these secret things? 12:46:59 * boklm` was disconnected 12:47:13 <Luigi12_lappy> yes freenode is acting up this morning 12:47:14 <MrsB> me too, missed 20 minutes nearly :( 12:47:50 <oden> secteam does the qa for embargoed stuff. 12:48:13 <t_m_b> Luigi12_lappy: maybe push all but SRPM to qa for testing, so qa can focus on non-broken update path... and then secteam QA the exploits 12:48:47 <Luigi12_lappy> hmm if that doesn't violate the embargo, that could work 12:49:09 <oden> t_m_b: with nothing in %changelog then ? 12:49:21 <Luigi12_lappy> oden: oh, good call 12:49:40 <Luigi12_lappy> plus it wouldn't work if the code was python/perl/etc 12:50:08 <ennael_> woot 12:50:18 <oden> yeah. 12:50:30 <Luigi12_lappy> freenode really needs a spanking 12:50:40 <MrsB> I've missed most of this, sorry 12:50:43 <boklm`> t_m_b: maybe installing a private BS on rabbit could be possible 12:50:48 <guillomo1itch> Luigi12_lappy: it seems they are currently being spanked actively 12:50:52 <guillomo1itch> and that's the issue 12:50:52 <oden> rabbit? 12:51:01 <Luigi12_lappy> guillomo1itch: oh that's unfortunate :o( 12:51:04 <boklm`> oden: the server we use for building isos 12:51:06 <ennael_> oden: name of a server :) 12:51:10 <oden> ah. 12:51:19 <guillomo1itch> excuse me if I'm missing the point 12:51:19 <t_m_b> and its brand new :) 12:51:34 <guillomo1itch> but the discussion seems focused on high-level kind of security issues 12:52:00 <guillomo1itch> the one concerned by privacy, embargo, etc... 12:52:02 <boklm`> guillomo1itch: security issues with embargo 12:52:05 <Luigi12_lappy> plus infrastructure for dealing with those 12:52:32 <oden> we're trying to figure out how to work to avoid leakage of sensitive embargoed stuff. 12:52:43 <guillomo1itch> given than current security team can't even follow standard flow of security issues 12:52:49 <guillomo1itch> and is always lagging 12:53:27 <guillomo1itch> is that really a priority ? 12:53:28 <MrsB> not true 12:53:32 <ennael_> guillomo1itch: having oden on board may solve part of this issue 12:53:35 <Luigi12_lappy> I guess with oden involved we could potentially not lag as much, assuming we can find a way to handle these sort of issues 12:54:16 <t_m_b> yes, and some of the embargoed exploits need to be pushed fast 12:54:42 <t_m_b> *fixes for the exploits.. 12:54:45 <Luigi12_lappy> I imagine that samba one from a couple months ago started that way, though we did do a pretty good job of getting it out quickly 12:55:09 <MrsB> I didn't take this meeting to be an excuse to kick the qa team 12:55:21 <Luigi12_lappy> MrsB: QA team isn't the main cause of the lag 12:55:25 <MrsB> excuse me if i'm missing the point 12:55:41 <ennael> MrsB: we miss ressources it's a fact it's not kicking 12:55:44 <Luigi12_lappy> MrsB: there's a lag of the packagers getting things packaged in the first place 12:55:59 <ennael> back to topic please 12:56:01 <MrsB> there also a lag in packagers responding to queries 12:56:02 <oden> i had an idea of an "emergency security responce team" at mandriva. meaning, i have the authority to assign anyone for a particular issue i need help with and the asignee drops what he/she was doing until the patch or whatever is fixed. 12:56:26 <ennael> oden: you work with salarees not contributers :) 12:56:37 <ennael> but please can we go back to the main topic 12:56:40 <oden> so, some issues could then be pushed straigh away for mga2. 12:57:29 <oden> just trying to explain what i/we have been thinking. 12:57:35 <ennael> ok let's try to split topics 12:57:48 <ennael> server part will be discussed on sysadmin ML 12:58:00 <Luigi12_lappy> I think maybe how to handle this embargoed stuff could be decided at a later date, and probably worked out between oden/ennael/tmb 12:58:09 <ennael> I'm sorry need to leave now 12:58:57 <oden> once mga has a "embargo team" mga can apply themselves for a vs-sec membership. 12:59:30 <Luigi12_lappy> yeah, that's what misc told me 8 months ago 13:00:01 <ennael> can we have 2 topics launched on ML 13:00:10 <ennael> one about process and the other about infra 13:00:17 <boklm> how many embargoed updates per month do we have ? 13:00:27 <oden> also, on this mga secteam server a private and secured irc server should run where the members connects and can discuss stuff. 13:00:40 <ennael> boklm: quite rare now if I remember in Mandriva 13:00:55 <guillomo1itch> hence my point: is that really a priority ? 13:01:01 <Luigi12_lappy> oden: a private channel on freenode won't work? 13:01:08 <oden> no. 13:01:21 <Luigi12_lappy> oden: I can't connect to IRC directly at work, for instance, so I use freenode's webchat 13:01:56 <oden> level 7 fw? if not we can use another port. 13:02:03 <t_m_b> ok, we'll discuss th infra on -sysadmin then and get back to you all when we have something real to suggest, is that ok by everyone ? 13:02:16 <oden> i guess so. 13:02:18 <Luigi12_lappy> yeah 13:02:21 <MrsB> sounds sensible 13:02:34 <oden> <guillomo1itch> hence my point: is that really a priority ? 13:03:16 <ennael> http://bn.parinux.org/p/Managing_embargo 13:03:17 <[mbot> [ Etherpad Lite ] 13:03:31 <ennael> can we list things here 13:03:39 <ennael> for now we don't even know excatly what is needed 13:03:40 <oden> good question. as i said. if mga want to participate with vs-sec then the embargoe thing has to be fixed. if not just react and lag. 13:04:01 <oden> guillomo1itch: good question. as i said. if mga want to participate with vs-sec then the embargoe thing has to be fixed. if not just react and lag. 13:04:16 <ennael> oden: how many embargoed updates / month 13:04:17 <ennael> ? 13:04:25 <ennael> just to give an idea 13:04:44 <oden> i have no figures right now. have to check all the mails. 13:04:57 <guillomo1itch> trying to reduce the current lag seems more sensible for me 13:05:10 <boklm> At the begening, we could start with a team only monitoring embargoed updates at first, starting to work on the update on their own computer for critical issue, to be ready to submit at the end of the embargo 13:06:09 <Luigi12_lappy> yeah at least having access to the information would be nice, even if we can't act on it right away 13:06:34 <boklm> and later have something better with a private server to build the updates 13:06:41 <MrsB> guillomo1itch: current 'lag' is at a minimum, packaging issues excepted. See for yourself. http://mageia.madb.org/tools/updates 13:06:45 <[mbot> [ Mageia App Db ] 13:07:24 <oden> i don't think mga lags much there. i lag more but then i'm alone ;) 13:07:56 <Luigi12_lappy> MrsB: QA has gotten faster over time IMO, and is not an issue really 13:08:12 <MrsB> Perhaps you'd pass that message on ;) 13:08:55 <guillomo1itch> MrsB: why not try to solve those packaging issues then ? 13:09:09 <MrsB> We're not packagers 13:09:15 <guillomo1itch> so what ? 13:09:27 <MrsB> so we have 99 other update permonth to work on 13:09:33 <guillomo1itch> and ? 13:09:41 <Luigi12_lappy> the packagers need to fix packaging issues 13:09:43 <MrsB> not sure what you're getting at tbh 13:09:52 <Luigi12_lappy> it's a different skill set 13:09:55 <oden> here's an example from vs-sec: 13:10:04 <oden> regarding: [vs-plain] Multiple SQL injections in MySQL/MariaDB 13:10:18 <oden> posted satureday. 13:10:22 <MrsB> I honestly thought we'd moved past this guillomo1itch 13:10:23 <guillomo1itch> fixing configuration files content is not a packaging issue 13:10:30 <oden> ... > spot this one easily). I think there's little point in delaying full 13:10:30 <oden> > public disclosure further. 13:10:30 <oden> I agree. In fact a public disclosure (in the form of a posting to 13:10:30 <oden> oss-security) was planned to happen today. 13:10:30 <oden> ... 13:11:14 <Luigi12_lappy> hmm, I guess that's the one we issued a fix for recently 13:11:26 <t_m_b> yep 13:11:59 <oden> oh, that last one was posted on monday. 13:14:32 <oden> there's simply a lot of mails to go through in order to tell. i don't trust our bugzilla this info. 13:15:07 <boklm> how long is the embargo usually ? 13:15:45 <oden> all tools needed has to be secure. this demands responsive sysadmins, like fixing bugzilla sec issues asap... 13:16:20 <oden> embargo time frames differs a lot. a month, a week, some days. 13:17:23 <t_m_b> http://oss-security.openwall.org/wiki/mailing-lists/distros 13:18:03 <t_m_b> "the maximum acceptable embargo period for issues disclosed to these lists is 14 to 19 days," 13:19:04 <oden> i think mit krb5 issues (sent from mit) has quite long embargo time. 13:19:56 <oden> and you learn nothing from mozilla, unless your'e a member there. 13:20:16 <oden> i applied but was denied. 13:20:20 <Luigi12_lappy> :O 13:20:28 <guillomo1itch> what kind of thing do you learn from mozilla, anyway ? 13:20:41 <guillomo1itch> "there is yet another critical flaw in html rendering, update to latest version" :) ? 13:20:47 <Luigi12_lappy> oden: where do you get the CVE descriptions for mozilla you use in your advisories anyway? From RedHat? 13:20:58 <oden> from mozilla. 13:21:19 <Luigi12_lappy> oden: does mozilla send them to one of the openwall lists? 13:22:59 <oden> guillomo1itch: what i'm after is to be able to download the latest ff, build it and push it on the embargo date. but it don't work like that, unless you're using windows, like. then you can install it as soon it is published. 13:23:28 <oden> Luigi12_lappy: no, it's just copy and paste. you can script it too. 13:23:35 <Luigi12_lappy> oden: copy from where? 13:24:01 <oden> http://www.mozilla.org/security/announce/2012/mfsa2012-72.html <- there 13:24:03 <[mbot> [ MFSA 2012-72: Web console eval capable of executing chrome-privileged code ] 13:24:22 <Luigi12_lappy> oden: those pages don't contain the text you use in your advisories 13:24:47 <oden> it can differ. 13:25:37 <Luigi12_lappy> that's the one thing that held me up with our last FF/TB update, I had to wait for Mandriva or RedHat to issue their advisories so I could get the CVE descriptions. 13:26:16 <Luigi12_lappy> they don't come from the http://www.mozilla.org/security/announce/ pages so I don't know where you get them from 13:26:17 <[mbot> [ Mozilla Foundation Security Advisories ] 13:26:19 <oden> i would rather just write "this is the latest firefox. look here for information: http://www.mozilla.org/security/announce/" 13:27:03 <Luigi12_lappy> well I've tried to follow your lead and be formal about it and do it the same way with descriptions and all 13:27:13 <oden> http://cve.mitre.org lags, i think he's exhausted. 13:28:16 <oden> i don't even get mails from there anymore. don't know why. so, it's a little harder to keep up right now. 13:28:16 * Luigi12_lappy hates all the stupid "reserved" CVEs 13:28:40 <boklm> as a begining we could start with a private ML only, to use embargo time to be able to have an update ready to submit for QA tests at the end of embargo, and after seeing how it works, see how we can improve the process to be able to also have QA done for the end of embargo 13:30:19 <boklm> what do you think about doing this ? 13:30:23 <oden> that mailinglist has to be gpg encrypted. you can use mailman for that as i added the support. 13:31:24 <guillomo1itch> then you should takeover maintainership, and reapply it 13:31:43 <oden> it's in mga2 i think. 13:31:48 <guillomo1itch> yes 13:31:59 <guillomo1itch> I jsut removed it it cauldron 13:32:04 <oden> latest version has the support i think. 13:32:26 <oden> or partly. hard to tell. no info. 13:32:26 <guillomo1itch> yes, the patch does exist 13:32:55 <oden> and no time anymore lurking with such things. 13:33:17 <guillomo1itch> sympa also have encrypted list support 13:33:37 <guillomo1itch> at least for S/MIME, no clue about PGP tough 13:33:50 <guillomo1itch> anyway, that's an issue with sysadmin 13:33:57 <oden> yep. 13:35:30 <oden> anyway. a secured and private irc server would suffice for me, for now. 13:35:57 <oden> no lag. 13:36:12 <guillomo1itch> that seems a reasonable and achievable target 13:37:35 <oden> using ngircd-19.2 on titan. access via ip address restriction and over ssh. 13:37:56 <boklm> how many people will we have in the team ? 13:38:49 <oden> good question. and who? 13:39:57 <boklm> so first thing would be to decide who will be part of that team 13:40:35 <oden> ngircd is run under runit + ipsvd (as well as many other services) 13:43:55 <oden> Luigi12_lappy: i've been critised for using the cve text. seems all other distros loves to write their own description, basically saying the same thing. i could probably do it too but then more time would be spent writing than providing fixes. 13:44:26 <Luigi12_lappy> oden: who criticized you? Yes, it would be a waste of time rewriting the descriptions. 13:45:10 <oden> Luigi12_lappy: don't remember really. maybe it was debian. 13:45:26 <Luigi12_lappy> RedHat's advisories are most similar to yours 13:45:40 <Luigi12_lappy> in my experience working on this throughout this year, Debian does the worst job with security updates 13:46:16 <Luigi12_lappy> they've had a number of broken ones, sometimes from re-diffing upstream commits and not realizing those were dependent on other commits 13:46:26 <MrsB> i think it's good to use the same text, it's easy then to see what has been fixed is the same as others. 13:46:30 <oden> really? 13:46:38 <Luigi12_lappy> then people complain in their bug reports about the breakage and the close the bug and ignore it 13:47:19 <oden> amazing. 13:47:19 <Luigi12_lappy> MrsB: I agree 13:47:35 <oden> same text as who? 13:47:48 <MrsB> the cve 13:47:55 <oden> yes. 13:48:08 <Luigi12_lappy> of course sometimes the CVE text is badly written, misleading, or inaccurate 13:48:23 <oden> but mitre lags now. so i have to get the text from redhat. 13:48:47 <MrsB> where do they get theirs from, write it themselves? 13:48:52 <Luigi12_lappy> I've used CVE text but fixed the inaccuracies a number of times 13:48:53 <oden> or elsewhere. 13:49:25 <oden> the redhat ones i think they mostly write themselves. 13:49:34 <Luigi12_lappy> wow 13:49:50 <Luigi12_lappy> RH's advisories are really helpful, they do a good job 13:50:23 <MrsB> it's their bugzilla we often find poc's on aswell 13:50:29 <oden> oh, another thing. one should give credit to the ones who discovered an issue. i think debian is best at that. 13:50:47 <oden> i seldom do though. 13:50:48 <Luigi12_lappy> yeah Debian and Ubuntu usually mention it 13:53:13 <MrsB> Do you think Anne will remember to endmeeting? 13:53:24 <Luigi12_lappy> hehe 13:53:44 <oden> ok. to summarize this. what will happen next. who does what etc? 13:53:50 <boklm> So to summarize things that need to be done to start the security team, the todo list is: 13:54:00 <boklm> - find who would be interested to join the team monitoring embargoed security issues 13:54:03 <boklm> - decide who joins the team (people who were already working on security updates ?) 13:54:06 <boklm> - create an encrypted mailing list / irc channel 13:54:09 <boklm> - request subscription to oss-security private ML 13:55:09 <oden> Luigi12_lappy is the mga "security team manager" right? 13:55:18 <Luigi12_lappy> unofficially 13:55:23 <MrsB> Team leader 13:55:31 * Luigi12_lappy happened into this role by accident 13:55:33 <leuhmanu> #info ? 13:55:43 <MrsB> everybody did Luigi12_lappy :D 14:00:58 <Luigi12_lappy> oden: not sure if you noticed, but I've periodically sent out a mail to mageia-dev listing the outstanding security issues that need help/input from others to fix. The most recent list is here: https://www.mageia.org/pipermail/mageia-dev/2012-September/018515.html 14:00:59 <[mbot> [ [Mageia-dev] Security updates - help needed! ] 14:01:35 <boklm> anything more to discuss in this meeting ? 14:01:40 <Luigi12_lappy> oden: a few of those issues still impact Cauldron and probably Mandriva as well: https://bugs.mageia.org/show_bug.cgi?id=7085 https://bugs.mageia.org/show_bug.cgi?id=7095 and maybe https://bugs.mageia.org/show_bug.cgi?id=7068 14:01:43 <[mbot> [ Bug 7085 openafs missing update for security issues CVE-2011-0430 and CVE-2011-0431 ] 14:03:09 <MrsB> It's early days, we can discuss more details later when the infrastructure is in place 14:07:14 * Luigi12_lappy is reminded of the scene from Titanic with the guys in the little boats yelling "is there anyone alive out there?" 14:07:56 <MrsB> I'm not allowed to watch titanic again :( 14:08:10 <Luigi12_lappy> why? 14:08:50 <ennael> #endmeeting