diff options
Diffstat (limited to 'meetings')
| -rw-r--r-- | meetings/logs/sec-meeting-2018-07-29-log | 190 |
1 files changed, 190 insertions, 0 deletions
diff --git a/meetings/logs/sec-meeting-2018-07-29-log b/meetings/logs/sec-meeting-2018-07-29-log new file mode 100644 index 0000000..ed2d27b --- /dev/null +++ b/meetings/logs/sec-meeting-2018-07-29-log @@ -0,0 +1,190 @@ +[14:05:05] <K_F> ChrisADR: postpone 15 min? wrapping up council about now +[14:05:21] <MyNt1a> hi +[14:07:58] <K_F> actually doesn't matter, discussion is light enough now I can do them in parallel +[14:16:24] <ChrisADR> K_F: 15 mins done :) +[14:16:31] <K_F> ChrisADR: :) +[14:16:37] <ChrisADR> are you ready? +[14:16:40] <K_F> yup +[14:16:50] <ChrisADR> k then !proj security +[14:16:58] <ChrisADR> !proj security +[14:17:00] <willikins> ChrisADR: (security@gentoo.org) ackle, blueknight, bman, chrisadr, creffett, k_f, pinkbyte, whissi, zlogene, zx2c4 +[14:17:03] <ChrisADR> roll call +[14:17:13] -*- Irishluck83 here +[14:17:14] <Whissi> Too early. +[14:17:16] -*- MyNt1a here +[14:17:26] -*- K_F here +[14:17:28] -*- domhnall here +[14:17:28] -*- ChrisADR here +[14:18:11] <ChrisADR> ok let's see +[14:18:40] <ChrisADR> first point, Security Project Structure, has anybody read the docs? +[14:19:32] <K_F> I really wish I could say yes... but no.. back home now though, so should be able to get through it next week +[14:21:43] <ChrisADR> K_F: is it ok if after a wee I send an email to sec@g.o and see if we are ready for first publication? +[14:21:51] <ChrisADR> s/wee/week +[14:22:18] <K_F> yup +[14:22:25] <ChrisADR> there is still one topic to add, if I'm not wrong +[14:22:46] <ChrisADR> let's move to topic 3 for the sake of logic +[14:22:58] <ChrisADR> b-man: here? +[14:23:25] <ChrisADR> you proposed to talk about the security members participation, e.g. slack in project and consequences +[14:23:45] <ChrisADR> that seems to be something to add in the project structure +[14:24:10] <ChrisADR> meanwhile, anyone thoughts about that? +[14:24:48] <K_F> ChrisADR: one way to do that is mimic glep 48, leads gets confirmed etc etc, and is responsible for behavior of all users in project, so can also remove members from project +[14:25:46] <ChrisADR> ok, which factors do we consider to remove a member? +[14:26:44] <K_F> for one thing they have access to certain restricted information, so I'd say it depends on whether they are still active in gentoo at all etc +[14:27:01] <K_F> the focus on security vs other projects will necessary change a bit over time depending on needs +[14:27:35] <K_F> that goes for the activity point.. the obvious example is also where a member no longer has the trust of the leads +[14:28:25] <ChrisADR> one example of trust loss please? +[14:29:31] <K_F> there have been a few situations in the past where info has been leaked , others where security members have been stepping out of bounds somewhat and put security in bad light.. but not the past few years +[14:31:23] <ChrisADR> ok, sounds like we do need to write that inside the proposal +[14:31:51] <K_F> can write some examples, it shouldn't be a complete list +[14:31:54] <Whissi> I hope we can move this to undertaker project +[14:32:00] <K_F> no, that is separate issue +[14:32:15] <ChrisADR> we could let them know though +[14:32:27] <Whissi> Mh. Ah I see the problem. +[14:33:00] <K_F> the criteria for removal are also relative +[14:33:16] <K_F> if sufficient members it is easier to remove than lacking manpower to begin with, where it is counter-intuitive +[14:33:27] <Whissi> People like Pinkbyte and ackle... not active in Gentoo Security daily operation for example... +[14:33:49] <Whissi> But still active in Gentoo somehow +[14:34:49] <ChrisADR> yea well, I was thinking in situations where the only "active" participation is in security (wrt undertaker proj) +[14:35:27] <ChrisADR> of course, if they contribute in some other areas, we would need to remove access from some tools/info we receive as security project +[14:37:15] <K_F> ChrisADR: and alias etc etc, so easiest way of that is a clean cut removal from security project +[14:37:33] <K_F> we can likely move things like glsamaker development to other alias though that has more members +[14:37:45] <K_F> maybe a more generic, security-wider-audience alias +[14:38:25] <ChrisADR> yea, sounds good to me +[14:39:51] <ChrisADR> so, I'm going to add a new section about project removal, with some guidelines, and most likely in the way we'll have to see other channels for things like development as you mention k_f +[14:40:22] <ChrisADR> agree? +[14:40:45] <Irishluck83> yep +[14:42:23] <ChrisADR> good :) no complains, moving to next topic then +[14:42:54] <ChrisADR> point 2 (excuse the order), some updates for the Security Handbook +[14:44:01] <ChrisADR> I read in #gentoo-wiki some mentions about an email from a user wanting to help updating the Security Handbook page, Whissi should have received a note too +[14:44:35] <Whissi> Yeah, but I didn't establish contact with that person yet. +[14:44:59] <ChrisADR> sure np +[14:45:44] <ChrisADR> K_F and padawans, do you have any extra ideas about the sec handbook? at least some kind of update/review process to eras that "Warning" note in the main page? +[14:45:47] <ChrisADR> https://wiki.gentoo.org/wiki/Security_Handbook +[14:46:20] <ChrisADR> 8 years is a long time :( and maybe is time for an update :) +[14:46:28] <K_F> I'd say remove it +[14:46:47] <ChrisADR> the flag? or the handbook? :o +[14:47:01] <K_F> it is general devops , and security project has better things to spend time on than updating it +[14:47:07] <K_F> the handbook +[14:47:15] <Irishluck83> yeah i kind of agree with that +[14:47:19] <MyNt1a> ^ agree +[14:47:42] <Irishluck83> if someone wanted to "harden" there os then they would follow another guide for that +[14:48:18] <ChrisADR> hmm +[14:48:38] <Whissi> I am against a removal. Yes, some parts are out of date, but not wrong. +[14:48:52] <Whissi> We didn't create that content so removing it would be harsh. +[14:49:04] <ChrisADR> well I understand the point, maybe we can share this handbook with hardening project? +[14:49:04] <domhnall> ^my thoughts on the matters align. +[14:49:19] <K_F> if they want to maintain it, by all means +[14:49:32] <ChrisADR> which imply participation from both teams to update/maintain it +[14:49:43] <K_F> its not under security project namespace as it is +[14:50:00] <K_F> but much of the content isn't even gentoo specific +[14:50:19] <K_F> just generic devops, network topology and architecture +[14:50:43] <K_F> and that already depends on threat model, what it is to be used for etc etc +[14:51:57] <ChrisADR> well I agree that the content is more general than specific, but I prefer not to remove stuff as whissi mentions, at least for tracking porpuses +[14:52:35] <K_F> right, which leaves warning and it staying as is.. +[14:52:47] <K_F> maybe updating warning; this is archived content and has not been.. +[14:52:53] <ChrisADR> let me send an email to hardened@g.o and see if they want to collaborate in the update :) +[14:53:10] <Irishluck83> could we merge it with the hardening project docs? i don't know if we need two docs on how to secure your pc +[14:53:11] <Whissi> There's just one question for me: +[14:53:34] <Whissi> This was a handbook in the past. I.e. dev content. +[14:53:50] <Whissi> I.e. only devs could edit content. +[14:54:15] <Whissi> My question would be, if we want to move that content to real Wiki content. I.e. open for everyone to contribute +[14:54:16] <Whissi> or not. +[14:54:50] -*- Whissi dislikes that Gentoo's handbook which could only be edited by devs, was transfered to the Wiki +[14:55:18] <Whissi> UGC is nice way to get content... but if nobody checks UGC... we will probably have bad/invalid content ;) +[14:55:26] <Whissi> And this is happening with Gentoo Wiki a lot :/ +[14:55:41] <Irishluck83> i say keep it semi closed. only devs can edit but the masses can contribute if they feel something needs to be added and then someone can put it in +[14:55:44] <ChrisADR> are you talking about *the* handbook? +[14:55:50] <Whissi> Yes +[14:56:00] <Whissi> We don't have "the" handbook anymore. +[14:56:04] <ChrisADR> it is still not editable for people without commit access to the repo I think +[14:56:06] <Whissi> It is now part of the Wiki :/ +[14:57:23] <Irishluck83> well i say keep it dev editable +[14:58:16] <ChrisADR> ohhh I see your point, I was trying to edit a translated version.. which is not possible, but the english version is editable +[14:58:22] <Whissi> See https://wiki.gentoo.org/wiki/Handbook:AMD64 ... you will find a lot of edits from non-Devs. Well, I am not saying that https://wiki.gentoo.org/wiki/Handbook:AMD64 is now bad content... haven read the handbook anymore since it was moved to wiki... but given that other Gentoo wiki pages do contain "wrong" information... :/ +[14:58:36] <Whissi> s/haven/haven't/ +[14:59:54] <Whissi> So to be clear: I don't want user generated security content which could be interpreted as "official" content. If this will happen I agree with k_f, remove it. +[15:00:02] <ChrisADR> k, I see two options right now, 1- mark the wiki as "archived" and don't let anyone edit it anymore... 2-share this site with hardened project (if they even want to maintain one more site) and then discuss with them if this should stay as dev-only or public wiki page +[15:00:51] <Irishluck83> well between those two then i'd go with the second option +[15:00:58] <ChrisADR> i'd rather prefer dev-only if this is about and updated *official* gentoo documentation +[15:01:40] <Irishluck83> agree. this type will obviously need to be contiunally updated so i w +[15:01:46] <Irishluck83> ould trust a dev to do it +[15:02:09] <ChrisADR> I'll send an email to hardened@g.o and see if they want to maintain this site with us, if not we mark it as archived, everybody agrees? +[15:02:44] <K_F> I'd go even further, and ask if they want to be primary maintainer +[15:02:47] <K_F> not just along with us +[15:02:56] <K_F> as to not give any false sense of expected work on it +[15:03:25] <K_F> to the extent is is ours to begin with +[15:03:36] <ChrisADR> yea... sounds fair and realistic +[15:03:57] <K_F> "We're considering marking this page as archived and locking it.. do you have any interest in maintaining it?" +[15:04:39] <ChrisADR> Whissi: agree? +[15:04:43] <ChrisADR> I do +[15:06:15] <Irishluck83> agree +[15:06:19] <ChrisADR> well unless another observation, we'll do that and see if hardened wants to maintain this :) open floor now +[15:06:30] <MyNt1a> agree +[15:06:35] <ChrisADR> does anyone have a topic? because I do +[15:06:59] <domhnall> I have a question. +[15:07:11] <Irishluck83> no, if you guys could look at the znc glsa that would be great +[15:07:33] <ChrisADR> your question domhnall +[15:07:42] <ChrisADR> Irishluck83: I'll try after the meeting ;) +[15:08:36] <ChrisADR> mgorny told me a couple of days ago that he could create an instance of glsamaker to develop stuff, do we want it to have a copy of our htpass file or a single/generic pass for everybody? +[15:08:51] <Whissi> ChrisADR: ack +[15:09:11] <ChrisADR> you can't ack on a two option question... do you? :P +[15:09:25] <Whissi> Damn. +[15:09:34] <ChrisADR> hahaha yea yea, handbook stuff :P +[15:09:40] <Whissi> <ChrisADR> I'll send an email to hardened@g.o and see if they want to maintain this site with us, if not we mark it as archived, everybody agrees? <-- I acked this one. +[15:10:29] <domhnall> okay, wrt https://wiki.gentoo.org/wiki/Project:Security/Bug_Searching, specificially, "Unhandled bugs , bugs that are in no known whiteboard state." Though there are bugs in the list which do have whiteboard status. Is something wrong with search term used here? +[15:11:41] <Whissi> Text says "no waitboard" but this doesn't mean empty whiteboard. +[15:11:52] <Whissi> It says no active security whiteboard status ;) +[15:12:09] <Whissi> I.e. query is '(does not match regular expression) ebuild|upstream|glsa|masked|stable' +[15:12:41] <Whissi> waitboard... man, I should stop writing for today. :) +[15:12:57] <Irishluck83> :) +[15:12:58] <ChrisADR> yea, we can fix query +[15:13:04] <Whissi> Query is right. +[15:13:05] <ChrisADR> almost done almost done :P +[15:13:58] <Whissi> I'll only update to include "blocked". Then I don't see any wrong bugs in that list. +[15:14:01] <ChrisADR> ohhh I see the mistake +[15:14:03] <Irishluck83> what was your topic ChrisADR +[15:14:08] <ChrisADR> I found one [upsteam] bug :P +[15:14:14] <Whissi> domhnall: Or do you have an example for a bug which shouldn't be listed in that result list? +[15:14:35] <ChrisADR> domhnall: bug 629956 :P +[15:14:38] <willikins> ChrisADR: https://bugs.gentoo.org/629956 "app-editors/gedit: GNOME gedit through 3.22.1 allows remote attackers to cause a denial of service"; Gentoo Security, Vulnerabilities; IN_P; mbailey_j:security +[15:14:43] <domhnall> Whissi, so "no known whiteboard state" doesnt mean no whiteboard at all? +[15:15:03] <domhnall> ChrisADR, Whissi sure, that'd be one example. +[15:15:14] <ChrisADR> no, it means you made a typo in the whiteboard :P +[15:15:22] <Whissi> domhnall: Wiki text should be "Not yet wrangled security bugs" :) +[15:15:32] <domhnall> Whissi, ah...lol. +[15:16:02] <Whissi> Mh, "unhandled bugs" implies that. +[15:16:26] <ChrisADR> yea, everything is ok it seems :) that sneaky missing "r" was the problem +[15:16:39] <ChrisADR> at least it wasn't a ";" at the end of a line domhnall ;) +[15:16:55] <domhnall> no comment +[15:16:57] <ChrisADR> we may have spend hours on that then :P +[15:17:47] <ChrisADR> ok, glsamaker stuff, do you all want a user and passw access, or do we only need one "generic" user +[15:18:21] <Whissi> https://wiki.gentoo.org/index.php?title=Project%3ASecurity%2FBug_Searching&type=revision&diff=727180&oldid=213072 +[15:18:30] <Irishluck83> say user/pass stuff +[15:18:33] <Whissi> domhnall: Better? +[15:19:57] <ChrisADR> domhnall: fixed https://bugs.gentoo.org/629956 +[15:20:43] <domhnall> Whissi, does unhandled bugs contain whiteboard or not? +[15:21:37] <Irishluck83> have to go...i'll catch up latter +[15:21:37] <domhnall> Maybe this can wait till meeting ends. (unless it has already), im not a fan of clutter. +[15:21:39] <Whissi> domhnall: Whiteboard isn't exclusive to security. So "unhandled (security) bugs" means bugs which need to be wrangled... they typically have no whiteboard value(s) from security project. +[15:21:44] <Irishluck83> later +[15:21:56] <domhnall> Whissi, okay. makes sense. +[15:23:32] <ChrisADR> Whissi K_F I'll request a single user access to glsamaker dev environment, is that ok for you? at least for now +[15:23:54] <Whissi> Did we get a response from infra? +[15:23:58] <K_F> ChrisADR: wfm +[15:24:18] <ChrisADR> Whissi: mgorny told me here that he could create an instance for us +[15:24:48] <ChrisADR> but this was a tiny caveat in the process, if one/multi user access via htpasswd file +[15:25:40] <ChrisADR> I'll have to clean the code a bit to ensure that we use the test bugzilla but besides that, everything should work ok +[15:26:06] <Whissi> Are we talking about who have access to that environment (i.e. plain Ruby files) or just the user who can access the frontend? +[15:26:19] <ChrisADR> user who can access the frontend +[15:26:19] <K_F> frontend +[15:26:28] <Whissi> Frontend can be a single shared user, right. +[15:26:48] <ChrisADR> yea, the infra side will remain in infra hands +[15:27:05] <ChrisADR> they'll "automate" upon requets to ease development cycles +[15:27:31] <Whissi> Can happen via git branches and pushes/tags, yes. +[15:27:31] <ChrisADR> which most likely implies, automate deploy process once the changes are pushed to the dev branch +[15:27:43] <ChrisADR> yep :) +[15:28:19] <ChrisADR> but wanted to ask you about the frontend user first, if you agree, then we are ready to build the env and start development :) +[15:28:58] <Whissi> OK. I agree. +[15:29:02] <ChrisADR> and if nobody else has something to discuss, I think we can finish the meeting :) +[15:29:50] <ChrisADR> 3...2...1... +[15:30:11] -*- ChrisADR bangs the gavel :) thank you all |