15:00:19 <gagehugo> #startmeeting security
15:00:20 <openstack> Meeting started Thu Feb 13 15:00:19 2020 UTC and is due to finish in 60 minutes.  The chair is gagehugo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:24 <openstack> The meeting name has been set to 'security'
15:00:32 <gagehugo> o/
15:00:47 <gagehugo> #link https://etherpad.openstack.org/p/security-agenda agenda
15:00:48 <redrobot> \o
15:03:22 * fungi is here, just fiddling agenda
15:05:04 <gagehugo> #topic YVR event attendance poll
15:05:20 <gagehugo> It's that time, before the summit/ptg/event
15:05:38 <gagehugo> We're supposed to gather attendence info and ask for a room if we need
15:06:11 <gagehugo> redrobot fungi: either of you plan on attending the Vancouver PTG?
15:06:28 <redrobot> No plans yet.  Gotta talk to the boss here pretty soon.
15:06:29 <gagehugo> I know it's a bit early
15:06:34 <gagehugo> yeah same haha
15:06:57 <redrobot> I gotta do the same for the Barbican team too, haha
15:06:57 <fungi> i'll be there, spread thin as usual, but if there are security-related activities which folks think will be easier to get done in a face-to-face setting then i'm happy to join
15:08:11 <gagehugo> I'll send out an email to see if we can gauge any interest
15:08:42 <gagehugo> could probably get a small session slot if possible
15:10:28 <gagehugo> #topic rainstorm post-678426 tasks
15:10:42 <gagehugo> #link https://etherpad.openstack.org/p/post-678426-tasks etherpad
15:10:54 <fungi> the long-awaited merging of the vulnerability management policy updates finally happened
15:11:07 <fungi> so now we need to do some actual work ;)
15:11:15 <gagehugo> oh boy
15:11:25 <fungi> i was just wanting to spend a few minutes figuring out what we think needs to happen next
15:11:31 * redrobot hides at the mention of work
15:11:49 <gagehugo> probably go through the big OS projects and unhide all those private security bugs
15:12:03 <fungi> for one, we should update the embargoed report template we include at the top of private security bugs to mention the embargo expiration timeframe
15:12:41 <fungi> we should also yes go through all existing private bugs and add a comment saying that we now have a maximum embargo time
15:13:02 <fungi> i think we start the countdown when we add that comment on them though, to give folks at least some time to prepare
15:13:12 <gagehugo> sure
15:14:15 <fungi> and i guess we need an announcement to the openstack-discuss ml about this change taking effect
15:15:15 <gagehugo> definitely
15:15:43 <fungi> also we should update our vmt process document to mention noting the expiration date for the embargo when we triage a new report
15:16:01 <fungi> and mention the 90-day max embargo period in the reporting guidelines on the security site as well
15:16:37 <fungi> i'll jot these down in the etherpad, but can anybody think of anything else directly related to this change which we need to do now that it's approved?
15:17:41 <gagehugo> those sound fine, do we want to give notice on current private security bugs now that we will make them public in X days?
15:17:59 <gagehugo> or are we just going to make them public after announcing via mailing list and updating docs/guides?
15:18:52 <fungi> i was thinking we do it in this order:
15:19:00 <fungi> 1. update our site/docs/templates
15:19:09 <fungi> 2. send announcement to the ml
15:19:24 <fungi> 3. add a 90-day warning to all currently private reports
15:19:50 <gagehugo> ok
15:19:52 <fungi> 4. switch those reports to public security after the 90 days
15:20:41 <fungi> for new incoming reports we'll comment setting the expiration to 90 days from when we triage it and subscribe project reviewers
15:20:43 <gagehugo> Is there a way to set that automatically in launchpad?
15:21:03 <gagehugo> like how it marks "expired" if there's no activity after 60 days?
15:21:11 <fungi> no way i know of, but it shouldn't be hard to calculate
15:21:28 <fungi> i usually just set myself reminders if i've proposed to make a bug public on a certain date
15:21:59 <fungi> it's not critical if it slips a few days, more that we set the expectation that we won't keep reports private indefinitely even if nobody gets around to working out a fix
15:22:35 <fungi> th vmt can still extend the deadline in extreme circumstances, like a fix is nearly complete or something
15:23:11 <fungi> i left us the "except under unusual circumstances" loophole in the policy
15:24:01 <fungi> if anybody disagrees with any of the tasks or proposed order, i'm happy to revisit the plan
15:24:26 <fungi> and also willing to do the bulk of the work on it as long as i know we're basically in agreement on what needs doing
15:25:29 <gagehugo> ok
15:27:37 <fungi> as an aside, here's a way from the command line you can calculate "90 days from today": date -d@$[$(date +%s)+7776000] -I
15:27:58 <gagehugo> nice
15:27:59 <fungi> (if your shell is bash anyway, otherwise you might need an echo and |bc or something)
15:29:03 <fungi> oh, hah, i should have remembered there's a much easier way: date -d90days -I
15:29:22 * fungi sighs at how he always overcomplicates things
15:29:28 <gagehugo> haha
15:30:09 <fungi> but yeah, i'll mention that in the process doc
15:30:31 <fungi> as for auto-expiring private status, i think we want human oversight anyway
15:30:45 <fungi> so i'd be uneasy just having it automatically switch to public
15:30:54 <gagehugo> probably, I just like offloading responsibilities to robots
15:31:31 <fungi> mostly due to the "extreme circumstances" clause, if we decide it needs more time we'd have to catch the expiration early and disable it, and hope we did that right
15:32:06 <fungi> s/disable/adjust/ or whatever
15:32:25 <fungi> but also i don't think either lp nor sb have a mechanism for auto-changing bug types on a schedule
15:32:48 <fungi> so it's probably a moot point
15:33:10 <gagehugo> might just be status then
15:34:05 <fungi> anyway, unless anyone has other suggestions, or wants to volunteer to pick up some of those tasks, i'm done with this topic for now
15:37:57 <gagehugo> I can send off the email, is that something we want to do today then?
15:38:22 <fungi> per the above sequence, i think the announcement should wait until we get official documentation updated
15:38:32 <fungi> just so we're not pointing folks to outdated info
15:39:11 <fungi> and then the bug updates can refer to the ml announcement too if we continue with the ordering i suggested
15:39:35 <gagehugo> sure
15:41:11 <fungi> i've adjusted the order in the pad to match
15:41:49 <fungi> i'll push up a change for the first step later today, hopefully so folks can review
15:42:06 <fungi> gerritbot should announce it in #openstack-security
15:42:31 <fungi> but i can nick highlight folks in there as well if anyone wants me to
15:46:11 <gagehugo> ok
15:48:25 <gagehugo> #topic open discussion
15:48:35 <gagehugo> fungi redrobot: anything else for today?
15:48:56 <fungi> nothing too exciting in the security ml archives
15:49:27 <fungi> bug 1841933 got a fix merged to master
15:49:29 <openstack> bug 1841933 in OpenStack Compute (nova) "Fetching metadata via LB may result with wrong instance data" [Undecided,Fix released] https://launchpad.net/bugs/1841933 - Assigned to Kobi Samoray (ksamoray)
15:50:23 <fungi> the fix for bug 1668410 got updated in an ubuntu sru
15:50:25 <openstack> bug 1668410 in neutron (Ubuntu Xenial) "[SRU] Infinite loop trying to delete deleted HA router" [High,Fix released] https://launchpad.net/bugs/1668410
15:50:31 <redrobot> nothing on my end
15:50:46 <fungi> and bug 1666959 got marked won't-fix by the neutron team
15:50:46 <openstack> bug 1666959 in OpenStack Security Advisory "ha_vrrp_auth_type defaults to PASS which is insecure" [Undecided,Won't fix] https://launchpad.net/bugs/1666959
15:51:39 <gagehugo> hmm I see
15:53:22 <fungi> nothing else to cover this week as far as i know
15:55:24 <gagehugo> fungi redrobot: thanks!  Have a good rest of the week
15:55:29 <gagehugo> #endmeeting