| opendevreview | Merged openstack/ossa master: Update Jeremy Stanley OpenPGP key expiration https://review.opendev.org/c/openstack/ossa/+/871528 | 12:46 |
|---|---|---|
| opendevreview | Jeremy Stanley proposed openstack/ossa master: Add OSSA-2023-002 (CVE-2022-47951) https://review.opendev.org/c/openstack/ossa/+/871635 | 15:14 |
| fungi | prometheanfire: d34dh0r53: ^ i'll revise that and un-wip as soon as we have all the review links | 15:14 |
| opendevreview | Jeremy Stanley proposed openstack/ossa master: Add OSSA-2023-002 (CVE-2022-47951) https://review.opendev.org/c/openstack/ossa/+/871635 | 15:28 |
| fungi | prometheanfire: d34dh0r53: ^ that revision has all the change links now | 15:29 |
| fungi | if someone's available for a quick double-check, we can approve asap and get it published so i can start sending copies to mailing lists | 15:29 |
| tobias-urdin | just a quick question, why is that public before new versions are available? | 15:30 |
| tobias-urdin | is embargo lifted already? | 15:30 |
| fungi | yes, the embargo was scheduled to end at 15:00 utc today | 15:30 |
| fungi | half an hour ago | 15:31 |
| fungi | the changes are all pushed to review for their respective projects now | 15:31 |
| fungi | and are in the process of being approved as we speak | 15:31 |
| tobias-urdin | ack, i see | 15:31 |
| fungi | it's not all instantaneous, for obvious reasons | 15:32 |
| fungi | especially for one like this that spans several projects and has over 20 patches for various branches | 15:32 |
| tobias-urdin | yeah it makes sense, I just thought that maybe patches was going to be silently merged and then OSSA public when new releases were available, but it's also hard to keep private I understand | 15:34 |
| tobias-urdin | silently as in: it's just random public patches, but would probably raise suspicion anyway | 15:34 |
| fungi | right, no we don't do that. we try to be as transparent as possible about everything, but that does sometimes lead to delays. it's a trade-off | 15:36 |
| fungi | if i had my way, everything would just be zero-day public bug reports and projects would fix them with some urgency, but not everyone agrees with my viewpoint on that so we have a rather cumbersome process of coordinating/reviewing/testing fixes in private and trading around copies of patches to numerous organizations ahead of time | 15:39 |
| fungi | but at least we are able to switch it all to 100% public visibility once it's done | 15:39 |
| tobias-urdin | yea I agree with you, I just feel sorry for public clouds that doesn't restrict logins, literally get a admin account login and delete everything :( | 15:40 |
| fungi | yes, the ones who want can get copies of the patches ahead of time: https://security.openstack.org/vmt-process.html#downstream-stakeholders | 15:41 |
| fungi | under our present process at least | 15:41 |
| fungi | and many public cloud providers do have their security teams enrolled in that | 15:42 |
| fungi | the ossa passes testing and the preview build is here: https://c423e137b3a1318db26e-f5dac079145e2b681e216f4ad0aa8d74.ssl.cf1.rackcdn.com/871635/2/check/openstack-tox-docs/6fe22ab/docs/ossa/OSSA-2023-002.html | 15:45 |
| fungi | since it seems like other vmt members aren't around at the moment, i'll go ahead and self-approve it | 15:45 |
| fungi | hoping it will be live on security.o.o and i'll be able to send copies to mailing lists by the top of the hour | 15:47 |
| fungi | if there are any errors, we can always revise and distribute errata afterward | 15:47 |
| opendevreview | Merged openstack/ossa master: Add OSSA-2023-002 (CVE-2022-47951) https://review.opendev.org/c/openstack/ossa/+/871635 | 15:51 |
| tobias-urdin | fungi: what the requirements for being added to the downstream list? | 16:02 |
| fungi | tobias-urdin: "distributions, products, private and public service offerings that are negatively affected by vulnerabilities" and "you should definitely be included on that email distribution list" | 16:03 |
| fungi | basically public clouds running openstack and distributors of openstack software, but we've also added representatives from community teams like the deployment projects and the central stable branch maintainers in the past | 16:06 |
| tobias-urdin | fungi: ack, where can I apply? :) I'd like us to be on that list | 16:48 |
| fungi | tobias-urdin: per https://security.openstack.org/vmt-process.html#downstream-stakeholders just send me an e-mail explaining why you want it, and i'll confer with the other vmt members | 16:52 |
| tobias-urdin | fungi: ack, thanks! | 16:53 |
| SvenKieske | hey there, regarding the wording for the fixes for CVE-2022-47951 I had some comments, because it is imho not strong enough, I did post it in code review here: https://review.opendev.org/c/openstack/glance/+/871613 but I noticed the same text appears in the fixes in the other projects as well. | 18:02 |
| SvenKieske | so I figured I maybe should ask here if this wording was somehow coordinated and if it maybe could get adjusted to nudge users into not enabling potential security vulnerabilities, by making it clear that this is what they do if the activate certain options. | 18:04 |
| fungi | SvenKieske: you probably want to take that up with dansmith and abhishekk in #openstack-glance | 18:05 |
| fungi | they were responsible for the wording choices in the help string | 18:06 |
| SvenKieske | fungi: thanks for the pointer :) | 18:06 |
| fungi | but yes, the wording included in there was also in the patches provided to downstream stakeholders (linux distros, cloud providers, et cetera) a week ago | 18:07 |
| fungi | so generally we try to avoid making unnecessary alterations to those changes and prefer to update help messages as a separate change (which could also be backported if the reviewers agree) | 18:08 |
| SvenKieske | ah, so maybe that ship has sailed already? I'm a little confused as to the state of these patches, as none of them are merged yet, but downstream already has them for a week? the woes of responsible disclosure, I guess.. | 18:08 |
| fungi | yes, i got a little ranty about it earlier today before you joined the channel: https://meetings.opendev.org/irclogs/%23openstack-security/%23openstack-security.2023-01-24.log.html | 18:10 |
| SvenKieske | anyway, don't want to make your work harder than it already is, will wait for tomorrow and then maybe propose alternative wording as a followup patch, if there is interest | 18:10 |
| SvenKieske | fungi: thanks for the log :D I like your stance on the security side of things btw, also the transparency is greatly appreciated :) | 18:12 |
| fungi | it's definitely a matter of balancing various trade-offs | 18:13 |
| fungi | i gave a talk about it at oscon a while back... 2015? | 18:13 |
| fungi | doing embargoed vulnerability management in an otherwise 100% public open source project is not without its challenges | 18:13 |
| SvenKieske | sure, I'm still waiting for some small vendor to sue the large vendors who get an unfair competetive advantage by getting to the patches earlier :D at least under german law that should be easily possible, but IANAL :D | 18:14 |
| fungi | we don't discriminate based on how big the organization is, we just want to be able to vet them somehow | 18:15 |
| fungi | we also keep the advance notification window as short as we reasonably can, in order to minimize the damage from an early leak during that time | 18:15 |
| SvenKieske | fungi: sure, that comment was more pointed at linux-distros Lists et al. | 18:15 |
| SvenKieske | the downstream stakeholders link is interesting, will chat with my org if we would like to be included there, what would it take? I presume some ability to receive gpg encrypted mail? | 18:16 |
| fungi | because of the inherent challenges and seeming contradiction to how we normally design and develop the software, we try to reserve the embargo process for only the most serious vulnerabilities and push to handle less severe risks through a more public process | 18:17 |
| fungi | SvenKieske: we don't even encrypt the mail to that list, we just ask the organizations to be cautious with the information and patches | 18:17 |
| SvenKieske | we are just a small/mid sized semi-public cloud provider, fortunately most APIs are not exposed directly to external customers. | 18:17 |
| fungi | you'd be surprised how many struggle to agree on a single encrypted messaging solution | 18:18 |
| SvenKieske | oh okay, well if the transport channels are encrypted that might be fine, if it's only for a few days | 18:18 |
| fungi | yes, we limit the period to 3-5 business days | 18:18 |
| fungi | also as a matter of policy we won't keep a vulnerability report private for more than 90 days even if it can't be fixed in that timeframe | 18:19 |
| SvenKieske | good to know and even better to do | 18:20 |
| SvenKieske | okay I guess I'm heading out of office, be there vulns or not, so: have a nice evening, or whatever applies to your timezone :D | 18:21 |
| fungi | yes, before enacting that policy we had some reports sit rotting in private for years and years because there was no consensus on severity or approach, and no sense of urgency when it can remain private indefinitely | 18:21 |
| fungi | thanks SvenKieske, you too! | 18:21 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!