diff options
authorWilliam Hubbs <>2019-03-10 15:22:49 -0500
committerWilliam Hubbs <>2019-03-10 15:23:31 -0500
commitd620a8917cef72a4f09ad944daf76be13984f7c4 (patch)
parentAdd meeting summary for 20190210 (diff)
add meeting log for 2019-03-10
Signed-off-by: William Hubbs <>
2 files changed, 330 insertions, 0 deletions
diff --git a/meeting-logs/20190310.txt b/meeting-logs/20190310.txt
new file mode 100644
index 0000000..93dea27
--- /dev/null
+++ b/meeting-logs/20190310.txt
@@ -0,0 +1,314 @@
+14:01 <@WilliamH> Ok folks, let's get started.. We have a pretty light agenda today...
+14:01 <@WilliamH>
+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>
+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 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>
+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: "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: "[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: "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: "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: "[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: "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. :-)
diff --git a/meeting-logs/20190310.txt.asc b/meeting-logs/20190310.txt.asc
new file mode 100644
index 0000000..1d34f95
--- /dev/null
+++ b/meeting-logs/20190310.txt.asc
@@ -0,0 +1,16 @@