meetings: Create logs dir for logs

Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>

4 files changed, 1030 insertions, 0 deletions

diff --git a/meetings/logs/sec-meeting-2018-02-18-log b/meetings/logs/sec-meeting-2018-02-18-log
new file mode 100644
index 0000000..1fd2dc6
--- /dev/null
+++ b/meetings/logs/sec-meeting-2018-02-18-log
@@ -0,0 +1,231 @@
+2018-02-18 14:01:52	@K_F	Roll call
+2018-02-18 14:01:54	 *	K_F here
+2018-02-18 14:01:57	 *	ChrisADR here
+2018-02-18 14:02:05	@ackle	here
+2018-02-18 14:02:39	ChrisADR	hi ackle nice to meet you :)
+2018-02-18 14:02:45	 *	Pinkbyte here
+2018-02-18 14:03:16	@ackle	Hi Chris, welcome aboard
+2018-02-18 14:03:27	ChrisADR	nice to meet you too Pinkbyte :)
+2018-02-18 14:03:32	ChrisADR	thanks :) glad to be here
+2018-02-18 14:04:11	@K_F	hmm, don't think I have whissi's phone # around to send SMS..
+2018-02-18 14:04:31	@K_F	so lets just start, and if he shows up he can read backlog anyways
+2018-02-18 14:04:50	@Pinkbyte	ChrisADR, we are all always welcome fresh blood, so - nice to see you amongst us
+2018-02-18 14:04:58	@Pinkbyte	s/fresh/for fresh/
+2018-02-18 14:05:22	@K_F	the four regular agenda items I've noted for today are (in short); (i) GLEP14 updates (ChrisADR can tell a bit about the changes he has done and what he wants help on forwards, and discusion if there is anything)
+2018-02-18 14:05:44	@K_F	(ii) glsamaker (iii) kernel sec and (iv) operator / access list in here (although mostly deferred until after a lead is in place)
+2018-02-18 14:06:30	@K_F	are there anything else we should discuss today? as a pro-forma I listed open bugs as well, in particular #624262, but that is more to remember than to discuss today
+2018-02-18 14:07:06	@blueknight	Sorry was watching a show.. here
+2018-02-18 14:07:39	@Pinkbyte	K_F, it would be nice if something about #624262 would be done. I remember those days when confidential mails from bugzilla were... confidential :-)
+2018-02-18 14:08:13	@K_F	Pinkbyte: right, which is why we have a bug, I just don't see anything from us being done about it today.. that said it is listed as a GSoC project this year as well
+2018-02-18 14:08:58	@K_F	so, ChrisADR you've been the one most active with trying to refurbish glep 14 c.f bug 637328
+2018-02-18 14:09:00	willikins	K_F: https://bugs.gentoo.org/637328 "GLEP 14 needs to be updated"; Documentation, GLEP Changes; CONF; mgorny:security
+2018-02-18 14:09:19	@K_F	what is the status of the update and what is needed from us on it before we can pass it around for approval?
+2018-02-18 14:09:39	@K_F	I take it everyone here has access to the updated files in git.gentoo.org/proj/security/private.git:/documentation/glep-0014.rst ?
+2018-02-18 14:09:44	@K_F	or should I make a copy of it somewhere public?
+2018-02-18 14:09:52	ChrisADR	ok, short and simple :) I'm a bit concerned about the implementation
+2018-02-18 14:10:34	ChrisADR	quoting from the source code: " WARNING: this code is only tested by a few people and should NOT be used
+2018-02-18 14:10:34	ChrisADR	# on production systems
+2018-02-18 14:10:37	ChrisADR	"
+2018-02-18 14:11:04	@K_F	ChrisADR: heh, indeed, that is code you don't want seen relied on in production systems :)
+2018-02-18 14:11:18	@K_F	(or at least comment, presumably it actually _is_ well tested by now)
+2018-02-18 14:11:56	ChrisADR	yea :) ok, the thing is that we need either to remove that comment, ensuring that glsa-check is actually tested, to be able to mark the GLEP as implemented, or keep it as "work in progress"
+2018-02-18 14:12:49	@K_F	it has been used in production for a number of years, so unless it is a very specific corner case, we can likely remove the comment now
+2018-02-18 14:13:00	ChrisADR	but I see that most of the work was done till 2015, except a couple of patches in 2016 and 2017
+2018-02-18 14:13:26	ChrisADR	ok, sounds good to me, the rest of the GLEP is just an update to the current status
+2018-02-18 14:14:00	@Pinkbyte	K_F, true. I remember exactly one breakage(which happens in this year) of glsa-check since i use it(from 2009 at least, iirc)
+2018-02-18 14:14:02	@K_F	so, should we vote for an approval of it in this meeting, or do a final circulation on email for comment?
+2018-02-18 14:14:16	@K_F	(approval in this context means we submit it to council)
+2018-02-18 14:14:40	ChrisADR	I'd prefer a circulation, I'd appreciate a peer review and then decide if everything is ok to send to council
+2018-02-18 14:14:47	@K_F	ChrisADR: actually one thing I noticed, which is nitpick when reading it is most references to GPG should be OpenPGP
+2018-02-18 14:15:04	@K_F	unless it reference the specific implementation
+2018-02-18 14:15:29	@K_F	e.g "verifies its OpenPGP signature" instead of "GPG signature"
+2018-02-18 14:16:13	@K_F	but right, if you can send out a call for comment we can deal with it with a deadline of 1 week from you send it out?
+2018-02-18 14:16:23	ChrisADR	yea, actually afaik we don't verify signatures per se, we assume that because of the signed commits in the repo
+2018-02-18 14:17:09	@K_F	signed commits aren't relevant, would be the signed MetaManifest or the signature of the web download, there aren't any good ways to verify the git commit signatures, in particular in context of retired devs and revoked keyblocks
+2018-02-18 14:17:41	@K_F	but if the tool doesn't check the signature, we want to update the GLEP to reflect that
+2018-02-18 14:18:06	ChrisADR	There are still a couple of sections that I have not changed, I hoped to send a proposal to the mail and discuss those specific implementations since I don't have it totally clear
+2018-02-18 14:18:15	@K_F	and/or write that it expects the tree consistency to be in place due to verification done during portage / gemato sync (but keep in mind that won't help paladius or pkgcore users)
+2018-02-18 14:19:33	@K_F	but right, lets do that by email then, that works for me
+2018-02-18 14:19:40	ChrisADR	ok, great
+2018-02-18 14:19:41	@K_F	any other comments from anyone on the subject before we move on?
+2018-02-18 14:20:14	@blueknight	Nothing from the peanut gallery :)
+2018-02-18 14:21:21	@K_F	ChrisADR: you also brought up glsamaker, want to lead in with your thoughts?
+2018-02-18 14:22:23	@K_F	i.e are there specific concerns, or just a generic discussion on whom takes responsibility for maintenance etc?
+2018-02-18 14:23:35	ChrisADR	well I was thinking about the whole project implementation, I know whissi is the only one developing it right now, but it's hard for him because of ruby... at first I was thinking to prepare a new version of glsamaker, but now I'd like to propose a new idea
+2018-02-18 14:23:53	 *	K_F is all ears
+2018-02-18 14:24:45	@K_F	but yes, it being ruby is actually an issue on a few points, including maintenance since not too many use it, that is also a problem with a few other sites, including packages.g.o
+2018-02-18 14:24:47	ChrisADR	alice sent an email announcing that we are officialy part of the Google Summer of Code, I was thinking (maybe not this year, but next one, given the availability from our team) to propose a project there and be mentors from a student
+2018-02-18 14:25:26	@Whissi	_No_. :)
+2018-02-18 14:25:30	@K_F	I'm not a fan of that idea, too many projects historically that have been written and not properly implemented in practice, and if we want to rewrite, it is to make sure codebase is familiar to security team
+2018-02-18 14:25:46	@K_F	and having a student at gsoc is 3-5 times the work of just doing it yourself
+2018-02-18 14:25:51	@K_F	or more..
+2018-02-18 14:25:56	ChrisADR	I guess that if it's in Python (django at least) it may be easier for the whole developers here to have an idea of how it works?
+2018-02-18 14:26:04	@K_F	in particular when we're starting from scratch, it is easier for a specific feature in existing framework
+2018-02-18 14:26:23	@ackle	Not a fan either, tools from GSoC have seemed... unreliable to me in the past
+2018-02-18 14:26:25	@K_F	django suffers from a number of same issues as ruby does with upgrades and compatability
+2018-02-18 14:26:34	@K_F	so that also easily gets stuck, and is difficult to properly package
+2018-02-18 14:26:46	@blueknight	ackle: you have a working demo version is that correct?
+2018-02-18 14:26:52	ChrisADR	ok out of ideas :P
+2018-02-18 14:26:58	@Pinkbyte	Well, we should feel ourselves pretty lucky that it is Ruby and not Haskell for example :-D
+2018-02-18 14:27:05	@ackle	Yes, I have a working dev system for glsamaker
+2018-02-18 14:27:34	@K_F	ackle: to ensure we're talking of same thing, you have a dev system of the current implementation
+2018-02-18 14:27:54	@K_F	I'm personally in favor of throwing in some more resources on existing system rather than rewriting from scratch, as I know that will bring bugs on its own
+2018-02-18 14:27:59	@ackle	Also to point out: in the past we've always said that a major change to glsamaker should probably be in tandum with an overhaul of the GLSA format (to make it easier to automate announcements)
+2018-02-18 14:28:07	@K_F	unless we have specific features that we know needs a solid rewrite (e.g proper CVE handling)
+2018-02-18 14:28:28	@K_F	but if we want to write a new system we need to do a full RFP / spec of what is needed before starting out
+2018-02-18 14:28:32	@Whissi	Yes. We should first think about what we want before we think about how we reach the goal.
+2018-02-18 14:29:05	@K_F	not necessarily only GLSA format though, that is output format only, we have a lot of background work that never sees the public
+2018-02-18 14:29:20	@ackle	K_F: yes, I keep an updated and running copy on one of my VMs for when I've made changes to glsamaker.g.o
+2018-02-18 14:29:26	@blueknight	ackle: Can we replicate your dev build in to a location where others have access?
+2018-02-18 14:29:43	@K_F	ackle: nice, do you have any notes for setting it up etc if others wants to replicate?
+2018-02-18 14:29:47	@blueknight	or share the VM?
+2018-02-18 14:30:19	@K_F	instead of sharing the VM, might want to do a replication of the pushing at infra
+2018-02-18 14:30:33	@ackle	I'm sure I have notes on setting it up. If infra can provide a VM, we could get a shared test system out there
+2018-02-18 14:30:34	@K_F	and have a git repo we can commit changes to for testing, instead of full access on VM
+2018-02-18 14:31:07	@K_F	in my experience testing without audit is often difficult to replicate in production system due to lack of documentation
+2018-02-18 14:31:27	@K_F	of course that brings question of whether we want a test system along with a dev system
+2018-02-18 14:31:30	@Whissi	For me the problem is testing vs bugzilla
+2018-02-18 14:32:41	@Whissi	Like testing the "close bugs" think... it requires a open bug... hard to test if you don't have a testing bugzilla ;)
+2018-02-18 14:32:53	ChrisADR	and our own bugzilla for tests? 
+2018-02-18 14:33:17	@ackle	There are various caveats with testing, such as connecting it to a test Bugzilla instance (as Whissi is stating) and having actual information in the database for validation (something that bit me in the butt before)
+2018-02-18 14:33:36	@K_F	Whissi: iirc infra has a testing infrastructure for bugzilla, maybe we can get some resources on that?
+2018-02-18 14:34:06	@K_F	but indeed, there will be references to bug numbers not existing etc etc
+2018-02-18 14:34:24	@K_F	unless it is done in a testing envoronment that synchronize / copy daily or weekly or whatever
+2018-02-18 14:36:13	@K_F	(I believe this is the one I'm thinking of.. http://bugstest.gentoo.org )
+2018-02-18 14:38:33	@K_F	but right, I'm putting that down for another subject to continue discussing on email.. but before doing any big changes I strongly recommend we figure out if we need major new features, and if we do figure out what we need (including testing infrastructure etc) before starting a new project on it
+2018-02-18 14:39:52	@K_F	So; (iii) kernel sec team
+2018-02-18 14:40:06	@K_F	ChrisADR: again, you had some questions on this, want to start up discussion?
+2018-02-18 14:40:15	ChrisADR	ok, sure
+2018-02-18 14:40:52	ChrisADR	it may be a good idea to define a structure, like the vulnerability treatment policy
+2018-02-18 14:41:01	@blueknight	I have an idea ... I am thinking we might want to put together a Trello for our team so we can put down the requirements?
+2018-02-18 14:41:01	ChrisADR	I propoce 3 states right now
+2018-02-18 14:41:26	ChrisADR	that's a good idea
+2018-02-18 14:42:05	@K_F	what is Trello?
+2018-02-18 14:42:25	ChrisADR	so, [upstream] as always, [cve] as archived in our db, and a new [backported](just basic idea) which means if we have that specific fix available in our *-sources
+2018-02-18 14:42:28	@blueknight	Trello is a free on line Todo / Project management with multi edit capabilitles.
+2018-02-18 14:42:36	@K_F	is it free software?
+2018-02-18 14:42:43	@blueknight	Free on-line service
+2018-02-18 14:42:43	@Pinkbyte	K_F, proprietary online service for kanban-like tasking and stuff
+2018-02-18 14:42:56	@K_F	meh, lets stick to formats people can use
+2018-02-18 14:43:05	@Pinkbyte	K_F, agreed
+2018-02-18 14:43:21	@K_F	but for kernel issues, its a bit of a catch 22
+2018-02-18 14:43:50	@K_F	1) we don't have resources to track the vulnerabilities, and the upstream recommendation is just to always use latest point release of long term stable branch
+2018-02-18 14:44:02	@K_F	2) upstream doesn't properly flag vulnerabilities (see 1)
+2018-02-18 14:44:19	@K_F	3) we don't have tooling to check the running kernel on a given system and what patches are potentially applied
+2018-02-18 14:44:46	@Whissi	Regarding kernel: The kernel project will move to some kind of auto-stabilizing later this year. At least we plan something like that.
+2018-02-18 14:44:48	@K_F	which mostly result in , sure, we can track some, in particular for release coordination, but in general, kernel is on its own
+2018-02-18 14:44:59	@Whissi	So the meaining of stable kernel in Gentoo _will_ change.
+2018-02-18 14:45:13	@K_F	Whissi: iirc they are using the proposal from the stable wg ?
+2018-02-18 14:45:27	@K_F	I wouldn't agree it is changing stable status if so
+2018-02-18 14:45:44	@K_F	mainly due to upstream stability guarantee, and only point releases of an already stabilized LTS will be auto-stabled
+2018-02-18 14:45:50	@Pinkbyte	Whissi, if it would be sticking to latest possible LTS point releases - blame me, if i will be against it :-)
+2018-02-18 14:46:36	@Whissi	Currently, in Gentoo, stable kernels means something like a GA status. I.e. only mark a kernel stable if we know it works on most hardware or aren't aware of any criticial problems which may affect *some* setups.
+2018-02-18 14:47:16	@Whissi	That's the reason why 4.14.x is still not being stabilized in Gentoo... because we are aware of *some* problems... however, 4.14.x is now better and works for *most* users... but still not ready to be named *GA*.
+2018-02-18 14:47:38	@Whissi	But this is going to change.
+2018-02-18 14:47:47	@K_F	right, 4.14 is a mess on libdrm and kernel mode buffers
+2018-02-18 14:48:00	@K_F	kernel modeline*
+2018-02-18 14:48:05	@blueknight	So they are going to roll the dice with automated building
+2018-02-18 14:48:17	@K_F	not really
+2018-02-18 14:48:39	@K_F	if they only stable latest point release as policy, it is easy to do a package mask for newer kernel branches
+2018-02-18 14:48:48	@K_F	first thing I do on any system after installing is masking any higher branch
+2018-02-18 14:48:56	@K_F	and only switching once LTS is EOL
+2018-02-18 14:49:13	@Whissi	I.e. in future we hope to have a working CI which will start testing when upstream kernel reaches RC. Once released, we will add and mark stable within 24-48h. If we get aware of any problems we maybe decide to pause/skip this version... or add patches like before. But in general the idea is to follow upstream within 48h.
+2018-02-18 14:49:27	@Whissi	(_stable_ within 48h)
+2018-02-18 14:49:27	@Pinkbyte	K_F, i forced to do this on one of my HP servers. Which breaks badly on 4.12 and 4.14
+2018-02-18 14:49:52	@blueknight	Well in either case... I think we stick to what we have done before
+2018-02-18 14:49:55	@K_F	Pinkbyte: most server systems do it like that anyways
+2018-02-18 14:50:12	@K_F	blueknight: you're not talking for security project? in which case I agree
+2018-02-18 14:50:25	@K_F	we have the project more as a discussion point and placeholder, but we shouldn't give any security guarantee for actual tracking
+2018-02-18 14:50:40	@blueknight	Well isn't this what we are talking about?
+2018-02-18 14:50:44	@K_F	we don't have the resources for it, and the best recommendation is "use latest upstream point release"
+2018-02-18 14:51:01	@K_F	blueknight: _could_ be a reference to kernel team's stable policy
+2018-02-18 14:51:09	@K_F	just wanted to have the statement in proper context
+2018-02-18 14:52:43	@blueknight	The non politically correct version is "no one tracks what is in the Kernel, we take whatever is available upstream and go with it"
+2018-02-18 14:54:30	@K_F	so, unless there are further comments on that, the next one I have is the channel IRC modes
+2018-02-18 14:55:00	@K_F	as explained in email already, that is easy to fix, but easier to do cleanup after a lead is in place as he/she would be natural Founder of channel that can then fix the other modes
+2018-02-18 14:55:58	@K_F	so I propse we defer that point
+2018-02-18 14:56:05	@Whissi	Well, I guess ChrisADR wants that we will write down that we track usally only focus >=A2 vulns for kernels. I.e. write down, that we don't track anything else due to lacking man power.
+2018-02-18 14:56:22	@K_F	we don't officially track anything
+2018-02-18 14:56:42	@blueknight	We do not track Kernel, and I would not want to track anything in Kernel
+2018-02-18 14:56:54	@blueknight	If the Kernel team does not know what is fixed, how shoudl we
+2018-02-18 14:57:03	@K_F	we can help coordinate etc, but we don't _track_ anything
+2018-02-18 14:57:15	@Whissi	Well, I try to track anything >=A2 and especially anything I find in the media.
+2018-02-18 14:57:37	@Pinkbyte	K_F, about channel modes - did i miss something? blueknight is currently team lead and can ask for channel ownership in #gentoo-groupcontacts, no?
+2018-02-18 14:57:42	@K_F	right, but you do that out of the goodness of your heart and not policy :)
+2018-02-18 14:57:50	@Whissi	yeah
+2018-02-18 14:57:52	@blueknight	Pinkbyte: I resigned due to time constraints
+2018-02-18 14:57:54	@K_F	Pinkbyte: right, but if we need to switch that anyways
+2018-02-18 14:58:20	@K_F	Pinkbyte: its easier to just wait for new lead to be in place
+2018-02-18 14:58:21	@blueknight	I do not feel it is right by the team since I can not dedicate a lot of time.
+2018-02-18 14:58:33	@Pinkbyte	blueknight, ok then, missed that e-mail(or just forgot about reading it, i am such a dumbass these days)
+2018-02-18 14:58:46	ChrisADR	blueknight: can you try to set -O on my nick?
+2018-02-18 14:58:57	@K_F	+AO you mean :)
+2018-02-18 14:59:01	ChrisADR	capital o letter
+2018-02-18 14:59:04	@blueknight	Chris I do not have rights
+2018-02-18 14:59:17	ChrisADR	well that's what the discussion is about
+2018-02-18 14:59:25	@Pinkbyte	according to chanserv info - a3li and keytoaster are channel founders
+2018-02-18 14:59:28	ChrisADR	I thought for one sec that you had those rights
+2018-02-18 14:59:36	@Pinkbyte	so only them can fully manage channel
+2018-02-18 14:59:38	ChrisADR	sorry, missed the flow 
+2018-02-18 15:00:27	@blueknight	Both keytoaster and Alex can be contacted to make the rights accordingly moved... so not a big deal
+2018-02-18 15:00:43	@ackle	Is there anything else to discuss?
+2018-02-18 15:00:51	@K_F	blueknight: we don't even need that if a new lead is in place (or if you want to have them now)..
+2018-02-18 15:00:58	@K_F	but right.. any other agenda item?
+2018-02-18 15:01:14	@K_F	if not we've managed to stay at timeline outlined, which is good in itself :
+2018-02-18 15:01:17	@K_F	:)
+2018-02-18 15:01:32	@K_F	I generally believe a few short meetings like this more frequently is a good thing
+2018-02-18 15:01:41	 *	Pinkbyte remember 2-3 hours meetings of Qt team. That was a bit of a pain...
+2018-02-18 15:01:58	ChrisADR	maybe set a couple of goals till the next meet?
+2018-02-18 15:02:02	@blueknight	So since we are all here.... I have one
+2018-02-18 15:02:11	@K_F	blueknight: floor is yours
+2018-02-18 15:02:24	@blueknight	What has been decided is going to be done with picking the new lead.
+2018-02-18 15:02:35	@blueknight	lead or leads
+2018-02-18 15:03:10	@K_F	I haven't seen any conclusions on anything
+2018-02-18 15:03:27	@ackle	We should probably arrange for nominations and election
+2018-02-18 15:03:33	@K_F	so guess someone just needs to actually call for election and chose a format (email, heliosvoting, etc etc)
+2018-02-18 15:03:36	@Whissi	Well, we can start a new election already or wait the remaining 2-3 month....
+2018-02-18 15:04:08	@blueknight	K_F: I propose smoke signals as the means (joke)
+2018-02-18 15:04:21	@K_F	blueknight: I have my Padron 7000 currently, so I'm ready to blow smoke rings :)
+2018-02-18 15:06:11	@blueknight	Ok so do you guys want to wait, or do elections. Lets vote
+2018-02-18 15:06:17	@Pinkbyte	Whissi, quick note from other team's lead - e-mail voting can be 2 weeks long... But it's not the problem. Problem is when you win election, because no one else was nominated. I hope that would be not the case with security :-/
+2018-02-18 15:06:22	@K_F	blueknight: I'd say it is more up to you than anything else
+2018-02-18 15:06:36	@blueknight	I resigned, so it is up to the team
+2018-02-18 15:07:02	@K_F	blueknight: well, if you take the resignation as a point after regular election or if you want to be freed of responsibilities already
+2018-02-18 15:07:10	@blueknight	So lets vote .... who wants election, and who wants tow ait.
+2018-02-18 15:07:29	@Whissi	Pinkbyte: I would propose a different way this time: Everyone is nominated... and has _one_ week to accept. After the week we would start normal voting via mail.
+2018-02-18 15:07:42	@Whissi	But this would be pre-announced
+2018-02-18 15:07:43	@K_F	blueknight: if you don't expect to be able to be around, I recommend just having election now
+2018-02-18 15:07:50	@Pinkbyte	I suppose that in that case we should roll election earlier. One week for nomination, two weeks of voting... Around a month will be only procedure going...
+2018-02-18 15:08:16	@Pinkbyte	Whissi, well, we are(not all of us, blame me) pretty active and responding team, so your proposal make sense
+2018-02-18 15:08:17	@Whissi	You really want 2 weeks voting?
+2018-02-18 15:08:47	@Whissi	7d should be enough, not?
+2018-02-18 15:09:03	@K_F	I generally would expect members to be able to respond in a week, in particular since it is pre-announced periode
+2018-02-18 15:09:15	@blueknight	7d does not account for anyone that has vacation (Holiday) or a business trip
+2018-02-18 15:09:18	@K_F	so 2 weeks since announcement ,if 1w acceptance periode)
+2018-02-18 15:09:23	@Pinkbyte	Whissi, i am not. I am just saying how it is in QA team. Last time there was no voting, because there are only me nominated
+2018-02-18 15:09:44	@K_F	blueknight: well, it is 2 weeks announcement since beginning of voting process
+2018-02-18 15:09:45	@blueknight	I recommend 2 weeks.
+2018-02-18 15:09:49	@K_F	s/voting/election/
+2018-02-18 15:10:06	@K_F	people should be in a position to read their email in that time
+2018-02-18 15:10:10	@blueknight	No but if I go on vacation or a business trip and do not have my GPG key to vote with me (because I forgot it or something),...
+2018-02-18 15:10:24	@ackle	Is there a reason why 2w is not reasonable? Or is it just impatience?
+2018-02-18 15:11:02	@Whissi	Well, with announcement we actual have >7d... but an actual voting period for >7d is a bit long, given that the "big" elections like council will happen in just 7d... not sure why security would need 14d...
+2018-02-18 15:11:04	@K_F	blueknight: right, but arguably that is more a question of whether we should require OpenPGP signatures, although I'm somewhat biased in that and mean everyone should have that pretty accessible in security project :)
+2018-02-18 15:11:46	@K_F	council voting is upen for 15 days
+2018-02-18 15:12:04	@K_F	after a 15 day nomination periode
+2018-02-18 15:12:09	@blueknight	But when I go on vacation I purposly disconnect for 7 days ... (usually on a cruise ship, where I do not buy internet)>
+2018-02-18 15:12:10	@Pinkbyte	Whissi, nobody denies shortening voting period IF all of team members are already voted or if clear winner is discovered
+2018-02-18 15:12:29	@Whissi	OK. I am not against 2 weeks. Just wondered :)
+2018-02-18 15:12:41	ChrisADR	council voting?
+2018-02-18 15:12:57	@ackle	I have to run... have fun painting that shed, folks ;)
+2018-02-18 15:13:03	@Whissi	I'll send my proposol for the election later tonight.
+2018-02-18 15:13:06	@K_F	ChrisADR: election
+2018-02-18 15:13:15	@K_F	ChrisADR: the voting part of the election process for council
+2018-02-18 15:13:21	ChrisADR	sorry, bad translation, ok got it
+2018-02-18 15:13:35	@K_F	Whissi: ok, putting you down to organize it then :)
+2018-02-18 15:13:43	@blueknight	OK.. with this meeting being done... Have a good day everyone.
+2018-02-18 15:13:57	@Whissi	No problem. Will be my 3rd Gentoo election I organized this year ;)
+2018-02-18 15:14:07	@K_F	sounds good, then I have 15 minutes until next meeting
+2018-02-18 15:14:08	@Pinkbyte	blueknight, you too. I should go to bed, though, it's 23:15 on my clock :-)
+2018-02-18 15:14:12	@K_F	have a nice evening everyone
+2018-02-18 15:14:15	 *	K_F bangs gavel
diff --git a/meetings/logs/sec-meeting-2018-04-21-log b/meetings/logs/sec-meeting-2018-04-21-log
new file mode 100644
index 0000000..a599742
--- /dev/null
+++ b/meetings/logs/sec-meeting-2018-04-21-log
@@ -0,0 +1,269 @@
+2018-04-21 15:00:19	@K_F	meeting time
+2018-04-21 15:00:45	@ChrisADR	!proj security
+2018-04-21 15:00:46	willikins	ChrisADR: (security@gentoo.org) a3li, ackle, blueknight, bman, chrisadr, creffett, k_f, pinkbyte, whissi, zlogene, zx2c4
+2018-04-21 15:01:17	 *	Pinkbyte is here
+2018-04-21 15:01:24	 *	K_F here
+2018-04-21 15:01:26	 *	ChrisADR here
+2018-04-21 15:01:41	 *	b-man is here
+2018-04-21 15:03:09	 *	Whissi is here
+2018-04-21 15:03:49	@ChrisADR	ok, 2 more mins and shall we begin?
+2018-04-21 15:04:08	@K_F	just begin
+2018-04-21 15:04:37	@K_F	if others joins we'll just record it as present
+2018-04-21 15:04:47	@ChrisADR	ok, so first topic on the list, Security GLEPs
+2018-04-21 15:05:29	@K_F	due to other issues, I haven't gotten around to writing up a specific GLEP 14 replacement at this time
+2018-04-21 15:05:57	@K_F	but the current status is we likely want to change sufficient enough to do a replacement..
+2018-04-21 15:06:10	@b-man	K_F: Do you have a shell or rough draft already?
+2018-04-21 15:06:29	@K_F	in terms of the implementations I'm going in direction we implement it in portage, and use that as reference implementation
+2018-04-21 15:06:39	@K_F	if other PMs wants glsa-check support they can implement it themselves
+2018-04-21 15:06:43	@b-man	I know you are doing a lot of work with big Gentoo problems... so if I can help let me know
+2018-04-21 15:07:13	@K_F	but yeah, we should keep timeline for this meeting to 2h, as trustee meeting starts then
+2018-04-21 15:07:35	@ChrisADR	ok, sounds good, talking about implementations, are we going to split glsa-check in a different GLEP?
+2018-04-21 15:07:58	@ChrisADR	or better stated, the standard so other PMs can use our data
+2018-04-21 15:08:02	@K_F	glsa-check would be an implementation, so not a specific GLEP needed per se
+2018-04-21 15:08:13	@K_F	if we want a GLEP it would be to describe the format of our GLSAs
+2018-04-21 15:09:03	@K_F	there are two ways of doing that, one is to describe that we maintain a schema for GLSAs in the security GLEP but not the details
+2018-04-21 15:09:27	@K_F	but directing to where the schema is described and in what format, which gives us more flexibility
+2018-04-21 15:09:40	@K_F	and of course we should version it appropriately
+2018-04-21 15:10:06	@b-man	agreed
+2018-04-21 15:10:29	@K_F	I don't necessarily see the need for a GLEP for the GLSA format specifically, as long as we take care of some timeline before introducing backward breaking changes
+2018-04-21 15:11:08	@K_F	but my take is we should provide the reference implementation in the standard stage3 which is portage
+2018-04-21 15:11:16	@Whissi	The format itself doesn't need a GLEP like we don't have a GLEP for ebuilds. But I am not sure if we should define basic functionality we expect from a security tool implementation.
+2018-04-21 15:12:02	@K_F	well, ebuilds have PMS
+2018-04-21 15:12:06	@Whissi	Things like "checking against GLSA data, when affected MUST end with non-zero exit or something like that.
+2018-04-21 15:12:53	@b-man	Looks to me like you are thinking along the same lines.
+2018-04-21 15:14:55	@b-man	We would not be blocking any PM from implementing their own security methods.
+2018-04-21 15:15:24	@K_F	right, we should describe the format and a reference implementation, but not support for all PMs
+2018-04-21 15:15:42	@K_F	but we should of course take that into consideration when doing actual changes
+2018-04-21 15:16:05	@K_F	e.g a 1-2 month delay from using new features after they are described
+2018-04-21 15:16:09	@b-man	and I am favor of *not* making security responsible for a specific tools development
+2018-04-21 15:16:56	@b-man	We can define the standard as Kristian has descibred and let the PM's do their development
+2018-04-21 15:17:46	@K_F	currently that is a dtd, we likely want to move it to a xml schema to have some flexibility, but it doesn't really affect GLEP 14 replacement per se
+2018-04-21 15:18:58	@ChrisADR	I guess it all will be clearer once we have the first draft about what we expect the kind of data to present to users, with that each PM could prepare the best way to approach the situation
+2018-04-21 15:19:54	@K_F	in all fairness, that won't deviate much from the current dtd
+2018-04-21 15:20:03	@b-man	+1
+2018-04-21 15:20:04	@Whissi	K_F: We already created a new XSD (thanks to mgorny).
+2018-04-21 15:20:24	@K_F	yes, which I prefer to use as the specs
+2018-04-21 15:20:43	@ChrisADR	ok then, do you agree to skip this topic until we have more solid information about the implementation?
+2018-04-21 15:20:52	@K_F	wfm
+2018-04-21 15:21:07	@K_F	or rather, the implementation has less interest, the specs does
+2018-04-21 15:21:20	@Whissi	OK, let's move to the next topic.
+2018-04-21 15:21:50	@ChrisADR	ok, glsamaker status...
+2018-04-21 15:22:19	@ChrisADR	on my mail I made the mistake of writing LTS support, it should have been community support for rails 4.x
+2018-04-21 15:23:10	@ChrisADR	but the result is pretty much the same I guess... do we need to start working in the documentation for an update or from scratch project?
+2018-04-21 15:23:33	@Whissi	Given that glsamaker isn't a public application it is acceptable to keep running code without support. Not nice, but not a big drama.
+2018-04-21 15:23:36	@K_F	rewriting from scratch is a big job
+2018-04-21 15:24:15	@K_F	I'm generally very sceptical of doing it, and if doing it, we need to take the time to write up a proper RFP for where we want to end
+2018-04-21 15:24:37	@Whissi	Yeah...
+2018-04-21 15:24:51	@ChrisADR	ok, is someone willing to take the RFP paperwork?
+2018-04-21 15:25:09	@K_F	at this time I'd say we stick to working with the current implementation
+2018-04-21 15:25:16	@Whissi	I have talked about this with blueknight before, we maybe should look into https://github.com/archlinux/arch-security-tracker
+2018-04-21 15:26:16	@Whissi	Goal should be to automate it a lot with the result to have GLSA for more packages, i.e. even for B/C and 3/4 rated things... just because we track things differently
+2018-04-21 15:26:34	@b-man	How would moving impact our database impl and CVE status with upstream?
+2018-04-21 15:27:02	@ChrisADR	yea, the thing is that I think that with our current implementation we are not achieving the goal
+2018-04-21 15:27:19	@b-man	Whissi: I agree on automation.
+2018-04-21 15:27:24	@Whissi	Sorry, don't get this. Please re-phrase, b-man
+2018-04-21 15:27:37	@ChrisADR	which, agree, should be to cover as much as possible from the stable gentoo ebuild repository
+2018-04-21 15:27:38	@Whissi	(the database impl thing)
+2018-04-21 15:27:49	@b-man	If we look at more automation though we will need to agree on dropping some of the verbiage in GLSA's.
+2018-04-21 15:28:24	@K_F	I find actually working through the bugs to be necessary in determining the impact for gentoo
+2018-04-21 15:28:31	@b-man	Whissi: Our database implementation which has all of our CVE data.  I want to ensure we don't impact that as (to my understanding) it can affect our standing as a CVE source?
+2018-04-21 15:28:48	@Whissi	We are no CVE source.
+2018-04-21 15:29:04	@b-man	Maybe Kristian can clarify what our CVE standing/status is.
+2018-04-21 15:29:11	@K_F	we're not a CVA atm, so that doesn't change much
+2018-04-21 15:29:36	@b-man	Whissi: Right, I am using the wrong term, but whatever our CVE role may or may not be
+2018-04-21 15:29:41	@K_F	we likely want to become one at some point, in particular for Gentoo specific issues which is a natural step (e.g init scripts etc)
+2018-04-21 15:29:52	@K_F	CNA*
+2018-04-21 15:29:59	@b-man	CNA... that's it
+2018-04-21 15:30:30	@K_F	but I don't see a reason for us to be a global CNA at this point, so if we go that route it is for gentoo specific issues
+2018-04-21 15:30:55	@b-man	Whissi: Have you deployed this Arch security tool?  Will it assist our workflow?
+2018-04-21 15:31:12	@Whissi	It will be a new workflow.
+2018-04-21 15:31:21	@Whissi	Arch Linux use to to group vulns
+2018-04-21 15:31:30	@Whissi	and to track vulns in first place
+2018-04-21 15:31:36	@ChrisADR	and before moving to a CNA role, we first need to be able to track our packages, for example we have >200 vulns that need to be tracked in cvetool
+2018-04-21 15:31:39	@Whissi	b.g.o would only be the detailed bug per packages
+2018-04-21 15:31:45	@Whissi	bug the main thing will happen in this tool
+2018-04-21 15:32:04	@Whissi	This is necessary because b.g.o doesn't really allow grouping
+2018-04-21 15:32:06	@ChrisADR	or at least sorted and/or reported
+2018-04-21 15:32:09	@Whissi	and such a thing
+2018-04-21 15:32:40	@b-man	Whissi: Ok, do you see it as an easy task to include code to output the GLSA XML?
+2018-04-21 15:32:49	@b-man	i.e. integrate
+2018-04-21 15:32:54	@Whissi	Yes.
+2018-04-21 15:33:13	 *	b-man is a fan of testing it
+2018-04-21 15:33:36	@ChrisADR	Whissi: could you prepare a testing env so that we all could see it?
+2018-04-21 15:33:38	@Whissi	https://security.archlinux.org/ frontend
+2018-04-21 15:33:54	@b-man	Whissi: Yes, checking it out :)
+2018-04-21 15:33:56	@K_F	testing alternative implementation is of course always good, but I'd say we can work on automating our current implementation instead of switching over
+2018-04-21 15:34:38	@b-man	K_F: I would like that very much, but I think the learning curve is a hinderance to whatever the hell that thing is designed in.
+2018-04-21 15:34:50	@b-man	(I know what it is built in... sorry for the dramatic response :))
+2018-04-21 15:35:36	@ChrisADR	besides, in my understanding, the current codebase is not overwhelmingly big yet
+2018-04-21 15:35:54	@Whissi	Keep in mind, arch's tool is doing things differently. See there "AVG-..." group.
+2018-04-21 15:35:54	@K_F	its relatively easy to grasp
+2018-04-21 15:35:56	@b-man	Plus, we have some underlying performance issus as well.  I know Thomas has tried to fix some
+2018-04-21 15:36:19	@Whissi	s/there/their/
+2018-04-21 15:36:48	@ChrisADR	yes, and since it's easy to grasp now, it's a good time to consider new implementations, with a more complex tool, considerations wouldn't be an option
+2018-04-21 15:37:57	@ChrisADR	that grouping system is most likely what I was pretending to do with the custom field from bugzilla
+2018-04-21 15:38:23	@ChrisADR	but that's next topic
+2018-04-21 15:38:35	@b-man	Motion: Coordinate with Gentoo infra to deploy a testing environment for the Arch Security Tool.
+2018-04-21 15:39:08	@K_F	given that the delay in most cases is waiting for stabilization etc, I don't see a major need for rework of the current glsamaker
+2018-04-21 15:39:13	@Whissi	But to be clear: I don't have time for a new GLSAmaker yet. Maybe at the end of this year, but not in the next 3-4 months.
+2018-04-21 15:39:24	@b-man	Haha ok.
+2018-04-21 15:39:27	@b-man	disregard
+2018-04-21 15:39:29	@K_F	in the process of making a GLSA we often find things that needs to be adjusteed
+2018-04-21 15:40:25	@ChrisADR	to be fair, the GLSA generation process does indeed work with glsamaker right now
+2018-04-21 15:40:43	@ChrisADR	I'm more concerned about our capability of tracking all the issues 
+2018-04-21 15:41:33	@Whissi	Creating GLSA isn't the problem right now, right.
+2018-04-21 15:42:04	@ChrisADR	and as we saw last week, first time we created a ncurses GLSA,
+2018-04-21 15:42:25	@ChrisADR	and that's probably because we can't track all the issues right now, 
+2018-04-21 15:42:55	@b-man	Whissi: How is data fed to the Arch Security tool?  Is it parsing CVE's automatically?
+2018-04-21 15:43:00	@ChrisADR	and I guess that's where we need automation
+2018-04-21 15:43:17	@ChrisADR	more than GLSA generation
+2018-04-21 15:43:37	@b-man	ChrisADR: point taken, but I would also say that it is *possible* we bumped and stabilized ncurses before a CVE was released.
+2018-04-21 15:43:53	@b-man	Which happens quite often in Gentoo
+2018-04-21 15:44:29	@b-man	So, what are we wanting to do here?
+2018-04-21 15:44:30	@Whissi	Well, from my p.o.v. the problem is a different one. If you have _one_ vuln in _one_ pkg everything is easy. Especially when we can create bug from CVEtool because CVE was already published.
+2018-04-21 15:45:08	@Whissi	But once there are multiple vulns and/or a vuln affecting multiple packages, things become hard to manage.
+2018-04-21 15:45:40	@Whissi	And this is was arch's implementation is addressing because they added a CVE tracker on top, decoupled from bugs.
+2018-04-21 15:46:09	@K_F	right, but that is a difficulty that is natural, and we'd still likely want to release the GLSAs as they are fixed
+2018-04-21 15:46:34	@K_F	the typical example is embedded small libraries
+2018-04-21 15:46:35	@Whissi	...and this is something I would want change when we build something new :p
+2018-04-21 15:46:51	@K_F	which we should try to avoid to begin with
+2018-04-21 15:47:10	@K_F	embedding is only negative
+2018-04-21 15:47:22	@Whissi	But this is going off topic right now.
+2018-04-21 15:47:48	@ChrisADR	ok, I think we all agree that GLSAs are not the problem
+2018-04-21 15:47:54	@ChrisADR	right now at least
+2018-04-21 15:48:28	@Whissi	Yeah, creating the GLSA is the easiest thing in our process.
+2018-04-21 15:48:32	@ChrisADR	but we need to take in consideration arch's perspective and other options for tracking issues or CVEs that may help us to have better response times
+2018-04-21 15:49:30	@K_F	we still need to track that in bugzilla to include workflow of other devs, and fixes in revbumps vs full versions
+2018-04-21 15:49:52	@ChrisADR	yes, we need that too
+2018-04-21 15:50:17	@ChrisADR	which takes us back to the point, is someone willing to write a document describing the situation and requirements? :P
+2018-04-21 15:50:34	@Whissi	Let's move on. I think I am the only one who have seen Arch backend... questions like the one from K_F are good but if you would know the backend you wouldn't ask that. Let's move one to the next topic for now :)
+2018-04-21 15:50:36	@ChrisADR	I can draft it if you want
+2018-04-21 15:50:56	@b-man	Whissi: If you have seen it then I stand by my motion
+2018-04-21 15:51:04	@b-man	Why not give it a go :shrug:
+2018-04-21 15:51:13	@b-man	I trust your judgement enough
+2018-04-21 15:51:38	@b-man	If it does not prove worthwhile then we can move on.
+2018-04-21 15:52:10	@K_F	yes, I haven't seen the arch backend before
+2018-04-21 15:52:36	@ChrisADR	b-man: could you help with infra request for deploying a testing env?
+2018-04-21 15:52:42	@b-man	sure
+2018-04-21 15:53:03	@ChrisADR	but without any major change, just to see how it works by default
+2018-04-21 15:53:17	@ChrisADR	and use that info to see if it's worth it
+2018-04-21 15:53:18	@Whissi	We cannot just test it and keep our workflow. We would either have to test it side-by-side keeping our old workflow which would limit the experience or we would have to stop current workflow for some time.
+2018-04-21 15:53:51	@ChrisADR	couldn't we connect it to development bugzilla env?
+2018-04-21 15:54:03	Irishluck83	I would think doing it side by side just in case this doesn't work out
+2018-04-21 15:54:13	@b-man	Whissi: I defer to you then to determine what is the best way forward.
+2018-04-21 15:54:38	@ChrisADR	I think we can have it running and see how it works, but without changing our current workflow
+2018-04-21 15:54:38	@K_F	Whissi: right, which goes back to writing up a RFP on what we want for changing, if the arch variant satiesfies that , even better
+2018-04-21 15:54:40	@Whissi	Also keep in mind that Arch doesn't care about unstable/stable. They don't have such a thing. From security perspective I'd like to have the same. I.e. when we know there's a vuln it doesn't matter if the package is stable. We need a solution. For ~arch and arch..
+2018-04-21 15:54:49	@K_F	but we should have a positive gain from any switch
+2018-04-21 15:55:24	@K_F	~arch isn't security supported, so we should have that distinction
+2018-04-21 15:55:58	@b-man	Whissi: Are you suggesting that the increased ability to process things will allow us to drop that distinction?
+2018-04-21 15:56:06	@Whissi	Yeah, but like said I would change our workflow if we move to something new in many ways. :)
+2018-04-21 15:56:15	@Whissi	b-man: Exactly!
+2018-04-21 15:56:32	@ChrisADR	it would be the best for us, indeed
+2018-04-21 15:56:42	@ChrisADR	then we could support gentoo as a whole
+2018-04-21 15:56:50	@b-man	K_F: Is there some historical reasoning as to why we differentiated between ~ and stable?
+2018-04-21 15:57:12	@b-man	(from a security perspective)
+2018-04-21 15:57:50	@K_F	b-man: as we don't restrict what developers put into no-kw or ~arch, but require a higher degree of conciousness of what goes into stable
+2018-04-21 15:58:03	@K_F	but mostly it is a matter of what we can track as a project
+2018-04-21 15:58:13	@K_F	that goes into auditing as well on some level
+2018-04-21 15:58:42	@b-man	I don't forsee an issue with devs putting things in ~arch
+2018-04-21 15:58:48	@Pinkbyte	b-man, stable versions require more work(stabilization) than ~keyword ones
+2018-04-21 15:58:52	@Pinkbyte	just that
+2018-04-21 15:58:54	@b-man	If it is open source it is open to the same scrutiny any other package is
+2018-04-21 15:58:55	@Whissi	If we tell people running ~arch they are using a vulnerable package some of them will start asking us "Ugh? And why don't you fix it?!"... so we would get a lot more user requests... but I think we can handle that and in the end I hope we will gain something. Maybe new devs who will help bumping because their PM keep nagging them "You are vulnerable" :p
+2018-04-21 15:59:20	@K_F	Whissi: ultimately we support stable version of Gentoo
+2018-04-21 15:59:37	@Whissi	Yup.
+2018-04-21 15:59:45	@ChrisADR	yes, but I guess that if we were able to support every package, we could say that we support all gentoo?
+2018-04-21 15:59:47	@b-man	Whissi: I would take the opposite stance.  ~arch can generally be looked at as more secure
+2018-04-21 16:00:26	@b-man	the delay from ~ to stable is the problem we have right now...
+2018-04-21 16:00:32	@K_F	b-man: only if upstream fixes things timely
+2018-04-21 16:00:44	@b-man	K_F: Agreed, but compound that with our stabilization delays...
+2018-04-21 16:01:08	@ChrisADR	well, let's land the ideas, do you agree if I work on a RFP to see what we need in matters of tracking and coordinating with other devs, and begin with that?
+2018-04-21 16:01:11	@K_F	b-man: a DoS due to failure of a fix on info leakage might have more severe consequences
+2018-04-21 16:01:27	<--	sokan (~Henry@unaffiliated/totaloblivion) ha salido (Remote host closed the connection)
+2018-04-21 16:01:46	@ChrisADR	because it seems that GLSA by itself is not an issue with our current procedures
+2018-04-21 16:01:51	@Whissi	ChrisADR: Everyone can always do that. Than we can talk about it in detail instead of wasting time like now ;-) So please do that, if you have that time.
+2018-04-21 16:02:13	@b-man	+1 from Whissis comment
+2018-04-21 16:02:16	@ChrisADR	ok, I'll prepare that and leave it in security@g.o
+2018-04-21 16:02:26	@ChrisADR	that brings us to the last topic
+2018-04-21 16:02:52	@b-man	K_F: I agree a DoS is an issue, but if that DoS is known and fixed then it naturally lands in ~.  We stabilize following that thus leaving our stable users vulnerable until then.
+2018-04-21 16:03:25	@ChrisADR	long story short, I've seen myself and every other padawan in the situation of discovering how to track bugs in bugzilla, search and all of that... we may need some more visibility from bugzilla and our "saved searches"
+2018-04-21 16:03:52	@Whissi	b-man: K_F is talking about a DoS due to program error in a new version undetected because it wasn't tested before, not about a DoS vuln I think. That's my understanding.
+2018-04-21 16:04:01	@b-man	Ah, Ok.
+2018-04-21 16:04:23	@b-man	I don't believe AT's are setup to detect a DoS :-P
+2018-04-21 16:04:26	@ChrisADR	that's why I wanted to propose a new field in bugzilla, for vulnerabilities component, that way we could generate a single report containing all the active bugs, sorted by whiteboard and package-affected(only one)
+2018-04-21 16:05:18	@K_F	Whissi: yes
+2018-04-21 16:05:31	@Whissi	ChrisADR: Can you show us a an example in detail? A bug, the problem, your new field with the values you are thinking of... how this should help us...
+2018-04-21 16:06:17	@ChrisADR	I sent you an email about bugzilla metrics, on that I listed some reports, one example was with wireshark
+2018-04-21 16:06:34	@K_F	my immediate take is we can re-use package list for stabilization
+2018-04-21 16:06:55	@ChrisADR	if we generate a report based in the "summary" field, we'll have 4 different lines for each wireshark-2.x, wireshark-2,3.x
+2018-04-21 16:07:24	@K_F	but I'm personally less interested in the statistics than the actual fixes
+2018-04-21 16:07:25	@ChrisADR	same goes for package-list, wihch would have one line for packege-v1, samepackage-v1-r1, and so on
+2018-04-21 16:07:51	@Whissi	To be honest I don't understand the problem you want to solve with metrics.
+2018-04-21 16:08:31	@ChrisADR	it's a matter of visibility, with one report, I saw that we had over 22 opened bugs that were not just from a couple of weeks ago, but months
+2018-04-21 16:08:45	@ChrisADR	without been seen
+2018-04-21 16:08:56	@b-man	ChrisADR: The same package?
+2018-04-21 16:08:59	@Whissi	This is my security todo query: https://bugs.gentoo.org/buglist.cgi?component=Vulnerabilities&email1=security%40gentoo.org&email2=alpha|amd|arm|hppa|ppc|x86&emailassigned_to1=1&emailcc2=1&emailtype1=equals&emailtype2=notregexp&list_id=3912024&query_format=advanced&resolution=--- -- Works fine :-)
+2018-04-21 16:09:02	@ChrisADR	different packages
+2018-04-21 16:09:36	@ChrisADR	resulst were limited to 500 with that approach 
+2018-04-21 16:09:54	@b-man	ChrisADR: I don't doubt you found something that works for you, but I am not understanding it either.
+2018-04-21 16:09:56	@Whissi	When you view it via b.g.o... query via API and you get all details.
+2018-04-21 16:10:19	@b-man	ChrisADR: I think if you expound on the problem and the solution we will get it.
+2018-04-21 16:10:32	@Whissi	Like I am using Deskzilla (Gentoo has a free site license)
+2018-04-21 16:10:54	@ChrisADR	yes, maybe that's just it, I need to better prepare the idea 
+2018-04-21 16:11:30	@ChrisADR	but that's something I think we should have written down somewhere, all of us here have their own method of "tracking" bugs
+2018-04-21 16:12:06	@ChrisADR	which causes a duplication of effort discovering the wheel and maybe it's not helping us as a whole to keep good track of every open bug
+2018-04-21 16:12:07	@b-man	I think that is due to individuality honestly
+2018-04-21 16:12:52	@ChrisADR	yea, it's about taste I think :) but it would be good to share that somewhere, so that all of us have all the possibilities and see which one fits us better :)
+2018-04-21 16:12:56	@K_F	well, some duplication of effort there is useful for BUS-factor reasons, but sounds like it can be solved by more comments in the bugs
+2018-04-21 16:13:55	@K_F	and coordination here in the channel
+2018-04-21 16:14:02	@ChrisADR	yea, I'll work on a better example for the next time :)
+2018-04-21 16:14:39	@ChrisADR	ok, any other item before welcoming our scouts / padawans?
+2018-04-21 16:14:55	@K_F	not anything from me
+2018-04-21 16:14:59	@b-man	Whissi broke my kernel again
+2018-04-21 16:15:08	@b-man	:-P
+2018-04-21 16:15:12	@ChrisADR	haha
+2018-04-21 16:15:20	@b-man	(inside joke... just messing around) :)
+2018-04-21 16:15:28	@ChrisADR	ok how many padawans are still here?
+2018-04-21 16:15:43	Irishluck83	i am but i need to leave soon
+2018-04-21 16:15:57	@ChrisADR	anyone else?
+2018-04-21 16:16:08	@ChrisADR	ok then :)
+2018-04-21 16:16:36	@ChrisADR	well we just wanted to welcome you Irishluck83, to the meeting and to the security project
+2018-04-21 16:16:48	 *	b-man has a saved round
+2018-04-21 16:16:52	@b-man	2 GLSA's need approving :)
+2018-04-21 16:16:52	@ChrisADR	I know that you have been talking with b-man regularly
+2018-04-21 16:17:01	Irishluck83	thanks. i have
+2018-04-21 16:17:25	Irishluck83	i think we closed out like 3 bugs in the last 3 days
+2018-04-21 16:17:29	@b-man	bang gavel?
+2018-04-21 16:17:30	Irishluck83	so trying to get there
+2018-04-21 16:17:44	@ChrisADR	I also wanted to comment you that we all would like to see you actively around
+2018-04-21 16:18:14	Irishluck83	will do
+2018-04-21 16:18:16	@ChrisADR	not just IRC, bugzilla and any other way you can imagine or contribute with
+2018-04-21 16:18:17	@b-man	He has limited time due to real world stuff, but he is active for a couple hours each night when we work together.
+2018-04-21 16:18:43	@ChrisADR	yea :) that's good, and good to all of us to know too
+2018-04-21 16:19:18	Irishluck83	i would like to help more but tim and all
+2018-04-21 16:19:24	@ChrisADR	Irishluck83: so keep working hard and try to learn something new everyday, we need much more work to get done, and i'd be good to have your help with that 
+2018-04-21 16:19:43	@ChrisADR	s/i'd/it'd/
+2018-04-21 16:19:45	Irishluck83	i am willing to help you guys
+2018-04-21 16:19:53	@ChrisADR	well, welcome again :)
+2018-04-21 16:19:55	Irishluck83	thanks again. i need to go and celebrate my wife bday
+2018-04-21 16:19:57	Irishluck83	thanks
+2018-04-21 16:20:14	@b-man	someone bang the gavel!
+2018-04-21 16:20:16	@ChrisADR	that's it I think, I'll update the wiki page to reflect our current padawans
+2018-04-21 16:20:21	@b-man	K_F: Councilman!
+2018-04-21 16:20:44	@K_F	I don't have anything else to add, so fine with banging gavel
+2018-04-21 16:20:52	 *	ChrisADR waiting for gavel
+2018-04-21 16:21:02	@K_F	but I'll leave the pleasure for ChrisADR
+2018-04-21 16:21:29	@ChrisADR	well thank you all, sorry for making this such a long meeting, we'll try to keep it shorter
+2018-04-21 16:21:35	@K_F	since he's chairing this meeting
+2018-04-21 16:21:37	 *	ChrisADR bangs gavel
+2018-04-21 16:22:03	@b-man	ChrisADR: I don't mind the length, but more targeted agenda items.
+2018-04-21 16:22:19	@K_F	the timing of this isn't bad
+2018-04-21 16:22:45	@K_F	but indeed, we can likely try to discuss more ahead of meeting and more specific meeting items going forwards
+2018-04-21 16:22:45	@ChrisADR	I expected it to be <60 mins :) but agree, better targeting next time 
+2018-04-21 16:22:48	@b-man	Things we can considerable actionable.  We do have some items to consider from this though.
+2018-04-21 16:22:59	@b-man	s/considerable/consider
+2018-04-21 16:23:22	@K_F	I generally like that we have more frequent meetings though
+2018-04-21 16:23:28	@b-man	+1
+2018-04-21 16:23:31	@ChrisADR	+1
+2
diff --git a/meetings/logs/sec-meeting-2018-06-03-log b/meetings/logs/sec-meeting-2018-06-03-log
new file mode 100644
index 0000000..cdd32a5
--- /dev/null
+++ b/meetings/logs/sec-meeting-2018-06-03-log
@@ -0,0 +1,346 @@
+2018-06-03 14:00:28	@ChrisADR	!proj security
+2018-06-03 14:00:29	willikins	ChrisADR: (security@gentoo.org) a3li, ackle, blueknight, bman, chrisadr, creffett, k_f, pinkbyte, whissi, zlogene, zx2c4
+2018-06-03 14:00:33	@ChrisADR	meeting time?
+2018-06-03 14:01:08	Irishluck83	there was a meeting
+2018-06-03 14:01:12	 *	K_F here
+2018-06-03 14:01:18	 *	ChrisADR here
+2018-06-03 14:01:35	@Whissi	uhm
+2018-06-03 14:01:37	@Whissi	Was it today?
+2018-06-03 14:01:47	@K_F	yup
+2018-06-03 14:01:57	@K_F	s/was/is/
+2018-06-03 14:02:15	@ChrisADR	Irishluck83: yes, sorry I haven't sent you and sokan a proper invitation, very busy this week, if you have time now, you are more than welcomed :)
+2018-06-03 14:02:33	Irishluck83	well i'm here so i can do the meeting
+2018-06-03 14:02:38	@ChrisADR	cool
+2018-06-03 14:03:59	@ChrisADR	domhnall: you too
+2018-06-03 14:04:34	@Whissi	But I am here.
+2018-06-03 14:05:20	@ChrisADR	ok, let's begin, b-man will catch up later I guess
+2018-06-03 14:05:53	@ChrisADR	first point in list was GLEP 14, deferred for next meeting 
+2018-06-03 14:05:56	@K_F	sounds good .. I believe first agenda item is GLEP14, I'm hoping to get started on that this week as I have plenty of time up in the air
+2018-06-03 14:06:10	@ChrisADR	cool, sounds good
+2018-06-03 14:06:34	@ChrisADR	next topic, GLSAMaker use cases
+2018-06-03 14:06:58	@ChrisADR	those with access to the repo may have noticed that I added a document in the documentation folder
+2018-06-03 14:07:23	@ChrisADR	it is still a WIP, but I'd like to point a new change that is currently in (RFC) stage
+2018-06-03 14:08:10	@ChrisADR	I'd like to change GLSAMaker so that padawans have access to CVETool, but only to be able to list CVEs in NEW state and to report them with the current interface
+2018-06-03 14:08:44	@ChrisADR	thoughts?
+2018-06-03 14:09:54	@Whissi	Mh.
+2018-06-03 14:10:14	Irishluck83	would that allow us to make the cve and put it in the whiteboard?
+2018-06-03 14:10:28	@K_F	might not be a bad idea, but haven't through it through fully.
+2018-06-03 14:10:42	@ChrisADR	that would allow padawans to see which CVEs are out there that we are not currently tracking
+2018-06-03 14:10:56	@ChrisADR	and if the apply to gentoo, to report them
+2018-06-03 14:11:19	@Whissi	Only for Padawans who passed first step and are also expected to write GLSA. I am against access for early Padawans to CVEtool just for reporting.
+2018-06-03 14:11:26	Irishluck83	that would be helpful.
+2018-06-03 14:12:00	@ChrisADR	Whissi: right, we need to have a pre-filter, but the idea is once they have a good understanding about what we do, let them use our tools to automate the process
+2018-06-03 14:12:04	Irishluck83	that sounds ok with me. I'm at that stage now anyway. It would help me more with bugs and helping the team
+2018-06-03 14:12:34	@ChrisADR	yes, mainly because scouting takes a lot of time, and produces not so much benefit for the  team right now
+2018-06-03 14:12:55	@Whissi	When they have access to normal GLSAmaker, they can have access to CVEtool web interface, too
+2018-06-03 14:13:12	@ChrisADR	when I was a padawan CVETool was blocked, until full access
+2018-06-03 14:13:31	@ChrisADR	was granted to me
+2018-06-03 14:14:08	@ChrisADR	so the change would be to allow "padawan" users to see and use CVETool interface
+2018-06-03 14:14:48	@ChrisADR	but only the reporting or assign  button, not NFU or Later yet
+2018-06-03 14:14:51	Irishluck83	so apprentices and up
+2018-06-03 14:15:29	@Whissi	But only for Padawans with GLSAmaker access. Not for new people from day one.
+2018-06-03 14:15:41	@ChrisADR	Whissi: of course
+2018-06-03 14:15:55	@K_F	I'm actually unsure if adding too much granularity makes sense in that case, e.g marking things NFU to clean things out likely makes sense in the same process
+2018-06-03 14:16:11	@K_F	but indeed, only after training..
+2018-06-03 14:16:36	@ChrisADR	K_F: granularity may not required, but at least a notification for other team members
+2018-06-03 14:16:51	@ChrisADR	so we can see if something is 'accidentally' marked as NFU
+2018-06-03 14:18:06	@b-man	Even if it is the CLI CVETool can assign it
+2018-06-03 14:18:37	@ChrisADR	I couldn't when I was padawan, but we'd have to take a look at the code and see that too
+2018-06-03 14:19:11	domhnall	ChrisADR: I'm here, continue while I read log for any missed content
+2018-06-03 14:19:27	@ChrisADR	so, do you consider it a idea worth of developing further?
+2018-06-03 14:19:44	@ChrisADR	with all the constraints listed above
+2018-06-03 14:20:53	domhnall	from what ChrisADR and Whissi are discussing, I'm in agreement.
+2018-06-03 14:22:29	@K_F	ChrisADR: likely mostly a matter of changing the access level granting cvetool access.. the monitoring can already be done using email filters
+2018-06-03 14:22:57	@ChrisADR	indeed, little change in implementation, but may be useful 
+2018-06-03 14:22:58	@K_F	maybe learn from bugzilla and add some headers on the changes, e.g who makes them etc
+2018-06-03 14:23:06	@Whissi	Monitoring will be the problem. There's no notification or something when you set NFU
+2018-06-03 14:23:31	@K_F	right, but that can likely be added to email queue as well
+2018-06-03 14:23:38	@ChrisADR	it would be easier to just remove the button from the interface for 'padawan' memebers
+2018-06-03 14:23:41	@K_F	with appropriate headers, and possibly a way to shut it off..
+2018-06-03 14:24:10	@K_F	meh, shouldn't hide things from UI if they have access under the hood, that should be consistent otherwise we'll just be confused
+2018-06-03 14:24:15	@Whissi	Yeah, hiding in UI would be fastest thing.
+2018-06-03 14:24:44	@Whissi	To implement something like that you would need 6+ hours...
+2018-06-03 14:24:50	@Whissi	And then you already know Ruby ;)
+2018-06-03 14:24:56	@Whissi	For us, it will take more time ;)
+2018-06-03 14:24:59	@ChrisADR	hahaha right
+2018-06-03 14:25:13	@ChrisADR	but I think it's worth the shot to try to find a implementation for this scenario
+2018-06-03 14:25:35	@ChrisADR	at least to have an extra couple of trusted eyes taking a look at the list
+2018-06-03 14:26:08	@Whissi	You suggestion to just hide the button for the beginning sounds practicable, yes.
+2018-06-03 14:26:11	@Whissi	+r
+2018-06-03 14:26:38	@Whissi	What I would like to investigate is how CLI access is restricted...
+2018-06-03 14:27:02	@ChrisADR	yes, I haven't take a look at that neither
+2018-06-03 14:27:34	@ChrisADR	shall we vote to move this from a RFC to a TODO stage?
+2018-06-03 14:27:57	@ChrisADR	with implementation details pending
+2018-06-03 14:28:07	@Whissi	Is RFC > Todo or < Todo? L)
+2018-06-03 14:28:38	@ChrisADR	mmm it'd be Request for Comment right now... so, < than TODO i guess
+2018-06-03 14:28:54	@ChrisADR	TODO should we something that we agree that we need, but we haven't implemented yet
+2018-06-03 14:29:20	@Whissi	OK.
+2018-06-03 14:30:55	domhnall	so, can we list the pending details before voting to avoid ambugiuty?
+2018-06-03 14:31:11	domhnall	blah, ambiguity
+2018-06-03 14:31:22	@Whissi	Would say we have to do a write up, i.e. update rfc, and then we can vote on that next time.
+2018-06-03 14:31:46	@ChrisADR	agree, sounds better and we then avoid ambiguity as domhnall says
+2018-06-03 14:32:08	@ChrisADR	ok, I'll work on that part of the document adding some constraints and we'll see for the next meeting, agree?
+2018-06-03 14:32:18	@Whissi	yup
+2018-06-03 14:32:43	@ChrisADR	K_F b-man extra comments? shall we move on?
+2018-06-03 14:33:00	@K_F	not on this topic, still got a few comments on glsamaker though :)
+2018-06-03 14:33:00	@Whissi	Maybe ping me/us before meeting so we can read before meeting in case we need to adjust something so that we have a final document when we meet so we can vote.
+2018-06-03 14:33:27	@ChrisADR	good, I'll keep that in mind for the next meeting then :)
+2018-06-03 14:33:50	 *	b-man forgot today was a meeting
+2018-06-03 14:34:03	@ChrisADR	ok, last topic then :P
+2018-06-03 14:34:26	@K_F	for one thing, seems we need some infra access to update password / add new users, I haven't looked into it specifically but the htpasswd isn't stored in the glsamaker admin interface but directly on server, so we need to find a way to set access on that without infra access
+2018-06-03 14:34:55	@ChrisADR	mmm good point
+2018-06-03 14:35:08	domhnall	K_F: I agree, previous access should be revoked if not a padawan.
+2018-06-03 14:35:24	@Whissi	Why without infra access?
+2018-06-03 14:35:42	@Whissi	It's not like we have to update that very often. I.e. can't we ping infra like now?
+2018-06-03 14:35:48	@K_F	Whissi: security leads should have the possibility to do it without being member of infra
+2018-06-03 14:36:06	@K_F	Whissi: it is likely as easy as setting up a git repository though..
+2018-06-03 14:36:09	@ChrisADR	since blueknight was infra too, he was able to do that
+2018-06-03 14:36:29	@K_F	with some sync mechanism
+2018-06-03 14:36:46	@Whissi	I don't think we need such a complexity.
+2018-06-03 14:36:56	@Whissi	But... if you like to have it, go on ;)
+2018-06-03 14:37:17	@ChrisADR	ok, we'll see that later then, now last topic
+2018-06-03 14:37:32	@ChrisADR	Policy definition of "supported"
+2018-06-03 14:38:07	@ChrisADR	since we have already dropped HPPA from the supported list, it may be a good time to redefine if "stable"=="supported"
+2018-06-03 14:38:25	 *	b-man grabs popcorn
+2018-06-03 14:39:59	@K_F	since we wouldn't necessarily be consulted before something is marked stable, I don't like it as we don't necessarily have control of the situation.. also other way around, we'd lose possibility of dropping security support from lagging arches
+2018-06-03 14:40:26	domhnall	I agree K_F on this one
+2018-06-03 14:41:21	@ChrisADR	yes, we wouldn't be consulted, but maybe it'd be a good policy for AT teams to know that if they want an arch to be considered as "stable" they need to be sure that they'll respond in the proper times to sec issues
+2018-06-03 14:41:48	@K_F	we wouldn't know that..
+2018-06-03 14:41:57	@K_F	and formally it is not a part of consideration for moving something to stable
+2018-06-03 14:42:43	@b-man	The proposals in the past were simply that stable profiles are security supported by default.
+2018-06-03 14:42:48	@ChrisADR	should we push to make it formally part of the considerations?
+2018-06-03 14:42:56	@b-man	within that stable profile only stable packages are truly supported
+2018-06-03 14:43:35	@K_F	ChrisADR: as I've said before, that would likely coincide with a GLEP:48 like for Security
+2018-06-03 14:44:11	@b-man	So, I think the first step and a reasonable proposal would be for security to drop the "security supported" terminology from s.g.o and docs.
+2018-06-03 14:44:44	@b-man	then we can work the other potential fixes such as a GLEP or what not to ensure profiles do not get marked stable without proper support.
+2018-06-03 14:45:05	@K_F	or we can keep security supported as it is and have the control to do as we want :)
+2018-06-03 14:45:19	@b-man	It is not really any control.
+2018-06-03 14:45:35	@K_F	it is
+2018-06-03 14:45:40	@Whissi	I agree with b-man. We don't have control.
+2018-06-03 14:45:49	@b-man	I can release a GLSA early?
+2018-06-03 14:45:52	@K_F	we control what is covered by the security project
+2018-06-03 14:46:01	@b-man	Which should be everything IMHO
+2018-06-03 14:46:13	@Whissi	b-man: Well, this has changed already. You can release after first arch has stabilized.
+2018-06-03 14:46:13	@b-man	::gentoo
+2018-06-03 14:46:43	@b-man	Whissi: It was rhetorical in response to the we have control idea.
+2018-06-03 14:46:46	@K_F	wouldn't be everything in any case, we definitely need to stick to stable
+2018-06-03 14:46:50	@ChrisADR	yes, it should be everything... even ~ arches.. but sadly we don't have the manpower to do that neither
+2018-06-03 14:46:51	domhnall	order?
+2018-06-03 14:46:52	@b-man	Yes, stable only.
+2018-06-03 14:47:18	@b-man	but, we really do cover a lot of ~ already anyway
+2018-06-03 14:47:33	@Whissi	Sorry, I have a lot to say about stable & security supported... but I don't have the time for this today :(
+2018-06-03 14:48:00	@K_F	yeah, I don't really see any new arguments comming up in today's discussion :)
+2018-06-03 14:48:05	@b-man	Whissi: Out buying peanuts and orange juice? :-P
+2018-06-03 14:48:08	@K_F	but indeed, it is a broader scale discussion
+2018-06-03 14:48:17	@b-man	K_F: We should just put it to vote
+2018-06-03 14:48:27	@Whissi	b-man: :p
+2018-06-03 14:48:36	@K_F	b-man: depending on what we're voting on, it isn't our vote to begin with
+2018-06-03 14:48:37	@ChrisADR	I was thinking in a end user point of view... like a question in the AMA... a user should be certain that if he uses "stable" it is also security supported
+2018-06-03 14:48:47	@K_F	in particular if security acceptance is required for stable, it is a council matter
+2018-06-03 14:49:05	@Whissi	K_F: You are the only one who wants to keep status quo. So please come up with arguments why.
+2018-06-03 14:49:17	@ChrisADR	yes, indeed, but we need to see if the team, as a whole, wants to go to council presenting the idea
+2018-06-03 14:49:20	@Whissi	All the other wants to change stable includes security coverage.
+2018-06-03 14:49:34	@Whissi	You cannot have a stable arch if you cannot keep up with security stabilization
+2018-06-03 14:49:51	@K_F	there are two ways for that to happen, one is security doesn't have a say and just covers everything marked stable
+2018-06-03 14:50:05	@K_F	the other is if security want a role in the process a priori, that will require a glep:48 style for security
+2018-06-03 14:50:15	@Whissi	(and I would say it like Linus: It isn't about security... i.e. if you would only follow security stabilization but ignore all other stable requests for your architecture, your architecture shouldn't be stable at all... but... )
+2018-06-03 14:51:06	@ChrisADR	ok, we then should prepare a GLPE:48 like document stating what should be considered to have a "stable" arch with security coverage and present that to council
+2018-06-03 14:51:19	@b-man	Step 1: we drop the separation of "security supported arches" and ensure it is understood that we support all stable profiles.
+2018-06-03 14:51:25	@K_F	ChrisADR: you'll find some early templates of that around already
+2018-06-03 14:51:26	@b-man	Step 2+: we go to council with a GLEP or whatever
+2018-06-03 14:51:46	Irishluck83	need to go but i'll catch up later.
+2018-06-03 14:52:20	@K_F	https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security
+2018-06-03 14:52:30	@ChrisADR	ok, so far we all agree that this is a must have topic, maybe too long for just one meeting, right?
+2018-06-03 14:53:02	@b-man	ChrisADR: As Whissi mentioned, most are in agreement already.
+2018-06-03 14:53:40	@b-man	We go round and round about GLEP's and council stuff most of the time.
+2018-06-03 14:54:16	@b-man	Let's take some first steps within security... like vote on what we agree is the right way, then we can go do all the GLEPs and council stuff we want.
+2018-06-03 14:54:32	@b-man	but if we cannot agree and do anything internal than there is no point in pursuing GLEPs.
+2018-06-03 14:54:47	@Whissi	I think this is not special about security project. I have to look up GLEP for stable arches in general. If we haven't yet a document for Gentoo, we have to create one:
+2018-06-03 14:54:53	@K_F	what I'd like to see is a more complete proposal of how it'd look
+2018-06-03 14:55:00	@Whissi	Any arch which should be marked stable has to follow rules.
+2018-06-03 14:55:09	@Whissi	Like doing stabilization in time ;)
+2018-06-03 14:55:17	@K_F	you don't have that atm
+2018-06-03 14:55:18	@Whissi	If you cannot keep up, you will loose stable flag.
+2018-06-03 14:55:20	@K_F	so indeed
+2018-06-03 14:55:24	@ChrisADR	ok, what do you think about this
+2018-06-03 14:55:32	domhnall	no
+2018-06-03 14:56:04	@K_F	that is part of why I'd like to see a complete proposal, there are inconsistencies in what I've seen so far, except gentoo security being a taker of what to support from exogenuous sources
+2018-06-03 14:56:17	@K_F	you don't really need even a council decision to mark an arch stable today
+2018-06-03 14:56:25	@ChrisADR	I(or someone)'ll prepare an email stating what whissi said, that security project is concernd about the current status of "stable" arches, that they need to be able to keep security in the arch or they shouldn't be called "stable"
+2018-06-03 14:56:52	@Whissi	But prepare that for us, so we can work on this draft
+2018-06-03 14:56:55	@Whissi	before it goes public ;)
+2018-06-03 14:56:57	@b-man	ChrisADR: That is great, but we as a project cannot unanimously agree.
+2018-06-03 14:57:08	@ChrisADR	see how arch teams react, and in base of that feedback, prepare a GLEP and see the details about that?
+2018-06-03 14:57:22	@K_F	wrong way around if you ask me
+2018-06-03 14:58:07	@b-man	This is the what, 5th time this dicussion has come up?
+2018-06-03 14:58:46	@K_F	something like that :)
+2018-06-03 14:58:58	@ChrisADR	maybe because this has ambiguous scope between AT, security, and other teams?
+2018-06-03 14:59:05	@K_F	and I think we can even agree on the goal, but it requires proper preparation
+2018-06-03 14:59:06	@b-man	ChrisADR: Not really
+2018-06-03 14:59:16	@b-man	K_F: No, we haven't agreed on the goal.
+2018-06-03 14:59:30	@b-man	I am pretty sure it is as simple as... does a stable profile == security supported?
+2018-06-03 14:59:41	@b-man	K_F says no.  Everyone else says yes.
+2018-06-03 14:59:50	@K_F	b-man: rights, it is as simple as that as long as security is a taker of stable
+2018-06-03 15:00:05	<--	fekepp (~Thunderbi@87.140.192.248) ha salido (Ping timeout: 240 seconds)
+2018-06-03 15:00:06	@K_F	we don't have any impact of what is marked stable, or if slacking arches
+2018-06-03 15:00:06	@ChrisADR	yes b-man but is not as simple because right now we don't have power to decide if something is stable or not
+2018-06-03 15:00:25	@ChrisADR	and that's in AT scope, a bit...
+2018-06-03 15:00:26	@b-man	No, we don't nor do we have any power now
+2018-06-03 15:00:38	@K_F	now we say its not security supported, case closed
+2018-06-03 15:00:50	@b-man	This isn't making any sense
+2018-06-03 15:00:53	@b-man	It is a straw man
+2018-06-03 15:01:17	@b-man	and I can't believe I am even using the "straw man" crap
+2018-06-03 15:01:38	@b-man	We currently support all packages which have a stable marking
+2018-06-03 15:02:12	@K_F	not necessarily
+2018-06-03 15:02:22	@b-man	K_F: Please, tell me when we haven't...
+2018-06-03 15:02:28	domhnall	b-man: so that wont change after this meeting...agreed?
+2018-06-03 15:02:51	@K_F	one example would be a package that controls hardware/monitors hardware on ArchX and is only marked stable on that
+2018-06-03 15:03:16	@b-man	Yea, sure of course.
+2018-06-03 15:03:18	@K_F	I'd tend to agree that for more general purpose applications, as long as amd64 is added we're covering it anyways, but that isn't necessarily ultimately true for all packages
+2018-06-03 15:03:42	@b-man	Just because it isn't mathematically/empirically true doesn't make it wrong.
+2018-06-03 15:04:10	@K_F	it makes the statement wrong logically
+2018-06-03 15:04:14	@b-man	We are doing the usual Gentoo bullshit and coming up with "Big Bang Theory" like cases in order to avoid making a decision.
+2018-06-03 15:05:07	@K_F	but i propose someone write up a more detailed proposal and we can discuss that by email
+2018-06-03 15:05:32	@b-man	I think we all understand what the proposal is.
+2018-06-03 15:05:55	@K_F	I do believe that to do this correctly we indeed need more formal description of requirement to mark stable, and for security project to be an imput on that a GLEP:48-style proposal
+2018-06-03 15:06:20	@b-man	K_F: Sure, I don't disagree with a GLEP, but we should come to an agreement and take internal action first.
+2018-06-03 15:06:46	@ChrisADR	ok, what about this...
+2018-06-03 15:06:55	@b-man	I proposed to agree that we as a project support all stable profiles
+2018-06-03 15:07:11	@b-man	by doing that we remove all security supported lingo from the pages.
+2018-06-03 15:07:13	@K_F	that part we can do.. I don't like it personally, but that is possible
+2018-06-03 15:07:26	@b-man	send out a notice that we now support all stable arches
+2018-06-03 15:07:47	@K_F	but we need to be aware that we don't have any control of what is marked stable, so suddenly a developer can add risc-v and we have no prior notice
+2018-06-03 15:07:47	@b-man	then we draft a GLEP to present ot the council detailing the "rules of a stable arch" (e.g. if you suck you get dropped).
+2018-06-03 15:08:07	@ChrisADR	I consider it the wrong order b-man 
+2018-06-03 15:08:32	@b-man	As I have said before, nothing will change if council does not do it.
+2018-06-03 15:08:33	@ChrisADR	If we'd have to vote right now... as Whissi said, ATs don't have a procedure to define something as 'stable' or markt it
+2018-06-03 15:08:57	@b-man	So, if all of that fails we can just go back and say sorry... your arch is no longer supported.
+2018-06-03 15:09:01	@ChrisADR	we need first to define what we expect to be considered before it is marked as stable
+2018-06-03 15:09:07	@b-man	but, I have confidence the council will see it our way.
+2018-06-03 15:09:13	@ChrisADR	that way we ensure that something is stable because it is security covered
+2018-06-03 15:09:31	@b-man	So, as a "show of good faith" we should take *some* action within the project first.
+2018-06-03 15:10:16	@b-man	K_F: Sure, that could happen, but highly doubtful.
+2018-06-03 15:10:24	domhnall	Why does this fail appealing to read GENTOO?
+2018-06-03 15:10:27	@ChrisADR	I consider that the show of good faith needs to be a formal proposal, worked by all of us, then presented to the community, and then to council if needed
+2018-06-03 15:10:27	@b-man	It would be a systematic process before that arch became stable
+2018-06-03 15:10:42	@Whissi	Don't treat security as an add-on. It should be _normal_ for stable to have security coverage. I really cannot think of any reason why you want something exposed as "stable" but give a shit about stabilization.
+2018-06-03 15:11:05	@K_F	right, but today it is an add-on, security isn't a special project
+2018-06-03 15:11:13	domhnall	right
+2018-06-03 15:11:14	@b-man	It doesn't need to be *special*
+2018-06-03 15:11:16	@K_F	I tend to agree we want to be one
+2018-06-03 15:11:18	@Whissi	It don't has to be a special for that
+2018-06-03 15:11:28	domhnall	heh
+2018-06-03 15:11:37	@b-man	Aside from the Gentooism of projects then sure it may be considered *special*
+2018-06-03 15:11:45	@K_F	Whissi: depends on the order of things, security supporting everything that is marked stable is possible
+2018-06-03 15:11:55	@K_F	but something doesn't need security coverate to become stable
+2018-06-03 15:12:04	@K_F	coverage*
+2018-06-03 15:12:34	@b-man	define something?  an arch, a package?
+2018-06-03 15:12:39	@K_F	the first we can decide on as a project, the second requires something else
+2018-06-03 15:13:09	@Whissi	Well... I think I got your point but I think we can ignore this. It is important to have a rule for Gentoo itself what's need to be done to mark an architecture stable and when a stable flag will be removed.
+2018-06-03 15:13:31	@Whissi	s/need/needed/
+2018-06-03 15:13:34	@K_F	right, but that requires a GLEP or at least a council vote on a properly written proposal
+2018-06-03 15:13:42	@Whissi	ACK.
+2018-06-03 15:13:47	@b-man	I think we have enough mechanisms in place (QA and Council) to ensure anything seriously worrisome (from a security perspective) is dealt with
+2018-06-03 15:13:51	@Whissi	(if we haven't something like that today)
+2018-06-03 15:13:52	@K_F	and likely a combination of both, 1) making Security a special project similar to QA
+2018-06-03 15:14:05	@Whissi	No. We don't need to be special for this.
+2018-06-03 15:14:10	@Whissi	Why do you want to combine this?
+2018-06-03 15:14:11	@K_F	2) a council vote on policy to mark arches stable
+2018-06-03 15:14:41	@K_F	if Security support is required to mark an arch stable, we claim to be special
+2018-06-03 15:14:52	@K_F	even more so if input to drop an arch from stable
+2018-06-03 15:15:01	@b-man	K_F: Or, the council claims to be smartly deciding what we allow.  Security should be one of those.
+2018-06-03 15:15:20	@K_F	b-man: technically you don't even need a council vote to mark an arch stable todday
+2018-06-03 15:15:27	@b-man	This is true.
+2018-06-03 15:15:33	@b-man	So, council should fix that.
+2018-06-03 15:15:43	@Whissi	Think about a simple GLEP saying: "You are a developer and you care for YOURARCH. Nice! If you want to mark YOURARCH stable, you have to tell anyone about your plans. From this moment, the whole community will start watching for X months to see if you can keep up with other architectures. Once you passed the test, YOURARCH will be marked as stable." Bum.
+2018-06-03 15:15:50	@K_F	b-man: its not really a problem as it is
+2018-06-03 15:16:14	@b-man	K_F: Sure it is, because we constantly see a flux of arches as stable/not stable
+2018-06-03 15:16:25	@b-man	but no one cares because we don't "promise" anything to our users.
+2018-06-03 15:16:30	@K_F	(of course, even talking about stable arches is incomplete, we need to consider the profiles too, but that is easier, we can just make it && dev profile)
+2018-06-03 15:16:57	@Whissi	Another paragraph: "Once you cannot keep up anymore, you will receive a strike. After 3 strikes, YOURARCH will be downgraded to exp again and you have to proof again for some time, that you can keep up, if you want to get back stable flag.
+2018-06-03 15:17:13	@ChrisADR	ok, I think we all ACK that a formal proposal needs to be written
+2018-06-03 15:17:40	@b-man	Sure, I agree a formal proposal needs to happen, but let's take some action internally for once first :)
+2018-06-03 15:17:53	@ChrisADR	that will define relevant aspects of Security project and some parameters that an arch needs to pass in order to be considered stable
+2018-06-03 15:18:25	@ChrisADR	so, are we all in the same page right now?
+2018-06-03 15:18:35	@b-man	and if our formal proposal implies that a stable arch == security supported then by our "good faith" actions we will show the council we *believe* it is important.
+2018-06-03 15:18:35	@K_F	ChrisADR: fwiw, those are likely parallel proposals, but something like that, yes
+2018-06-03 15:19:03	@b-man	*if* we believe security is important then we should act upon it.
+2018-06-03 15:19:25	@ChrisADR	ok, make it two separate proposals, but we all agree that those proposals need to be presented, right?
+2018-06-03 15:19:46	Irishluck83	yes
+2018-06-03 15:19:48	@K_F	I think working on them internally is anyways useful to outline policy
+2018-06-03 15:20:05	@b-man	Not, "security is important, but we want to choose what is convenient to us"
+2018-06-03 15:20:09	@K_F	then we'll determine what needs external validation and not when we have a more complete proposal
+2018-06-03 15:20:20	@b-man	This is also the reason we need to take action and convince the council it is important.
+2018-06-03 15:20:28	@b-man	It should be baked-in... not an add-on
+2018-06-03 15:21:10	@ChrisADR	ok, what about this... K_F and me will work on the Security project structure as a document, b-man and Whissi, since you are involved with ATs in x64 and amd64, could you write some guidelines about what times, needs, constraints, and arch needs to accomplish to be considered 'stable'?
+2018-06-03 15:21:12	@b-man	and quite frankly, it would be nice to see the council discuss security on a regular basis
+2018-06-03 15:21:40	@ChrisADR	s/and arch/an arch/
+2018-06-03 15:22:04	@b-man	Sure
+2018-06-03 15:22:04	@K_F	b-man: there isn't often a need for a council decision on it, that is only needed to set policy (as we're currently discussing, but that requires a proper proposal)
+2018-06-03 15:22:24	@K_F	otherwise it is the domain of Security
+2018-06-03 15:22:24	@b-man	K_F: Yes, via the proposal they will have to make a decision.
+2018-06-03 15:22:46	@K_F	well, strictly speaking not only that, if someone started Security II tomorrow they could do that
+2018-06-03 15:23:15	@b-man	Well then, I am going to fork the security project!
+2018-06-03 15:23:28	@b-man	LibreSecurity!!!!!!
+2018-06-03 15:23:43	@b-man	Who's coming with me? :-P
+2018-06-03 15:23:55	 *	b-man is joking of course
+2018-06-03 15:24:35	@ChrisADR	ok so... both documents prepared internally... then presented to community in order to be presented to council for a final decition... agree?
+2018-06-03 15:24:42	@b-man	We are going to use Python instead of Ruby!
+2018-06-03 15:24:54	@K_F	ChrisADR: right..
+2018-06-03 15:25:10	@b-man	and instead of padawans we will have Ninjas in training
+2018-06-03 15:25:22	@b-man	cuz ninjas are way cooler
+2018-06-03 15:25:34	@ChrisADR	Whissi b-man: agree?
+2018-06-03 15:25:49	@Whissi	On LibreSecurity?
+2018-06-03 15:25:52	@b-man	ChrisADR: On Ninjas?  Yes :)
+2018-06-03 15:25:53	Irishluck83	actually i did some ninjustus in college
+2018-06-03 15:26:04	Irishluck83	ninjutsu
+2018-06-03 15:26:12	@b-man	I agree the documents, yes.
+2018-06-03 15:26:16	@Whissi	Well, b-man and I will create some guidelines, yes...
+2018-06-03 15:26:19	@ChrisADR	on preparing both documents (sec structure and arch stabilization constraints) to be presented formally to council as soon as possible
+2018-06-03 15:26:32	@Whissi	First we present it to security
+2018-06-03 15:26:44	@ChrisADR	sure
+2018-06-03 15:26:46	@b-man	Now, can we decide on stable arch == supported internally?
+2018-06-03 15:26:58	@Whissi	And before council, it will go to -dev ml to have some fun. Council is only final destination to vote after community discussed.
+2018-06-03 15:26:58	@K_F	right, first internal, then community discussion / RFC
+2018-06-03 15:27:05	@b-man	and get rid of the silly "security supported" list on the s.g.o?
+2018-06-03 15:27:05	@ChrisADR	I don't think we can given the current status of things
+2018-06-03 15:27:37	@ChrisADR	yes, following standard procedures of course
+2018-06-03 15:27:47	@K_F	well, we can, I'm not sure if we want to
+2018-06-03 15:27:48	domhnall	b-man: why?
+2018-06-03 15:27:51	@b-man	"Be the change you want to see in Gentoo" - Daniel Robbins
+2018-06-03 15:28:38	domhnall	Please, ChrisADR, keep the posted supported list.
+2018-06-03 15:28:49	@b-man	Ghandi and Daniel Robbins were friends.
+2018-06-03 15:29:00	@ChrisADR	I'd love to get rid of that part, but I don't see it as a wise decision right now, specially not having some guidelines about what 'stable' actually is
+2018-06-03 15:29:11	@ChrisADR	to begin with
+2018-06-03 15:29:23	@b-man	We don't *control* anything anyway
+2018-06-03 15:29:36	@K_F	we control what we call security supported
+2018-06-03 15:29:50	@b-man	so, the very *control* we think we have is just a way of saying "screw you user..."
+2018-06-03 15:30:09	@b-man	and it still leaves vulnerable ebuilds in the tree cuz arch X isn't caught up
+2018-06-03 15:30:26	@b-man	So, by pretending we have *control* we are just proving that we *don't* care.
+2018-06-03 15:30:45	@K_F	that won't change by us setting security supported = stable
+2018-06-03 15:30:53	@b-man	Nope, it won't.
+2018-06-03 15:30:59	@b-man	but it will show that we *do* care.
+2018-06-03 15:31:06	@ChrisADR	ok, it's clear that the current status is not great, and that if we change it right now it won't help neither
+2018-06-03 15:31:24	@b-man	and by taking action prior to telling the world we think we should do business a certain way means we believe it.
+2018-06-03 15:31:30	@K_F	at least now the user has a possibility of getting a warning, if support is dropped due to sluggishness etc
+2018-06-03 15:31:41	@ChrisADR	so, let's prepare those guidelines and present them, and show that we do care about security in general
+2018-06-03 15:32:24	@ChrisADR	ok let's finish that point with the documentation pending and move one
+2018-06-03 15:32:32	@b-man	Then lets at least take down "Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us." from s.g.o
+2018-06-03 15:32:48	@b-man	cuz that != true
+2018-06-03 15:33:28	@ChrisADR	well it is... that's why we are having this long discussion...
+2018-06-03 15:33:51	@ChrisADR	but moving on... anything else, or should I bang the gavel?
+2018-06-03 15:34:07	@K_F	one small thing, I noticed while linking on AMA ...
+2018-06-03 15:34:15	@ChrisADR	sure
+2018-06-03 15:34:41	@K_F	Update current members of https://wiki.gentoo.org/wiki/Project:Security/Affiliations <- we need to update this a bit with new members
+2018-06-03 15:35:19	@K_F	at least distros is wrong
+2018-06-03 15:35:29	@ChrisADR	I had never seen that document :P
+2018-06-03 15:35:54	@ChrisADR	can you take a look at that for us K_F ?
+2018-06-03 15:36:11	@K_F	yes, I added it to my TODO (but won't be next week..)
+2018-06-03 15:36:28	@K_F	reminds me, I need to set a devaway
+2018-06-03 15:36:32	@ChrisADR	well, it's not the most urgent thing we have right now
+2018-06-03 15:36:35	@ChrisADR	thanks :)
+2018-06-03 15:37:23	@ChrisADR	ok, something else? we are 37 mins over schedule
+2018-06-03 15:37:45	@K_F	nothing more from me
+2018-06-03 15:38:24	@ChrisADR	ohh before I forgot, please add those documents to the repo, same place as glsamaker-use_cases please
+2018-06-03 15:38:48	@ChrisADR	I mean, sec structure and arches constraints
+2018-06-03 15:39:25	 *	ChrisADR bangs the gavel, thank you for your time today
diff --git a/meetings/logs/sec-meeting-2018-06-24-log b/meetings/logs/sec-meeting-2018-06-24-log
new file mode 100644
index 0000000..dbe4e97
--- /dev/null
+++ b/meetings/logs/sec-meeting-2018-06-24-log
@@ -0,0 +1,184 @@
+2018-06-24 13:59:47	@ChrisADR_mobile	!proj security
+2018-06-24 13:59:49	willikins	ChrisADR_mobile: (security@gentoo.org) a3li, ackle, blueknight, bman, chrisadr, creffett, k_f, pinkbyte, whissi, zlogene, zx2c4
+2018-06-24 13:59:53	@ChrisADR_mobile	Meeting time
+2018-06-24 14:00:02	 *	K_F is here
+2018-06-24 14:00:06	 *	domhnall here
+2018-06-24 14:00:06	 *	MyNt1a is here
+2018-06-24 14:00:09	 *	ChrisADR_mobile here too
+2018-06-24 14:00:11	 *	Irishluck83 here
+2018-06-24 14:01:50	@ChrisADR_mobile	Whissi b-man?
+2018-06-24 14:01:55	 *	b-man here 
+2018-06-24 14:02:27	@ChrisADR_mobile	b-man: are you in your laptop?
+2018-06-24 14:02:38	@b-man	Nope.  Should I be?
+2018-06-24 14:03:05	@ChrisADR_mobile	Can you? K_F and I are in mobiles, maybe would be faster if you can lead
+2018-06-24 14:03:13	@ChrisADR_mobile	Or you Whissi
+2018-06-24 14:04:01	@b-man	Ok, on laptop
+2018-06-24 14:04:28	@K_F	thanks.. I wont be on laptop for another 15 min or so :)
+2018-06-24 14:04:33	@ChrisADR_mobile	Awesome, thanks, please first topic, I can't see it in the cellphone while writing here
+2018-06-24 14:04:40	@b-man	Security Project Structure GLEP review:
+2018-06-24 14:04:56	@b-man	Want to hold that one until K_F is on laptop?
+2018-06-24 14:05:09	@ChrisADR_mobile	K_F: should we?
+2018-06-24 14:05:32	@K_F	no.. I havent gotten around to preparing much on that anyways. thankfully slowing down a bit this week
+2018-06-24 14:06:06	@K_F	good news is there was a new Norwegian record in CSWC yesterday combined with 20year anniversary party :)
+2018-06-24 14:06:23	@ChrisADR_mobile	Ok, so, you have the updates in the repo, I added some stuff about motivaron and stable dropping
+2018-06-24 14:07:25	@ChrisADR_mobile	If there are no objections or feedback about those paragraphs, should we move on?
+2018-06-24 14:07:48	Irishluck83	where are they located in glep?
+2018-06-24 14:07:49	@K_F	yeah.. will follow up by email during week
+2018-06-24 14:08:02	@K_F	Irishluck83: in a private git repo of ours
+2018-06-24 14:08:04	@ChrisADR_mobile	b-man:?
+2018-06-24 14:08:11	Irishluck83	ok
+2018-06-24 14:08:13	@b-man	No objections from me
+2018-06-24 14:08:19	@ChrisADR_mobile	Ok fine
+2018-06-24 14:08:24	@ChrisADR_mobile	Next topic?
+2018-06-24 14:08:36	@b-man	GLSAMaker use cases doc
+2018-06-24 14:09:03	@b-man	"I've finished a first draft of the user stories, now with a clearer idea of what
+2018-06-24 14:09:03	@b-man	does every access level do and what the functionalities are, we may take a look
+2018-06-24 14:09:03	@b-man	at the padawan relation with CVETool."
+2018-06-24 14:09:09	@ChrisADR_mobile	Oh right, I updated some use cases, now it's fully mapped, at least what we currently have
+2018-06-24 14:09:42	@b-man	In this, I would ask if there are any objections to granting access to padawans for the CVETool prior to becoming a full GLSA coordinator.
+2018-06-24 14:09:57	@ChrisADR_mobile	+1
+2018-06-24 14:10:08	@b-man	It seems properly using the permissions as ChrisADR_mobile has mapped for us restricts this access.
+2018-06-24 14:10:22	@ChrisADR_mobile	Most likely a minor permission change in the code, but still necessary I think
+2018-06-24 14:10:24	@b-man	It would be good for the padawan to be exposed to the tool early on
+2018-06-24 14:10:30	@K_F	do we have any granularity in access restrictions on cvetool? e.g if adding embargoed CVEs
+2018-06-24 14:10:57	@b-man	K_F: I don't think the CVE will show up in the list as it pulls from the public CVE releases.
+2018-06-24 14:11:07	@K_F	not if we add it ourselves
+2018-06-24 14:11:15	@b-man	If the CVE is embargoed all that should show is the boilerplate text.
+2018-06-24 14:11:26	@b-man	hmmm
+2018-06-24 14:11:31	@b-man	I don't follow then K_F
+2018-06-24 14:11:34	@ChrisADR_mobile	Not really, if we add it the content is reserved until a public announce is made
+2018-06-24 14:11:55	@ChrisADR_mobile	I mean "*RESERVED * stuff stuff....."
+2018-06-24 14:12:05	@K_F	not if we add it to the tracker manually.. but indeed we normally just use boilerplate text but it discloses that there is an issue in specific packages even so
+2018-06-24 14:12:15	@b-man	K_F: You mean we manually add the CVE with the privately released text?
+2018-06-24 14:12:36	@K_F	doesnt even need to be privileged text.. you'll disclose the applications having issues
+2018-06-24 14:12:51	@ChrisADR_mobile	I think he means the 'cvetool new CVE-NUM
+2018-06-24 14:13:06	@K_F	right
+2018-06-24 14:13:07	@b-man	K_F: How would they see the tracker?
+2018-06-24 14:13:21	@b-man	that command puts boilerplate text in it
+2018-06-24 14:13:23	@K_F	if they have access to cvetool?
+2018-06-24 14:13:44	@ChrisADR_mobile	Yes, they shouldn't theoretically
+2018-06-24 14:13:57	@b-man	I don't see a way to view a bug with CVETool's permissions.
+2018-06-24 14:14:03	@K_F	they would see the assignment while preparing the GLSA
+2018-06-24 14:14:13	@ChrisADR_mobile	They should see the boilerplate text, both in command line and web interface
+2018-06-24 14:14:33	@K_F	right, but that still leaks the application
+2018-06-24 14:14:45	@ChrisADR_mobile	No they don't, if the GLSA is marked as private, they can't see anything
+2018-06-24 14:14:49	@b-man	I am still not following how this would expose anything, sorry.
+2018-06-24 14:15:04	@K_F	they would see the bug assigned for the CVE in cvetool
+2018-06-24 14:15:06	@b-man	As ChrisADR_mobile just said the GLSA would be marked private.
+2018-06-24 14:15:19	@b-man	Right, but that text will be boilerplate as many texts are.
+2018-06-24 14:15:22	@ChrisADR_mobile	Without private permission no
+2018-06-24 14:15:45	@ChrisADR_mobile	I tested that with yury
+2018-06-24 14:16:02	@ChrisADR_mobile	That only see public stuff, both in web and cli
+2018-06-24 14:16:10	@K_F	but might not be much of an issue ultimately
+2018-06-24 14:16:25	@ChrisADR_mobile	The thing is that we have to mark it as private while working on it
+2018-06-24 14:16:59	@b-man	So, given that are you comfortable K_F/
+2018-06-24 14:17:03	@b-man	?
+2018-06-24 14:17:13	@ChrisADR_mobile	Besides, right now, the only member who would have that priv is Irishluck83
+2018-06-24 14:17:37	@K_F	we can always try it out for a bit anyways.. and get some more experience with it
+2018-06-24 14:17:38	 *	sokan here
+2018-06-24 14:17:40	@ChrisADR_mobile	We can make him sign the disclosure agreement earlier, and test with him both interfaces
+2018-06-24 14:17:52	@b-man	Perfect.
+2018-06-24 14:17:58	@ChrisADR_mobile	Right, sounds good to me
+2018-06-24 14:18:11	@b-man	I will request his permissions following the meeting.
+2018-06-24 14:18:33	@K_F	that we set ourselves
+2018-06-24 14:18:42	@ChrisADR_mobile	Ok so, just to make it official, please vote in the permission change
+2018-06-24 14:18:52	@b-man	This will also allow us to tweak any permission models during testing
+2018-06-24 14:19:04	 *	ChrisADR_mobile yes 
+2018-06-24 14:19:08	 *	b-man yes
+2018-06-24 14:19:09	 *	K_F yes
+2018-06-24 14:19:14	@ChrisADR_mobile	Ok perfect
+2018-06-24 14:19:33	@ChrisADR_mobile	I'll work on that change in the next weeks, hopefully it's not that complicated
+2018-06-24 14:19:56	@b-man	I have already started looking at it and I don't believe it will be
+2018-06-24 14:19:57	@ChrisADR_mobile	Ok, moving on to next topic...
+2018-06-24 14:20:05	@ChrisADR_mobile	Great!!
+2018-06-24 14:20:27	@b-man	Welcome to the new scouts:
+2018-06-24 14:20:50	domhnall	o/
+2018-06-24 14:21:03	@ChrisADR_mobile	Ahhhhh right :)
+2018-06-24 14:21:04	Irishluck83	yep welcome scouts
+2018-06-24 14:21:20	@ChrisADR_mobile	Welcome fresh meat \o/
+2018-06-24 14:21:49	@b-man	For all the new scouts: if you PM K_F your mailing address he will send you free cigars
+2018-06-24 14:21:58	@ChrisADR_mobile	Since sokan and MyNt1a are here already, and they requested formally to join the team a while back
+2018-06-24 14:22:14	@b-man	:-P
+2018-06-24 14:22:26	MyNt1a	o/
+2018-06-24 14:22:26	@ChrisADR_mobile	I was thinking I'd time to assign them their mentors
+2018-06-24 14:23:48	@ChrisADR_mobile	So K_F, you and Whissi are the closest devs around them... How are your schedules?
+2018-06-24 14:23:59	sokan	\ο
+2018-06-24 14:24:10	@K_F	hectic
+2018-06-24 14:24:12	@ChrisADR_mobile	Well... Busy as always, but any chance to add one more task?
+2018-06-24 14:24:16	@ChrisADR_mobile	Hehe
+2018-06-24 14:24:29	domhnall	ChrisADR_mobile: mentors are assigned now?
+2018-06-24 14:24:45	@b-man	domhnall: We are just checking availability.
+2018-06-24 14:24:52	domhnall	oh
+2018-06-24 14:24:55	@ChrisADR_mobile	Well, they have requested and being working for a while
+2018-06-24 14:25:10	@b-man	MyNt1a: domhnall, where are you located?
+2018-06-24 14:25:12	@ChrisADR_mobile	So, meetings are a good time to see availability
+2018-06-24 14:25:13	@b-man	!time MyNt1a
+2018-06-24 14:25:13	willikins	b-man: I don't know where MyNt1a is, (s)he should use !time set <Continent>/<City> to let me know
+2018-06-24 14:25:15	MyNt1a	germany
+2018-06-24 14:25:16	@b-man	!time domhnall
+2018-06-24 14:25:16	willikins	b-man: I don't know where domhnall is, (s)he should use !time set <Continent>/<City> to let me know
+2018-06-24 14:25:36	@ChrisADR_mobile	MyNt1a: is Germany, domhnall USA right?
+2018-06-24 14:25:37	domhnall	!time America/New_York
+2018-06-24 14:25:37	willikins	domhnall: America - New York - Sun Jun 24 15:25 EDT
+2018-06-24 14:25:57	@b-man	I can mentor domhnall if he would like
+2018-06-24 14:26:20	@ChrisADR_mobile	domhnall: thoughts?
+2018-06-24 14:26:22	@K_F	sounds good.. I can mentor MyNt1a
+2018-06-24 14:26:35	@ChrisADR_mobile	MyNt1a: thoughts?
+2018-06-24 14:26:44	MyNt1a	would be great :D
+2018-06-24 14:27:20	@ChrisADR_mobile	Well then, sokan would be between me and Whissi, and our last scout for the other one
+2018-06-24 14:27:23	domhnall	b-man: honored and i accept.
+2018-06-24 14:27:44	@b-man	Well, that settles that.  I will update the wiki following the meeting
+2018-06-24 14:27:57	sokan	ChrisADR_mobile: sure thing, and thanks :)
+2018-06-24 14:28:00	@ChrisADR_mobile	Thanks b-man
+2018-06-24 14:28:33	@ChrisADR_mobile	Yes, let's wait Whissi to see that and according to that we'll add all scouts and mentors :)
+2018-06-24 14:28:44	@b-man	ChrisADR_mobile: ?
+2018-06-24 14:28:55	 *	zlogene passes around 
+2018-06-24 14:28:57	@ChrisADR_mobile	No no, that was for sokan
+2018-06-24 14:29:02	@b-man	ok
+2018-06-24 14:29:02	@ChrisADR_mobile	b-man:
+2018-06-24 14:29:26	@ChrisADR_mobile	Hi zlogene :) do you want a scout? :p
+2018-06-24 14:29:38	domhnall	b-man: should you be absent, who would i difer questions to?
+2018-06-24 14:30:01	@zlogene	ChrisADR_mobile: what do you mean I do not follow?:p
+2018-06-24 14:30:09	@b-man	domhnall: for you and all the scouts/padawans/ninjas always feel free to ask questions in the main channel.  It will also ensure you get a timely answer.
+2018-06-24 14:30:33	@ChrisADR_mobile	We are assigning mentors :p would you like a mentee scout?
+2018-06-24 14:30:58	@b-man	domhnall: This is also why we try to ensure matches are done by timezones.
+2018-06-24 14:31:15	@ChrisADR_mobile	That leaves the floor open, any other stuff?
+2018-06-24 14:31:22	@zlogene	ChrisADR_mobile: no, I am pretty feed up with teaching people being the recruiter :p
+2018-06-24 14:31:46	@ChrisADR_mobile	Hahaha ohhhh :( well worth the effort :)
+2018-06-24 14:31:46	@b-man	ChrisADR_mobile: zlogene is a Gentoo recruiter as well
+2018-06-24 14:32:46	@ChrisADR_mobile	Ok then, for the first time... This was a nice and short meeting \o/
+2018-06-24 14:32:57	 *	ChrisADR_mobile bangs the gavel
+2018-06-24 14:32:57	sokan	this it it? o.O
+2018-06-24 14:33:00	@K_F	:)
+2018-06-24 14:33:04	@ChrisADR_mobile	Thank you all!!
+2018-06-24 14:33:11	@b-man	damn
+2018-06-24 14:33:15	@b-man	I had a open floor thing
+2018-06-24 14:33:20	sokan	...
+2018-06-24 14:33:25	Irishluck83	nice. nice and quick. i still thing padawans should be ninjas. :)
+2018-06-24 14:33:25	sokan	that was fast :D
+2018-06-24 14:33:28	@ChrisADR_mobile	Oh, rewind then
+2018-06-24 14:33:29	domhnall	b-man: a dance move?
+2018-06-24 14:33:36	@b-man	domhnall: Only on Friday's
+2018-06-24 14:33:41	sokan	nooo. no ninjga. add sith lords :D
+2018-06-24 14:33:42	Irishluck83	*think
+2018-06-24 14:33:58	@ChrisADR_mobile	Ok, no open floor stuff then?
+2018-06-24 14:34:01	@b-man	Yes,
+2018-06-24 14:34:04	@b-man	I am typing
+2018-06-24 14:34:09	@ChrisADR_mobile	Cool :)
+2018-06-24 14:34:31	sokan	so ChrisADR_mobile I can easily spam you questions now with no remorse eh? :P
+2018-06-24 14:34:32	@b-man	I wanted to begin the discussion of slacker marks or something similair to that for security team
+2018-06-24 14:35:06	@ChrisADR_mobile	That'd reduce significantly the team hehe
+2018-06-24 14:35:13	@ChrisADR_mobile	What do you propose?
+2018-06-24 14:35:39	@b-man	Nothing solid yet, but I wanted to begin the discussions. I will send a mail with some rough ideas.
+2018-06-24 14:35:42	@K_F	I'm not really a fan of that, if we're worried about activity we can always deal with that on case-by-case basis, but slacker mark doesn't sound useful
+2018-06-24 14:36:15	@ChrisADR_mobile	Well, prepare the email, and sure, we can begin discussion and see
+2018-06-24 14:36:25	@b-man	K_F: That could work too.  I am not sold on the "slacker" marks piece.  Just using it as an example to communicate what I am thinking.
+2018-06-24 14:36:44	@b-man	I see a lot of folks as sec members who don't do anything :)
+2018-06-24 14:36:54	@ChrisADR_mobile	Yea, it may be interesting topic to discuss
+2018-06-24 14:37:18	@K_F	yeah, the broader topic is more interesting to discuss
+2018-06-24 14:37:25	@ChrisADR_mobile	But that's for the next meeting if the mail is sent ;)
+2018-06-24 14:37:44	 *	ChrisADR_mobile prepares the gavel again 
+2018-06-24 14:38:00	 *	b-man plugs his ears
+2018-06-24 14:38:03	 *	ChrisADR_mobile waits a couple of secs 
+2018-06-24 14:38:15	 *	ChrisADR_mobile bangs again :) 
+