meeting logs: Added sec-meeting-2018-04-21-log

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

1 files changed, 269 insertions, 0 deletions

diff --git a/sec-meeting-2018-04-21-log b/sec-meeting-2018-04-21-log
new file mode 100644
index 0000000..a599742
--- /dev/null
+++ b/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