19:05:22 #startmeeting storyboard 19:05:23 Meeting started Wed Dec 6 19:05:22 2017 UTC and is due to finish in 60 minutes. The chair is SotK. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:05:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:05:27 The meeting name has been set to 'storyboard' 19:06:15 #link https://wiki.openstack.org/wiki/Meetings/StoryBoard Agenda 19:06:47 I expect today will be fairly quick 19:06:59 #topic In Progress Work 19:07:34 so, the email bug got sorted out, thanks fungi! 19:07:40 "bug" 19:07:49 haha 19:08:39 in other news, I addressed Zara's comments on https://review.openstack.org/#/c/511246/ so that we can unblock those 19:08:43 #link https://review.openstack.org/#/c/511246/ 19:08:57 #link https://review.openstack.org/#/c/511247/ 19:09:23 neat, thanks! 19:09:44 (sorry I'm late, my food was ready) 19:10:11 np :) 19:11:15 heyhey 19:11:31 welcome fungi 19:12:56 only thing i had (aside from noting that storyboard.o.o is now exempted frmo the spamhaus policy blocklist entry rackspace blankets their ipv4 allocations with), is that kolla-kubernetes bugs have been migrated today 19:13:19 nice! 19:13:23 how did that go? 19:13:39 fine, import was probably around 20-30 minutes to complete 19:13:50 i wasn't timing it, but should have done 19:14:11 sounds good 19:14:23 20-30 mins sounds specific enough for us tbh 19:15:14 indeed 19:15:25 discussion on the migration goal proposal is also coming along 19:16:06 so I see 19:16:15 I had a skim of it but not yet a proper read 19:16:24 #link https://review.openstack.org/#/c/513875/ 19:16:54 thanks, gertty was taking too long to pull it up for me so i could grab the link 19:17:46 I've also been lurking 19:18:03 since I think anything I write would read as 'storyboard storyboard storyboard' anyway 19:18:05 i think most of the concerns have been assuaged at this point other than where it would be nice to have a smoother experience on private story reporting and the need to generally just get some more projects migrated before we set it as a goal 19:19:04 they seem like fair concerns 19:19:24 kmalloc mentioned earlier this week that the discussion around migrating had come up in #openstack-keystone and they're concerned about the private story situation getting resolved before considering it 19:19:50 being one of the more security-critical projects we have 19:19:59 I think we had a plan on how to solve the private story reporting somewhere in our meeting logs, idk if it ever got written up into a story 19:20:16 * SotK will confirm he isn't going mad and do so later 19:20:36 that would be awesome if you get a chance 19:21:00 I'm about 70% certain it did 19:21:25 i didn't have anything else. dunno whether diablo_rojo_phon has anything to add from kubecon, but she's probably otherwise occupied there at the moment 19:23:14 (istr it involved having a specific tag and then notifying teams subscribed to the tag, all I can find atm is: https://storyboard.openstack.org/#!/story/2000568) 19:23:33 where the tag wasn't a freeform thing so that people would definitely get the right one 19:23:48 applied via a checkbox? 19:23:51 Zara: that sounds similar to my memory 19:23:52 ahh, so overloading story tags for auto access? 19:25:10 I don't remember if it was using actual tags or setting a "vulnerability" flag on the story 19:25:13 I'm not *certain* if it was a tag or if we were going to add a field in the db 19:25:20 yeah I think we might've settled on db in the end 19:25:25 to me the critical bit to solve is having some logic for granting private story access to specific accounts or, preferably, predefined groups of accounts 19:25:50 I think that was fairly straightforward (just hooking up 'teams' to view permissions) 19:25:55 and the tricky bit was on the reporting side 19:26:07 because we needed people to consistently make them private 19:26:26 right, seems like that piece is probably solvable in the webclient 19:26:28 so eg: they couldn't write 'private' themselves as a tag because they might write 'prrrivate' or something 19:26:48 there's already a "private" checkbox when reporting a new story 19:27:04 aha, found the discussion 19:27:07 #link http://eavesdrop.openstack.org/meetings/storyboard/2017/storyboard.2017-03-08-19.00.log.html#l-94 19:27:11 thanks 19:27:49 my ideal future would be having a reporting url which defaults the private setting true for a new story and hides it 19:28:16 and then we can just use that url in our reporting suspected vulnerabilities workflow documentation 19:29:01 that sounds like a good idea, and ties in with the need from other docs folks to link to a partially filled story creation thing 19:29:42 agreed, fairly similar 19:29:54 just involving a different field 19:30:13 yep 19:30:34 so what's the situation with "teams" in sb right now? is that still theoretical/roadmap or is it implemented? partly implemented? anything there at all yet? 19:31:03 teams are pretty much complete in storyboard 19:31:12 they can be created and edited by admins iirc 19:31:19 we've had them in storyboard-dev for a while 19:31:22 and can be added to the permission list for stories 19:31:25 if you want to poke around there 19:31:48 and can access be granted to a team for a private story yet, or is that still just supportnig individual accounts? 19:31:56 hah, you answered that already 19:31:58 thanks 19:32:03 :) 19:32:23 you can't add teams to boards/worklists permissions yet though 19:32:48 there's a really old half finished patch for that somewhere that is fairly high on my todo list to revisit 19:33:03 i can see people being interested in access controls for boards and worklists, but for now i'm mostly just concerned with the private story situation since vmt needs are seen a s major migration blocker 19:33:22 makes sense 19:33:33 that's excellent news though 19:33:36 yeah, I think the roadmap side is fairly clear at least and we're mainly struggling for time. 19:33:43 to actually do the things 19:33:43 closer to solved than i realized even 19:34:02 I think the main missing piece there is that currently the bug reporter has to manually remember to add the VMT (if someone were to make such a team in sb) to their story 19:34:25 that's it, because private =! sec vulnerability 19:34:31 it might sometimes or it might not 19:34:36 yeah, i expect that's something which could also be done via the not-yet-defined custom reporting urls mechanism 19:35:09 which is how we ended up with needing a specific tag or other mechanism to report sec vuln, I remember now. 19:35:21 so the suspected vulnerability reporting url could set private true and add access for the vmt 19:35:30 Zara: yep 19:36:21 fungi: indeed, though I feel like we'd still need some mechanism for it in storyboard itself to catch folk who don't follow that link 19:36:33 i can certainly see having bolt-on automation autoadd vmt access to private stories with a "security" tag on them, as a workaround 19:38:30 #action SotK to add detail to the private stories story 19:38:41 anything else? 19:38:57 as for the "making sure private stories don't slip through the cracks" problem, the solution launchpad adopted was to have the ability to set a team (on a per-project basis) which automatically has access to any private bug reports 19:39:42 so teams could set that as the vmt or as their own team-specific core security reviewers team, whoever is expected to triage those 19:40:09 s/team-specific/project-specific/ 19:40:55 not sure how something like that would align with the current data model around teams and permissions in sb 19:41:13 and no, nothing else from me this week 19:42:34 that's certainly something to consider, my only immediate concern is of it being a stepping stone to adding full permissions for projects and so on 19:43:00 which is something we've deliberately avoided so far 19:43:49 agreed, makes sense to avoid 19:45:25 wonder if it would make sense to have an option to prevent adding a private story without selecting at least one team to grant access for 19:46:08 so that a naive reporter couldn't accidentally create a story only they could see 19:47:11 yeah, that could make sense I guess, though it could be limiting if someone deliberately wanted to create a private story visible to only them and certain other people for whatever reason 19:47:34 * SotK doesn't really see there being much benefit in doing that, but I guess some follk might 19:48:14 well, the certain other people part is probably solvable if you just require that the reporter add at least one team or an account who isn't them 19:48:45 and sure, it seems like it could be a global setting to turn that behavior on/off for a deployment 19:49:35 yeah, I think I'd prefer "at least one team or other person", or make it fully configurable 19:50:40 makes sense 19:52:13 * SotK will leave the meeting open for a couple of minutes in case anyone has anything further to discuss 19:54:56 thanks for attending folk! 19:54:59 #endmeeting