diff options
Diffstat (limited to 'meetings')
| -rw-r--r-- | meetings/logs/sec-meeting-2018-02-18-log | 231 | ||||
| -rw-r--r-- | meetings/logs/sec-meeting-2018-04-21-log | 269 | ||||
| -rw-r--r-- | meetings/logs/sec-meeting-2018-06-03-log | 346 | ||||
| -rw-r--r-- | meetings/logs/sec-meeting-2018-06-24-log | 184 |
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 :) + |