| fungi | https://bugs.launchpad.net/neutron/+bug/2054590 is now public | 15:15 |
|---|---|---|
| SvenKieske | ah, finally :) | 16:39 |
| SvenKieske | mhm, I'm a little bit baffled it was private to begin with, parts of this circulated already in the scs community | 16:40 |
| SvenKieske | fungi: this was public as of this posting (meeting minutes): https://input.scs.community/2023-scs-team-iaas#Notice-about-a-potential-security-issue-josephineSei | 16:41 |
| fungi | SvenKieske: that would also have been good to know | 16:41 |
| SvenKieske | well, I/we redirected the reporting to you. I wondered if I should say something with regards of reporting this in public but didn't speak up. | 16:42 |
| fungi | luzi e-mailed me privately with her concerns but didn't mention that some of it had already been discussed publicly, so i advised her to start with a private security bug for neutron to get a few eyes on it | 16:42 |
| fungi | but yeah, if i'd known about prior public discussion i would have suggested just opening a public security bug about it | 16:43 |
| SvenKieske | yeah my bad I guess, as I think I was the one the most familiar with openstack security process. I silently hoped that it would be obvious (from the reporting side) that this is of course public once it enters public meeting minutes. | 16:43 |
| fungi | still, it only sat private for a few days before it got some attention | 16:43 |
| SvenKieske | yeah, not much harm done I guess. | 16:44 |
| SvenKieske | I'll circle back with our PO guys and some security guys if we maybe should write down our own policy on how to report security bugs upsteram | 16:45 |
| SvenKieske | upstream* | 16:45 |
| SvenKieske | I also didn't really interfere much, because I thought it might be debatable if a trust boundary is crossed/this really is viewed as a security issue. | 16:46 |
| fungi | SvenKieske: if you think it would help, i could add something to https://security.openstack.org/#how-to-report-security-issues-to-openstack about circumstances for bringing already public items to the vmt's attention. so far we've tried to keep it brief in order to avoid unnecessary confusion | 16:48 |
| fungi | mmm, also i see a missed a variation of "responsible" there when i cleaned up all the others | 16:49 |
| SvenKieske | well on one hand it is good in theory to maybe add a note like "if the information you want to report is already public knowledge, e.g. described in another public bugtracker, please just open a public security bug" | 16:50 |
| SvenKieske | on the other hand this document is already rather long, so making it longer might have negative impact | 16:50 |
| fungi | the "how to report" section is fairly short, thankfully | 16:50 |
| SvenKieske | I would maybe move the whole section "reporting security issues" out of it into it's own document that can be prominently linked to from the website. possibly with a link to the more detailed informations for deployers and developers. | 16:51 |
| fungi | though i suppose it could also warrant a dedicated page like i did for https://zuul-ci.org/docs/zuul/latest/vulnerabilities.html | 16:51 |
| SvenKieske | yeah right, from the perspective of security researchers it's always good to have a dedicated document which is short imho | 16:52 |
| fungi | good call | 16:52 |
| SvenKieske | I notice we do not happen to have a "security.txt" on our website, what do you think about that? | 16:53 |
| SvenKieske | in case you are not familiar: https://securitytxt.org/ it has it's up- and downsides, as usual. :) | 16:53 |
| SvenKieske | ah nice, last time I looked it was not yet an actual RFC: https://www.rfc-editor.org/rfc/rfc9116 | 16:54 |
| opendevreview | Jeremy Stanley proposed openstack/ossa master: Clean up a couple missed "responsibly" mis-uses https://review.opendev.org/c/openstack/ossa/+/910371 | 16:54 |
| SvenKieske | a clear downside of a security.txt is, that you might get more spam/low quality reports, depending on your usage of the file | 16:55 |
| fungi | SvenKieske: that looks like a way for operators of a service or site to publish how people should report vulnerabilities for that service or site in a discoverable way, not for producers of open source software to direct vulnerability reports for their various projects. probably would make more sense to put a file in the top level of each git repository, or just mention it in every | 17:00 |
| fungi | readme | 17:00 |
| fungi | it's not clear to me where we would put an rfc 9116 security.txt file the way it's described | 17:01 |
| fungi | also keep in mind that the openstack community doesn't maintain the (www.)openstack.org web site | 17:02 |
| SvenKieske | yeah, that seems difficult :) | 17:02 |
| fungi | so any information published there would need to be coordinated with the third-party webdev contracting firm that maintains it on behalf of the openinfra foundation | 17:02 |
| opendevreview | Jeremy Stanley proposed openstack/ossa master: Move Reporting and VMT sections to dedicated pages https://review.opendev.org/c/openstack/ossa/+/910374 | 17:17 |
| fungi | SvenKieske: see if that ^ makes sense | 17:17 |
| fungi | i tried to retain the existing anchors so external referents still end up somewhere useful | 17:18 |
| fungi | https://e5f1af19c3b87103bfc3-8ce5690b0835baabd00baac02d43f418.ssl.cf2.rackcdn.com/910374/1/check/openstack-tox-docs/7c7e0b4/docs/ is the preview | 17:23 |
| fungi | there are probably some internal references that could still stand to be cleaned up, but it's a start anyway | 17:25 |
| SvenKieske | I'll take a look, thanks! | 17:29 |
| fungi | it's mainly just a forklift of those two sections into separate documents/pages | 17:29 |
| fungi | nothing reworded | 17:29 |
| fungi | minimum effort expended to make sure sphinx remained happy | 17:30 |
| SvenKieske | :) | 17:30 |
| SvenKieske | LGTm | 17:31 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!