15:01:09 #startmeeting security 15:01:09 Meeting started Thu Nov 4 15:01:09 2021 UTC and is due to finish in 60 minutes. The chair is gagehugo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:09 The meeting name has been set to 'security' 15:01:12 o/ 15:01:33 ahoy! 15:01:37 #link https://etherpad.opendev.org/p/security-agenda agenda 15:04:38 #topic PTG recap 15:04:43 #link https://etherpad.opendev.org/p/security-sig-ptg-yoga 15:04:47 Notes from the PTG 15:07:52 we didn't get around to talking through the list of repos did we? 15:08:28 oh, right, i was having problems with my computer locking up 15:08:44 yeah haha 15:08:50 We can talk about it today though 15:08:56 turns out it's something specific to the i915 kernel driver and intel internal video chipsets when running on battery 15:09:04 hmm 15:09:40 that is a bit specific 15:09:46 i was trying to run on battery because the usb headset i've got has really poor electrical isolation and the mic picks up a 60hz hum whenever i plug in a type-c charger 15:10:11 yeah, someone reported a similar problem to debian-devel later that week and i realized it was only happening when i was on battery 15:10:24 once i thought back 15:10:45 interesting 15:10:59 anyway, not at all security related, just was a surprising discovery 15:11:31 My previous DAC on my desktop liked to pickup some noise whenever someone texted me and my phone was nearby on the desk 15:12:12 oh, yeah i've had that, though mostly just with fm radios 15:12:17 heh 15:12:22 #topic retiring git repos 15:12:32 #link https://opendev.org/openstack/governance/src/commit/0f0b0ce7d99188447a1fabcbc3165c4305815066/reference/sigs-repos.yaml#L76-L80 15:13:28 so looking through those, we definitely still use ossa 15:14:08 i'm rather certain we can retire security-specs 15:14:56 Do we still use security-analysis with the latest changes to the vulnerability:managed tagging? 15:15:44 actually the only projects in that repo docs are barbican and KSM 15:15:47 we recommend that projects undergo a security analysis, but honestly i've always felt that having it in a separate repository makes little sense, it would be more useful for those to exist in the project docs 15:16:43 it was in its own repo originally because we recommended that the projects seek out independent reviews of their analyses, but that was all based around the ossg acting as reviewers for them 15:16:54 yeah 15:17:21 we tried to get several of the keystone libraries covered in the past with the process before it all changed 15:18:33 the other repo there is security-doc which does need some love but gets updates from time to time 15:18:56 though with no tech writing sig any longer, it will most likely be on us to do any reviewing there if we keep it 15:19:06 makes sense 15:19:11 again, it may make more sense for security recommendations to go into project documentation anyway? 15:19:17 that's worth bringing up on the ml probably 15:19:41 sure 15:20:05 instead of having it all over the place 15:23:41 well, it's more that project install docs are most likely how people are finding out how to do installations (or they're using a canned installer/distro) 15:23:58 yeah, installations/configurations 15:24:07 and we're expecting them to go to some separate document if they're one of those weird people who actually wants a secure deployment 15:24:17 hah 15:24:30 much better if openstack is secure by default, recommending secure options in the install docs 15:24:40 but yeah it makes sense to just have that info in the same place 15:27:22 as for repos reporting into this channel with gerritbot, looks like it's the same 4 as in the sigs-repos list for us 15:29:43 so the idea is to retire security-specs (it hasn't had a spec change in 6 years), propose moving security-analysis and security-doc into project docs, keep ossa 15:30:45 I am fine with that 15:31:02 moving security-analysis and security-doc *content* into project docs, i mean, and then retire them (keeping the old versions published i guess for the sake of old hyperlinks) 15:31:31 yes 15:32:12 okay, i can start an ml thread about security-analysis and security-doc i suppose, unless you're keen to take that 15:32:34 That works 15:32:39 security-specs we can clearly just retire, that doesn't need further discussion as far as i can see 15:32:51 I can retire that repo then 15:34:38 thanks! 15:34:53 #topic open discussion 15:35:01 I don't have anything else for this meeting 15:35:51 it's not visible work, but i've been following up with ptls and security liaisons on old private bugs for deliverables the vmt doesn't officially oversee, trying to get them cleaned up where possible 15:36:25 oh nice! 15:36:45 yeah, mainly just trying to make sure things don't fall through the cracks 15:37:23 sounds good 15:37:32 i'm okay with public security reports falling stale, someone can always find them and decide to work on them, but the private ones are at risk of rotting without ever seeing the light of day 15:37:44 yeah, that's a good point 15:38:18 for vmt-overseen deliverables that's not a problem these days because we have a maximum embargo period those projects have agreed to 15:39:38 yeah, that definitely helps move things along eventually 15:39:55 oh, before i forget, i also discovered recently that there's an update we should probably make to our embargoed disclosure process 15:40:35 #link https://oss-security.openwall.org/wiki/mailing-lists/distros 15:41:17 under the "List policy and instructions for reporters" section there are a couple of things we haven't been doing when sending to the provate linux-distros ml as a downstream stakeholder 15:41:27 s/provate/private/ 15:42:16 in particular, including "[vs]" in the subject, and encrypting the message body for the key included there 15:43:28 it dawned on me recently when i got a reply from one of the volunteers to linux-distros, which was encrypted to my openpgp key, that they probably expected me to encrypt when sending to the ml as well, so i went out looking for their list guidelines, something i should probably have read years ago 15:43:45 oh ok 15:44:03 "confirm that you indeed read this policy before successfully sending anything to us." haha 15:44:12 exactly ;) 15:45:11 hmm they give the key to use there 15:45:27 yep 15:45:46 yeah should update our process then 15:46:21 it doesn't come up often because we do embargoed disclosures only rarely, but it would still be best to follow their recommendations when notifying them 15:46:38 yeah 15:47:48 I need to hop on another meeting, thanks fungi! 15:47:53 #endmeeting