15:01:09 <gagehugo> #startmeeting security
15:01:09 <opendevmeet> 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 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:09 <opendevmeet> The meeting name has been set to 'security'
15:01:12 <gagehugo> o/
15:01:33 <fungi> ahoy!
15:01:37 <gagehugo> #link https://etherpad.opendev.org/p/security-agenda agenda
15:04:38 <gagehugo> #topic PTG recap
15:04:43 <gagehugo> #link https://etherpad.opendev.org/p/security-sig-ptg-yoga
15:04:47 <gagehugo> Notes from the PTG
15:07:52 <fungi> we didn't get around to talking through the list of repos did we?
15:08:28 <fungi> oh, right, i was having problems with my computer locking up
15:08:44 <gagehugo> yeah haha
15:08:50 <gagehugo> We can talk about it today though
15:08:56 <fungi> turns out it's something specific to the i915 kernel driver and intel internal video chipsets when running on battery
15:09:04 <gagehugo> hmm
15:09:40 <gagehugo> that is a bit specific
15:09:46 <fungi> 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 <fungi> 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 <fungi> once i thought back
15:10:45 <gagehugo> interesting
15:10:59 <fungi> anyway, not at all security related, just was a surprising discovery
15:11:31 <gagehugo> 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 <fungi> oh, yeah i've had that, though mostly just with fm radios
15:12:17 <gagehugo> heh
15:12:22 <gagehugo> #topic retiring git repos
15:12:32 <gagehugo> #link https://opendev.org/openstack/governance/src/commit/0f0b0ce7d99188447a1fabcbc3165c4305815066/reference/sigs-repos.yaml#L76-L80
15:13:28 <fungi> so looking through those, we definitely still use ossa
15:14:08 <fungi> i'm rather certain we can retire security-specs
15:14:56 <gagehugo> Do we still use security-analysis with the latest changes to the vulnerability:managed tagging?
15:15:44 <gagehugo> actually the only projects in that repo docs are barbican and KSM
15:15:47 <fungi> 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 <fungi> 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 <gagehugo> yeah
15:17:21 <gagehugo> we tried to get several of the keystone libraries covered in the past with the process before it all changed
15:18:33 <fungi> the other repo there is security-doc which does need some love but gets updates from time to time
15:18:56 <fungi> 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 <gagehugo> makes sense
15:19:11 <fungi> again, it may make more sense for security recommendations to go into project documentation anyway?
15:19:17 <fungi> that's worth bringing up on the ml probably
15:19:41 <gagehugo> sure
15:20:05 <gagehugo> instead of having it all over the place
15:23:41 <fungi> 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 <gagehugo> yeah, installations/configurations
15:24:07 <fungi> 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 <gagehugo> hah
15:24:30 <fungi> much better if openstack is secure by default, recommending secure options in the install docs
15:24:40 <gagehugo> but yeah it makes sense to just have that info in the same place
15:27:22 <fungi> 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 <fungi> 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 <gagehugo> I am fine with that
15:31:02 <fungi> 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 <gagehugo> yes
15:32:12 <fungi> 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 <gagehugo> That works
15:32:39 <fungi> security-specs we can clearly just retire, that doesn't need further discussion as far as i can see
15:32:51 <gagehugo> I can retire that repo then
15:34:38 <fungi> thanks!
15:34:53 <gagehugo> #topic open discussion
15:35:01 <gagehugo> I don't have anything else for this meeting
15:35:51 <fungi> 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 <gagehugo> oh nice!
15:36:45 <fungi> yeah, mainly just trying to make sure things don't fall through the cracks
15:37:23 <gagehugo> sounds good
15:37:32 <fungi> 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 <gagehugo> yeah, that's a good point
15:38:18 <fungi> 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 <gagehugo> yeah, that definitely helps move things along eventually
15:39:55 <fungi> 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 <fungi> #link https://oss-security.openwall.org/wiki/mailing-lists/distros
15:41:17 <fungi> 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 <fungi> s/provate/private/
15:42:16 <fungi> in particular, including "[vs]" in the subject, and encrypting the message body for the key included there
15:43:28 <fungi> 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 <gagehugo> oh ok
15:44:03 <gagehugo> "confirm that you indeed read this policy before successfully sending anything to us." haha
15:44:12 <fungi> exactly ;)
15:45:11 <gagehugo> hmm they give the key to use there
15:45:27 <fungi> yep
15:45:46 <gagehugo> yeah should update our process then
15:46:21 <fungi> 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 <gagehugo> yeah
15:47:48 <gagehugo> I need to hop on another meeting, thanks fungi!
15:47:53 <gagehugo> #endmeeting