| opendevreview | Jeremy Stanley proposed openstack/ossa master: Add OSSA-2026-035 https://review.opendev.org/c/openstack/ossa/+/1000875 | 16:59 |
|---|---|---|
| fungi | gouthamr: JayF: rosmaita: ^ (public workflow advisory) | 17:00 |
| * gouthamr looks | 17:05 | |
| rosmaita | fungi: lgtm | 17:11 |
| gouthamr | fungi: asked a question | 17:13 |
| gouthamr | can turnaround with a quick +2 if you see | 17:13 |
| fungi | gouthamr: i'm missing sufficient context to understand the rather terse question you asked there | 17:15 |
| rosmaita | pretty sure it's the QOS policy that can't be deleted (based on the LP bug description) | 17:16 |
| gouthamr | sorry, maybe it was my misunderstanding of the bug | 17:16 |
| rosmaita | but i don't know a lot about octavia | 17:16 |
| JayF | my read on it == rosmaita | 17:16 |
| fungi | yes, if you're asking what it prevents deletion of, it's that the owner of the qos policy can't delete it once it's associated with someone else's amphora | 17:16 |
| gouthamr | my bad then, yes | 17:17 |
| JayF | attacker creates an amphora, attaches the victim's qos policy, victim can never delete policy until attacker unattaches | 17:17 |
| fungi | (or the operator unattaches it for them) | 17:17 |
| gouthamr | ack; noted that clarification and approved | 17:18 |
| gouthamr | ty! | 17:18 |
| fungi | to be fair, i was on the fence about whether this needed an advisory at all. the way i would see it playing out in a public cloud is that someone discovers they can't delete their qos policy, they file a trouble ticket, an operator looks into it and fixes the invalid association, problem solved | 17:19 |
| fungi | the main impact is that it wastes operators' time until they realize that it's a malicious behavior and revokes the attacker's account | 17:19 |
| opendevreview | Merged openstack/ossa master: Add OSSA-2026-035 https://review.opendev.org/c/openstack/ossa/+/1000875 | 17:21 |
| gouthamr | but that's the way it is framed | 17:21 |
| gouthamr | beyond such a nuisance, a different tenant shouldn't be able to use a qos policy meant for someone else | 17:21 |
| fungi | as for temporarily including cve request ids in advisory notes, that allows an interested third party to nudge mitre on our behalf if they get tired of not having a cve assignment, because i personally find myself having a hard time caring about cve identifiers most of the time | 17:22 |
| gouthamr | i didn't see anything about not sharing request IDs | 17:23 |
| JayF | I've been putting the CAN IDs in the bugs | 17:23 |
| fungi | well you mentioned can ids, which i guess is what the new form gives you instead of a request id | 17:23 |
| JayF | unless someone feels strongly, I'm not changing that behavior | 17:23 |
| gouthamr | that's not public advisory JayF | 17:23 |
| gouthamr | "This reaches the CNA-LR team, who will review as soon as possible. In the meantime, please do not use the CAN number as a public vulnerability ID." | 17:23 |
| gouthamr | ^ and i think i saw something remind me about this somewhere else | 17:24 |
| JayF | Yeah, we don't use it as an ID, but we do make them public | 17:24 |
| JayF | when the bugs are opened post-embargo | 17:24 |
| gouthamr | yes | 17:24 |
| fungi | yeah, we don't use it as a vulnerability id, we use it as a tracking reference | 17:24 |
| fungi | we say "we requested a cve id and don't have one yet, the request was made on x date and this was the tracking number for the request" basically | 17:24 |
| fungi | because we don't have time to follow up pestering mitre to process the request, but maybe someone else does | 17:25 |
| fungi | the main annoyance is that launchpad seems to scrape can ids from bug comments and then automatically attach them as cves | 17:26 |
| fungi | even though they're not cves at all | 17:26 |
| JayF | yeah, I usually remove them | 17:27 |
| gouthamr | i'm unable to track whatever i read, maybe i'll find it later when i'm not actively looking :D | 17:27 |
| JayF | with the button | 17:27 |
| fungi | maybe if we don't quote them in can format it would be avoided | 17:27 |
| gouthamr | put a space in it or something to beat their logic | 17:27 |
| fungi | "the request has a CAN ID of NNNNNN" | 17:28 |
| JayF | at some point I'd rather leave the text in proper formats for humans who come later rather than catering to the over-excitable platform :D | 17:29 |
| JayF | pressing an additional button to remove the invalid one in LP... how long could it take? lolsob | 17:29 |
| gouthamr | yeah, technically i think LP is at fault here.. and maybe they'll take a patch.. we shouldn't be the only ones running into this | 17:29 |
| JayF | I'm sure this would ZOOM to the top of their backlog /s :D | 17:30 |
| JayF | #2 behind the task of "fix the entire internet since AI-bots are breaking it" | 17:30 |
| gouthamr | i'll try "hear me, i'm important" | 17:30 |
| fungi | "don't you know who i think i am?!?" | 17:31 |
| * gouthamr pictures an intense FOSS drama on broadway | 17:31 | |
| fungi | hah, i just realized i put the wrong date in the note, the cve request was made on 2026-07-27, oh well | 17:49 |
| fungi | not all that important to correct | 17:49 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: OSSN-0107: IPA Container HWM Security Misimplmented https://review.opendev.org/c/openstack/security-doc/+/1000784 | 19:54 |
| JayF | fungi: gouthamr: rosmaita: ^ I would like to release this advisory today; it's been revised for Ironic comments. | 19:55 |
| * gouthamr is looking | 19:57 | |
| opendevreview | Merged openstack/security-doc master: OSSN-0107: IPA Container HWM Security Misimplmented https://review.opendev.org/c/openstack/security-doc/+/1000784 | 20:32 |
| fungi | sorry, stepped out for food, but lgtm | 20:56 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!