path: root/sec-meeting-2018-04-21-log

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