path: root/meeting-logs/20190310.txt

14:01 <@WilliamH> Ok folks, let's get started.. We have a pretty light agenda today...
14:01 <@WilliamH> https://archives.gentoo.org/gentoo-project/message/11230a6857a8838db6f34cbef523477a
14:01 <@WilliamH> 1. Roll Call:
14:01  * K_F here
14:01  * leio here
14:01  * slyfox here
14:01  * Whissi here
14:01  * ulm here
14:02  * WilliamH here
14:02  * dilfridge here
14:02 <@WilliamH> 2. GLEP 79:
14:02 <@WilliamH> https://archives.gentoo.org/gentoo-project/message/189b52f718e1419fd8fd43d35ccde566
14:03 <@WilliamH> Is there any discussion that needs to happen for this?
14:03 <@K_F> to me the idea seems good enough, and I've been discussing the necessary aspects ahead of this
14:03 <@slyfox> 1. Are security@ and infra@ happy about it 2. Why council has to be involved?
14:04 <@dilfridge> 2. because it's a glep?
14:04 <@K_F> slyfox: well, its a GLEP in format, so that means council
14:04 <@WilliamH> slyfox: Council approves GLEPS, but you are correct we haven't heard from Infra or Security.
14:04 <@dilfridge> 1. it's been proposed by someone from infra
14:04 <@WilliamH> dilfridge: true.
14:04 <@K_F> but arguably this is something that infra could do anyways.. it doesn't need a glep, but having one still describes things nicely
14:04 <@leio> I don't like the L1 signing suggestions and the expiring key renewal wording (I don't read ahead-of-time out of it); the former I'd like comments from people in the know with GPG, the latter is such grammar
14:05 <@dilfridge> not sure how it involves security, but K_F is member there
14:05 <@leio> just*
14:05 <@K_F> it doesn't really involve security per se, but several members have been discussing it already
14:05 <@Whissi> It wasn't discussed in Gentoo security project (to answer slyfox's question).
14:05 <@K_F> leio: can you elaborate on that?
14:05 <@leio> what Whissi also wrote, basically
14:06 <@K_F> the encouragement?
14:06 <@leio> "However, at the same time users are encouraged to sign the key upon verifying it."
14:07 <@K_F> right.. that isn't really vital to anything.. and depending on how you read it most likely means signing using a non-exportable signature
14:07 <@leio> doesn't that also typically end up being uploaded eventually and then affect WoTs, etc
14:07 <@WilliamH> leio: I interpret that as meaning no one is required to sign the key, but it is good if they do.
14:07 <@leio> I find it bad if they do (in an exportable signature)
14:08 <@K_F> well, its not really bad in any way, and can have value, so it doesn't really matter that it is there as an encouragement
14:09 <@WilliamH> leio: given your concern about it, do you think we should vote on this today or send it back for more discussion?
14:09 <@K_F> if more discussion someone should actually propose some arguments and/or suggested rewrites though
14:10 <@leio> I would like to defer that to Whissi, assuming he knows GPG more and raised this point as well
14:10 <@WilliamH> Whissi: ^^ ?
14:10 <@leio> ultimately I'm not sure why this has to be a glep, etc
14:10 <@WilliamH> leio: There is that too since it is purely an infra project.
14:10 <@leio> but if it is a glep, I'm going to go nitpicky on it
14:11 <@Whissi> Well, I still don't understand how a _user_ will benefit from that proposal. The only benefit I see: Because we are CA, we can revoke a developer key. That's all.
14:11 <@Whissi> (we don't revoke the key itself, we revoke the key trust)
14:11 <@K_F> Whissi: right, so you can use it to verify email messages, commit signatures etc
14:11 <@dilfridge> well, a GLEP is one of the few ways in gentoo how you can "nail something down" so nobody later can claim "that's just inofficial, not really a policy"
14:11 <@K_F> without it you need a full WoT to get to all developers
14:12 <@dilfridge> so if somebody makes the effort to write a useful glep, let's work with that
14:12 <@K_F> such a CA setup is ultimately a good structure, and one that I've proposed myself for decades :)
14:12  * dilfridge too
14:12 <@Whissi> But when we create that GLEP, will it the basic for a new requirement or something? How will it affect everyone? Or is it just something new some people maybe use but we all can ignore.
14:12 <@leio> I'm happy with the majority of it, personally; I just don't understand the intricacies of the effect of "signing" that L1 or L2 key and how it affects other things, such as a separate WoT
14:13 <@K_F> (there is even a section on it in my book)
14:13 <+mgorny> Whissi: it's specifically designed not to require anything from devs
14:13 <@dilfridge> anyone can sign any key with gpg
14:13 <@WilliamH> leio: That's my thing, a lot of this gpg stuff is a black box to most of us.
14:13 <@leio> sure, but the wording there is a suggestion now. And if it's mentioned there, we get to bikeshed it.
14:13 <@K_F> WilliamH: man gpg or read rfc4880? :)
14:13 <+mgorny> i.e. give something to users without requiring devs to jump through a lot of hoops
14:14 <@dilfridge> then effing read up on it, pretty please, it's somewhat important
14:14 <@leio> maybe it can say that "non-exportable signature" in there and we are good?
14:14 <@K_F> dilfridge++
14:14 <@Whissi> mgorny: So the user should check if GPG key X has a valid signature from "Gentoo CA" on @gentoo.org UID. If true -> the dev is active/valid. That's all?
14:14 <@Whissi> user == random Gentoo user
14:15 <@K_F> Whissi: yes, thats basically it
14:15 <@K_F> there might be other uses for separate L2 keys, but that'd be the gist for gentoo dev one
14:15 <+mgorny> Whissi: well, gpg does that for the user
14:15 <@dilfridge> yes, and depending on the trust model that may be doneautomatically by gpg
14:15 <+mgorny> user needs only to validate L1 key and set its trust
14:15 <@K_F> another one might sign service keys used for git commits etc
14:15 <+mgorny> (which he can do via website or WoT or any other way)
14:15 <@Whissi> Yeah, if they accept L1/L2 trust and we use exportable signatures.
14:16 <@K_F> its exportable signatures for the L2 dev key on @gentoo UID
14:16 <+mgorny> leio: exportable signatures are by design, so that users can rely on WoT to verify the key rather than TLS
14:16 <@dilfridge> please let's not reinvent the wheel... the gpg trust model exists for a reason and has been used for a long time
14:16 <@dilfridge> so why not coopt it
14:17 <@K_F> I really don't see a reason not to recommend signing the L1 CA
14:17 <+mgorny> L1/L2 split is merely not to have to keep L1 unencrypted on servers
14:17 <@leio> I'm talking about the suggestion to users to sign the L1 key; L1 key signing L2 key with exportable signatures and L2 key signing dev keys with exportable signatures makes sense.
14:17 <@K_F> if people don't they ... don't
14:17 <@dilfridge> well
14:17 <@dilfridge> anyone can sign the L1 key anyway
14:17 <@dilfridge> anyone can sign any key
14:17 <@Whissi> Well, I am still unhappy how L1 key is generated and I am a little bit concerned what will happen if say antarus who will own that key will left Gentoo for example. How will this affect L1 trust. Because if we cannot trust L1, we can't trust L2...
14:18 <+mgorny> ...and they do without verifying much
14:18 <@leio> K_F: ok, what is the answer to my original wondering - how does that affect the other stuff, like separate WoT concepts - if users sign it, won't it all end up in WoT then, and we'll need to explicitly remove that stuff from the WoT etc; or that's all moot because WoTs specifically are limited to only direct contacts between the nodes in the trees?
14:18 <@K_F> Whissi: its definitely a good case for a generate on smartcard
14:18 <+mgorny> Whissi: the current infra policy is 2 devs keep a secure copy of the key, and others get extra revocation certs
14:18 <@dilfridge> so what in the GLEP specifies how L1 is generated?
14:19 <+mgorny> dilfridge: it's outside the scope
14:19 <@K_F> leio: WoT only extends for as far as you define it to in the trustdb
14:19 <@dilfridge> afaics it only says "infra best practices"
14:19 <@dilfridge> and that's ok
14:19 <+mgorny> it isn't supposed to explain how pgp works
14:19 <@K_F> leio: so I'm not entirely sure i understand the question
14:19 <@K_F> but at least this gives users a possibility to verify commits/emails from devs
14:20 <@K_F> which is a good thing for both users and other devs
14:20 <@K_F> to do so you DO need to sign the L1 key, but it _can_ be a non-exportable signature, and assign ownertrust value of FULL to it
14:21 <@Whissi> I agree that it isn't supposed to explain how GPG works. But next GLEP which will describe how to verify repository/release media will depend on GLEP 79...  and in the end everyone will be surprised one day when a former Gentoo dev with access to L1 key issued a new signature because he/she was able to do that and don't like Gentoo anymore.
14:21 <@K_F> you would also then need to assign a FULL owertrust to the dev L2 key (which is permitted then given the L1 key)
14:21 <@leio> and what's the benefit of doing an exportable signature there?
14:21 <@K_F> leio: for one thing if the web server is hacked and it starts pointing to another CA key, you can wonder why they don't match
14:21 <@dilfridge> Whissi: so what would be the alternative?
14:21 <+mgorny> Whissi: you're confusing dev keys with release keys
14:21 <@K_F> and you can expand trust through it through existing WoT
14:22 <@leio> K_F: sure, but wouldn't that happen with non-exportable too
14:22 <@Whissi> So if we create a Gentoo Trust everyone should be able to understand how things work, who has keys and what will be done if someone with access to that key will leave project.
14:22 <@K_F> leio: well, the difference is third parties can't rely on it.. so depends on what your starting point is
14:22 <@dilfridge> OK
14:22 <@dilfridge> so
14:23 <@dilfridge> here's a suggestion
14:23 <+mgorny> leio: non-exportable signature prevents using WoT to verify it
14:23 <+mgorny> which forces users to rely on PKI, which is not really very secure
14:23 <@dilfridge> Whissi: how about you write a paragraph expanding the GLEP, which goes into the details of access to the L1 key
14:23 <@K_F> leio: if you believe I might have a decent understanding of which key is correct, and I'm already in WoT you already get a valid CA key directly, but you'd have to extend it to trust further on
14:23 <@dilfridge> everything else is not really a problem, since it all hinges on L1
14:23 <@leio> mgorny: I'm talking about users signing the L1 key, not other parts; are you?
14:24 <+mgorny> leio: yes
14:24  * dilfridge gets another beer
14:24 <+mgorny> when users verify the correctness of the key, they can sign it
14:24 <+mgorny> when they sign it, other users trusting them can trust that they have verified the key
14:25 <@Whissi> dilfridge: Yes, I can work with infra on adding the information I am missing. But I like to hear your opinion first: Do you think that we must define actions like "If someone with access to L1 key will leave project, we have to recreate L1..."  yes/no
14:25 <@Whissi> (your all, from all council members)
14:25 <@K_F> not if it is created on smart card only
14:25 <@leio> ok, I'm good regarding the signing stuff, thanks for explanations.
14:25 <+mgorny> Whissi: it's really just another key in infra possession
14:25 <@Whissi> OK, that's important to know. Where's key stored
14:25 <+mgorny> i don't see a need to copy policies into the glep
14:26 <+mgorny> esp. that it would mean we would actually have to update the glep every time infra policy changes
14:26 <+mgorny> (e.g. when we get the nitrokeys)
14:26 <@dilfridge> well
14:26 <@dilfridge> if there's one point where infra policies should get formalized then L1
14:26 <@K_F> its intended as a long term authentication of Gentoo assets
14:26 <+mgorny> Whissi: would it work if infra policy was copied to the public wiki?
14:26 <@K_F> so it is a certain special role
14:26 <@K_F> dilfridge: exactly
14:27 <@Whissi> That's the question here. If you all believe that policy shouldn't be part of GLEP, I will not block.
14:27 <@Whissi> mgorny: It will help yes.
14:27 <@K_F> I don't particularly believe it belongs in the GLEP, as that is the concept itself
14:27 <@dilfridge> I'm somewhat ambiguous
14:28 <@K_F> but I belive it needs to be done correctly, for sure
14:28 <@dilfridge> what is the impact if someone uses L1 maliciously? since people trust L1 directly, she can sign dev keys directly. no L2 needed.
14:28 <@Whissi> And I would really like to participate key creation to be honest... (i.e. do that during a mini conf)  sure, someone could manipulate laptop and things like that... but... :>
14:29 <@K_F> dilfridge: could be used for other assets as well, e.g release media
14:29 <+mgorny> Whissi: a laptop? and you call that secure?
14:29 <@dilfridge> yes, and that's pretty bad
14:29  * mgorny would never ever let his primary keys touch a device he carries outta secure locations
14:29 <@Whissi> mgorny: I was referring to antarus example.
14:29 <@K_F> online laptop isn't secure
14:30 <+mgorny> dilfridge: it is revoked to kill the impact
14:30 <+mgorny> dilfridge: the point is that L1 is kept secure and used scarcely, so the chances are minimal
14:30 <@dilfridge> yes that's the mitigation, I'm not sure yet how effective that is
14:30 <+mgorny> depends on users refreshing keys
14:31 <+mgorny> but that's inevitable
14:31 <+mgorny> the difference is, we can actually mitigate it
14:31 <+mgorny> if users sign malicious key via regular wot, it's usually impossible to mitigate that
14:32 <+mgorny> (i mean, we would have to ask users to PLEASE not trust this, blah blah)
14:32 <@Whissi> dilfridge: Why do we have Certificate Transparancy Log now? Because some CAs issued certificates they weren't allowed to do so. Someone with L1 access can do everything. We won't notice. And if _user_ will trust that key and use WoT, they will trust the malicious key by default until someone will notice "Uh, that isn't L1/L2 key..."
14:32 <@K_F> CT is just crap anyways
14:32 <@K_F> but that is a separate discussion
14:32 <@Whissi> :)
14:32 <@dilfridge> so let's come up with a better plan
14:32 <@K_F> CT works as long as everyone is honest, clients doesn't require all certs to be verified vs CT
14:33 <@K_F> its just security theater
14:33 <@Whissi> K_F: Wrong. Chrome is requiring CT log
14:33 <@dilfridge> "works as long as everyone is honest"
14:33 <@K_F> Whissi: not for all certs, only some special ones
14:33 <@Whissi> For all certs
14:33 <@Whissi> Since end of 2018
14:33 <@dilfridge> Silizium.
14:33 <@dilfridge> so let's come up with a better plan
14:34 <@K_F> Whissi: ah, missed that part, but other browsers and clients (e.g curl/wget) doesn't..
14:34 <@WilliamH> So does someone want to put forward a motion?
14:35 <+mgorny> well, i think the glep is good as-is, so unless there's really a majority disagreement, i'd like it to be voted on
14:35 <@Whissi> K_F: cURL project is working on implementation. Mozilla has that implemented but it is of by default.
14:35 <@K_F> Whissi: lets just vote for the glep, if it fails we can revisit
14:36 <+mgorny> and if not, i'd like to hear specific comments on what needs to be improved
14:36 <@dilfridge> well we had some of those already
14:36 <@Whissi> I still don't like L1 creation. If we can talk about this even if we vote for GLEP now, I am happy to vote.
14:37 <@dilfridge> imho the signatures thing is a non-issue... L1 creation / maintenance is more complex
14:37 <@Whissi> ack
14:37 <@leio> I don't like "Whenever an old signature expires, a new one is automatically created." wording, can we change that with editorial changes later?
14:37 <+mgorny> right now, L1 creation would look like this: i start my secure machine, create the key, export an encrypted copy for robin and revcerts for some more infra people
14:37 <@K_F> I'm fine with voting with a comment on futher discussion and clarity on L1 creation
14:37 <@leio> (it very specifically states that new one is automatically created AFTER old one expires)
14:38 <+mgorny> leio: 'is about to expire'?
14:38 <@leio> sure
14:39 <@leio> english is hard :)
14:39 <@Whissi> mgorny: This is... uhh... sounds like a software certificate which allows for endless copies. Me wonders if k_f like that plan. But if you have a policy at infra how to handle leaving members... it might work.
14:40 <@K_F> I prefer HSM/Hardware token for any CA key
14:40 <+mgorny> Whissi: that's bus factor of 2
14:40 <+mgorny> + backup bus factor of N for revoking and creating a new key
14:41 <+mgorny> K_F: we'll still waiting for nitrokey
14:41 <+mgorny> better have a semi-secure policy than wait while keys are kept unencrypted on infra servers, like they were in the past
14:41 <@K_F> well, its easy enough to buy a token (I would expect most infra members to have some empty around anyways)
14:41 <@K_F> but we don't need to do that for a long term CA
14:42 <+mgorny> K_F: oh, you meant token in possession of infra member, rather than plugged into server?
14:42 <@K_F> the real question is durability.. which token is appropriate to use for something like that
14:42 <@K_F> a regular smartcard is more difficult to break than a nitrokey
14:42 <+mgorny> i still find offline storage better than that
14:42 <@K_F> yes, in possession of infra member
14:42 <@K_F> nothing should ever touch online system
14:42 <+mgorny> but that's really topic of infra policy
14:43 <@K_F> (online is defined here as a system that is ever online)
14:43 <@K_F> i.e never any network connectivity
14:44 <@Whissi> If we will ever learn that the CA system we will create doesn't work and we have major concerns we could start another vote to kill the then existing GLEP 79, right?
14:45 <+mgorny> Whissi: yes
14:45 <@K_F> well, it doesn't really need changing GLEP 79 per se
14:45 <@WilliamH> Whissi: I don't see why not. 
14:45 <+mgorny> though if there are major issues, i suppose we'll just revoke the key without waiting for GLEP first
14:45 <@K_F> as the fingerprint of the CA key isn't specified there
14:45 <@Whissi> OK, let's move on and vote.
14:45 <@WilliamH> Whissi: Do you want to put forward a motion?
14:46 <@Whissi> Let's vote on the current proposal. We maybe update L1 details but this won't require a new vote.
14:47 <@WilliamH> Please vote on whether to approve GLEP 79.
14:47  * K_F yes
14:47  * Whissi yes
14:47  * slyfox abstains
14:48  * leio yes, provided the "is about to expire" change
14:49  * WilliamH abstains
14:49  * ulm abstains
14:50 <@WilliamH> We're missing a vote.
14:50  * dilfridge|mobile abstaining
14:50 <@WilliamH> The motion passes.
14:50 <@slyfox> \o/
14:50 <+mgorny> thank you
14:50 <+mgorny> leio: can i change it as editorial change, or should i send an update for ml comments?
14:50 <@WilliamH> moving on:
14:50 <@WilliamH> 3. open bugs with council involvement:
14:51 <@leio> I don't know, I'm not a glep editor ;p
14:51 <@WilliamH> https://wiki.gentoo.org/wiki/Project:Council#Open_bugs_with_Council_participation
14:51 <@K_F> mgorny: editorial, lets note it in summary of meeting
14:51 <@K_F> WilliamH: ^^
14:51 <@WilliamH> K_F: got it.
14:52 <@WilliamH> bug 677824
14:52 <+willikins> WilliamH: https://bugs.gentoo.org/677824 "Deferred decision: Forums (specifically OTW)"; Gentoo Council, unspecified; CONF; k_f:council
14:52 <@WilliamH> K_F: ^^
14:53 <@K_F> no update on that for this meeting (I'm not aware of anything at lesat)
14:53 <@slyfox> that bug has no forum people CCed
14:53 <@WilliamH> Do we want to add the forums mods to it then?
14:54 <@K_F> the bug is really just a reminder for us
14:54 <@K_F> the discussion was ongoing on the ML already
14:54 <@K_F> but it is somewhat dead
14:54 <@slyfox> IDK, i don't understand the puurpose of the bug. maybe it should link to the discussion thread
14:54 <@K_F> but the people wanting more discussion should pick up a discussion
14:54 <@K_F> slyfox: sure, it can do that
14:55 <@Whissi> There's a group of people who want to kill OTW. But I don't think that's the opinion of the majority (well, most people don't care).
14:55 <@K_F> slyfox: it is linked already in the post though
14:55 <@K_F> slyfox: you just need to go via the agenda link
14:55 <@slyfox> same thread?
14:55 <@slyfox> 'k
14:55 <@WilliamH> Whissi: I seem to remember an alternat proposal wrt otw, making it something like "anything linux related".
14:56 <@K_F> in any case, not really anything to spend time on now.. afaik no update on that bug
14:56 <@WilliamH> But that is true that most people probably don't really care much.
14:57 <@WilliamH> moving on then for now...
14:57 <@Whissi> The problem is, that most people who want to kill OTW aren't active in forum. Like I said last time, every forum needs such a place where you can move OT. Deleting stuff don't work. People will go crazy. So just move...  but yes, excluding from search by default, including search engines could be discussed.
14:57 <@K_F> search isn't really the material thing
14:57 <@dilfridge|mobile> Whissi: I don't subscribe to that idea.
14:58 <@K_F> it requires a huge amount of resources to monitor, and in particular it adds requirements to proctors/comrel if complaints on forum mods
14:58 <@WilliamH> dilfridge|mobile: Same here.
14:58 <@K_F> having such a forum seems to be an invitation for chaos
14:58 <@Whissi> Maybe make it member only forum, so you need an account to read. But if you will shutdown OTW, you will wake up a monster.
14:58 <@K_F> but we deferred the discusssion, and the discussion really should be on ML
14:58 <@K_F> member doesn't change anything
14:58 <@K_F> it ultimately makes moderation / monitoring worse; and might be against gentoo social contract
14:59 <@Whissi> Member only will change. You told me you are concerned because 3rd party not familiar with detail will find OTW posting and think "Oh Gentoo!"... if member only, they can't see.
15:00 <@K_F> SoC says "We will not hide problems"
15:00 <@K_F> but it is broader discussion than that, that is one proble,, but since responsibility of monitoring is put on other projects it is broader discussion than forum mods etc only
15:00 <@K_F> in any case, the discussion should be on ML
15:00 <@WilliamH> K_F++
15:00 <@K_F> the bug is just a reminder that we need to make a decision at some point, at which point it is brought up at agenda again
15:00 <@Whissi> OK, defer, next.
15:01 <@WilliamH> bug 662982
15:01 <+willikins> WilliamH: https://bugs.gentoo.org/662982 "[TRACKER] New default locations for the Gentoo repository, distfiles, and binary packages"; Gentoo Linux, Current packages; CONF; zmedico:dev-portage
15:01 <@K_F> to me it is very much a case of those protecting OTW needing to step up, though
15:01 <@WilliamH> I've wondered about this one myself, what are we waiting for?
15:01 <@K_F> WilliamH: iirc that is just a tracker, nothing requiring our involvement
15:02 <@ulm> I've CCed council to #662982 because there's only little progress since more than half a year
15:02 <@ulm> so we can keep an eye on it
15:02 <@WilliamH> Do we even know what the current status is?
15:02 <@ulm> zmedico posted a patch for portage
15:02 <@slyfox> worth asking in the bug
15:02 <@ulm> not sure what it blocking that patch
15:03 <@ulm> *is
15:03 <@slyfox> but it has 3 blocking bugs
15:03 <@Whissi> ulm asked for status in bug 378603
15:03 <+willikins> Whissi: https://bugs.gentoo.org/378603 "sys-apps/portage: FHS compliance of default PORTDIR & near friends"; Portage Development, Core - Configuration; CONF; mgorny:dev-portage
15:05 <@WilliamH> ok, so there's not really a lot we can do on this bug.
15:05 <@Whissi> ACK. Next bug.
15:06 <@WilliamH> bug 676248
15:06 <+willikins> WilliamH: https://bugs.gentoo.org/676248 "non-free licenses are accepted without user prompt"; Gentoo Linux, Profiles; CONF; whissi:licenses
15:06 <@K_F> we handled that one last meeting, really
15:07 <@K_F> its already commented on the bug as well
15:07 <@K_F> so next..
15:07 <@Whissi> Looks like we are waiting for portage-2.3.62 stable
15:07 <@slyfox> cool
15:07 <@WilliamH> bug 642072
15:07 <+willikins> WilliamH: https://bugs.gentoo.org/642072 "[Tracker] Copyright policy"; Gentoo Council, unspecified; IN_P; mgorny:council
15:07 <@ulm> another tracker
15:08 <@WilliamH> ulm: when can we close it?
15:08 <@ulm> repoman and devmanual still need an update
15:09 <@WilliamH> ulm: ok.
15:09 <@WilliamH> bug 637328
15:10 <+willikins> WilliamH: https://bugs.gentoo.org/637328 "GLEP 14 needs to be updated"; Documentation, GLEP Changes; IN_P; mgorny:security
15:10 <@K_F> no update
15:10 <@K_F> manpower is thin enough, so whatever time there is goes to actual security work
15:10 <@Whissi> :>
15:11 <@WilliamH> Next topic:
15:11 <@WilliamH> 4. Open Floor
15:11  * WilliamH listens
15:11  * veremitz 's stomach grumbles
15:12  * Whissi has nothing for open floor
15:12  * WilliamH bangs the gavel... meeting closed.
15:12 <@WilliamH> Thanks folks. :-)