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