| cardoe | gouthamr: I'd like to bring up https://review.opendev.org/c/openstack/keystone/+/979789 and https://review.opendev.org/c/openstack/keystone/+/975342 these are the cause a reproducible crasher in keystone. I can denial of service keystone by just running skyline configured with federation. I've been asking to bring these up at meetings and IRC but there's been 0 traction. | 01:17 |
|---|---|---|
| cardoe | For next week | 01:17 |
| cardoe | https://bugs.launchpad.net/keystone/+bug/2139467 it's been a reported crasher for 7 months | 01:21 |
| cardoe | Just seems bad to ignore. | 01:21 |
| gouthamr | cardoe: ack, we might overload the agenda at this point though.. can we chat here? Artem and Dave Wilde are both afk for a bit - holidays.. but xek and dmendiza[m] should be around and can help figure out this specific issue | 06:41 |
| gouthamr | have you asked in a keystone meeting? | 06:42 |
| gouthamr | tbf, xek is struggling to get reviews on fixes for OSSA-2026-037 | 06:42 |
| gouthamr | 2/4 active reviewers are out, and one of them wrote/shepherded the fix, so, we're in a pickle.. i don't know if knikolla works on keystone anymore.. the last comment on gerrit from him was from Jan 2025 | 06:43 |
| gouthamr | https://review.opendev.org/admin/groups/keystone-core,members | 06:44 |
| opendevreview | Ivan Anfimov proposed openstack/governance master: Update Zun release/security liaisons https://review.opendev.org/c/openstack/governance/+/1002501 | 09:10 |
| cardoe | gouthamr: kinda makes my ML post relevant about culling inactive cores | 12:10 |
| cardoe | gouthamr: so I think the issue is more about a difference in opinion. some things can already be done and why federated users should be excluded from some operations | 13:19 |
| TheJulia | Interesting you bring up culling because I had a discussion recently where it was raised to me that a lack of actively doing so in a project creates an inherent security risk because its functionally a violation of the concept of least privilege when a user has lingering rights not actively being exercised. On the human side I think its easy just to grant rights back to people if they ask at some point down the road. | 13:19 |
| cardoe | I absolutely agree. That person is also less likely to notice if their credentials get hacked because they are not active in that space. | 13:22 |
| TheJulia | yup | 13:22 |
| fungi | yes, the presence of unused accounts in a privileged group makes them especially attractive targets of compromise since their owners aren't around to notice activity which isn't actually theirs and others may simply be fooled into thinking they've come back | 13:47 |
| cardoe | fungi: yep that's my concern | 14:25 |
| sean-k-mooney | for what its worth i am planing to simiarly triage the membership fo the cyrbog core team groups | 15:09 |
| sean-k-mooney | when doing this for watcher the intally approch we took was if you have not activly contibuted to the review or mantiance of any of the release corresponding to the current stable brnach then you were a candiate for removal | 15:11 |
| sean-k-mooney | i.e. if some one was last active in 2024.2 or older and has not done any review or other contibutions since then they woudl be condiered an inactive core | 15:12 |
| gouthamr | yeah some "automatic" revocation norms would actually help maintainers set the expectations without fear or favor | 15:12 |
| sean-k-mooney | revieiwing the membership is on my todo list after rc1 | 15:15 |
| JayF | cardoe: for the future, a reproducable DoS in Keystone is likely a security vulnerability. That issue should've gone through VMT process. | 15:16 |
| JayF | cardoe: and while I hate that the VMT ends up in this role, designating something a security issue and putting a deadline on it helps with prioritization | 15:16 |
| JayF | cardoe: I don't what this to be the openstack community, but it's the one we got | 15:16 |
| cardoe | Well I didn't realize you could DoS it at first. I thought it was just a functionality bug so I wrote a patch. | 15:17 |
| cardoe | Until someone clicked the button in a dev env with like 2 keystone workers running as rapidly as they could and other stuff was bad. | 15:17 |
| sean-k-mooney | i mean its not to late to treat it as a public security bug | 15:19 |
| sean-k-mooney | and if requried issue an adveisory | 15:19 |
| JayF | with it being a public bug now, I'll leave that to the general keystone contributor/community base | 15:20 |
| JayF | it's not likely to be a class a, which means OSSA (advisory) is unlikely, and OSSN (note) usually is a community choice | 15:20 |
| opendevreview | Merged openstack/security-doc master: Migrate OSSN txt files to build pipeline https://review.opendev.org/c/openstack/security-doc/+/1000155 | 15:22 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: Move OSSN process documentation into build https://review.opendev.org/c/openstack/security-doc/+/1002661 | 15:58 |
| frickler | sean-k-mooney: 2024.2 is pretty generous IMO, I was thinking to apply the same criteria as for AC status. that would even be quite easy to check automatically, just match the list in gerrit with the roll generated from the election tooling. likely the shouldn't be a hard "drop them all" list, but rather a "take a close look" one | 16:20 |
| sean-k-mooney | frickler: well my intial tinking ws if non of the branche that are under stable mantacnes are ones you have help maintian then your inactive | 16:22 |
| frickler | and if that check finds persons that the PTL or whoever checks this think still are active in some other way, that would also give a good motivation to add them as extra-ACs explicitly | 16:22 |
| sean-k-mooney | but that was more because fo not having any other better suggetion | 16:23 |
| frickler | sean-k-mooney: ah, so you were thinking fresh contributions to older stable branches? I'm not even sure whether the election tooling wouldn't consider those, need to check the code. or maybe fungi knows right away because he was dealing with the code recently? | 16:25 |
| sean-k-mooney | well if your a core but dont review on master but have been reviing backprot then that still somewhat active | 16:26 |
| sean-k-mooney | perhaps movign you to the stabel core group after a few release woudl refect reality better | 16:26 |
| sean-k-mooney | but its not a 0 impact | 16:26 |
| frickler | yes, I agree, I'm just not sure how the tooling handles this | 16:26 |
| sean-k-mooney | oh well we just looked in gerrit for reviews using before/after | 16:27 |
| sean-k-mooney | nothing fancy | 16:27 |
| sean-k-mooney | but we also tried to let folkd know a cycle in advance | 16:27 |
| sean-k-mooney | i.e. after rc1 we cleaned up really old memeber and said to the folkd that were effectivly inactive for 18 months that we woudl remvoe them at the end of the cycle if they were not active | 16:28 |
| frickler | otoh it would sound weird to me if someone actively said "I'll review only stable/2025.2 and older". it may happen by chance, yes, but why would someone actively decide for that? | 16:28 |
| sean-k-mooney | well elodilles mainly reviews older banches :) | 16:28 |
| sean-k-mooney | and nwere one but there are folks that due to there jobs or use of openstack care more about stabel branches then new features | 16:29 |
| sean-k-mooney | but i agree its the excpetion rather then the norm | 16:29 |
| frickler | yes, but all stable branches afaict, that would also stay within the "last two cycles" running windows | 16:29 |
| sean-k-mooney | yep the (once it becomes unmaintined/) guidline was kind of arbiarty whiel we were reviving the project | 16:30 |
| sean-k-mooney | as with cybrog i didnt want to just remvoe peopel as one fo the first things after being approinted to the core team | 16:31 |
| sean-k-mooney | for established and fucntionging teams i think refelctign on the memberhsip each cycle after rc1 is a good thing | 16:31 |
| sean-k-mooney | its after the electiosn and ff rush | 16:31 |
| fungi | frickler: the election tooling does include stable branch contributions just like the master/main branch, doesn't differentiate, though *in addition* you can tell it to generate a list of people involved specifically in stable branch work because that used to be how we determined the electorate and ptl candidates for the stable branch management team (which hasn't existed for | 16:37 |
| fungi | many years now but it's never been cleaned up in the tools) | 16:37 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: OSSN-0109: EC2-derived tokens retain full privileges https://review.opendev.org/c/openstack/security-doc/+/1002392 | 17:03 |
| frickler | fungi: thanks for confirming. just for completeness: are other branches like unmaintained, ironic bugfix or possible feature branches counted as well or are those excluded? | 17:07 |
| fungi | activity on all branches of official deliverables are aggregated to determine the electorate and ptl candidate qualification | 17:08 |
| fungi | including feature branches, backport branches, unmaintained branches, et cetera | 17:08 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: OSSN-0110: Self-service password change does not revoke generators https://review.opendev.org/c/openstack/security-doc/+/1002410 | 17:22 |
| fungi | frickler: put another way, what the election tooling queries is the owners of changes that merged to an official deliverable repository within a set timeframe (and now anyone who left a cr+2 or w+1 on those same changes), it doesn't look at branch information at all, just the repository for each change | 17:28 |
| fungi | this is also why the definition for atc/ac has basically always talked about cycles and not releases. it's not changes that went into particular releases but changes that merged in certain cycles | 17:29 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: Minor cleanups for OSSN-0004, OSSN-0097 https://review.opendev.org/c/openstack/security-doc/+/1002672 | 17:30 |
| fungi | even the contributors we thank on the release marketing pages are a list of all people who contributed during the cycle, not only people whose work directly landed in that final release | 17:31 |
| fungi | so if you only had a stable/2026.1 backport merge during the 2026.2 hibiscus cycle, you're still a hibiscus contributor from that perspective | 17:32 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: OSSN canonical URLs are in docs.openstack.org, now https://review.opendev.org/c/openstack/security-doc/+/1002673 | 17:34 |
| frickler | oh, interesting topic: that list still only includes "changes merged", but not "core reviews" or extra-acs? might be an opportunity to make at least 10 extra people happy if I remember the number correctly | 17:36 |
| fungi | for hibiscus it will include the core reviewers, because i just run the same tools the election officials use to generate the list (merely with different start/end dates) | 17:36 |
| fungi | no actual changes needed on my end now that the election tooling has been updated | 17:37 |
| fungi | and it has always included the extra a(t)cs | 17:38 |
| fungi | and more recently, contributors to sig-owned and tc-owned repos | 17:38 |
| frickler | ok, cool | 17:40 |
| opendevreview | Merged openstack/security-doc master: Minor cleanups for OSSN-0004, OSSN-0097 https://review.opendev.org/c/openstack/security-doc/+/1002672 | 17:45 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: OSSN canonical URLs are in docs.openstack.org, now https://review.opendev.org/c/openstack/security-doc/+/1002673 | 17:48 |
| *** bauzas1 is now known as bauzas | 18:07 | |
| gouthamr | when do you pull this list, fungi | 18:16 |
| gouthamr | i want to suggest a follow up list to thank folks that worked on security issues during this release, and would like to coordinate it with tc/foundation staff/vmt.. | 18:18 |
| fungi | gouthamr: rc1 | 18:18 |
| fungi | from a thanks perspective, the development cycle extends from the rnd of rc1 week for the prior release to the end of rc1 week of the current release | 18:19 |
| *** Unknown123 is now known as Mike-- | 18:19 | |
| fungi | basically the point at which stable branches are created in cycle-with-rc model deliverables and further commits to master are targeting the 2027.1 release rather than the 2026.2 release | 18:20 |
| gouthamr | makes sense; and i can work with that | 18:22 |
| JayF | gouthamr: solve a vuln, get a VMTee? | 18:25 |
| JayF | gouthamr: go tell your bosses we need t-shirt budget, go go go :D | 18:25 |
| JayF | lol | 18:25 |
| gouthamr | i wish :P | 18:25 |
| fungi | vmtee, love it | 18:26 |
| gouthamr | "VMTee" is awesome | 18:26 |
| gouthamr | VM+Tee :P i'm tripping | 18:26 |
| fungi | though chances are all we can afford is a cup of vmtea | 18:26 |
| JayF | Here's your VMTNFT, it's a goofy looking money who loves security! wow! | 18:30 |
| JayF | s/money/monkey/ | 18:30 |
| JayF | (although on reflection, I think they were technically bored apes) | 18:30 |
| TheJulia | Can we go for morale stile patches instead? | 18:39 |
| TheJulia | err, style | 18:39 |
| fungi | only if we can call them "security patches" | 18:42 |
| JayF | If OpenStack is corporate OSS, and we do punk-style recognition patches, I think that officially makes us a Poseur ;) | 18:43 |
| fungi | i'll start wearing a fully-patched jacket | 18:43 |
| clarkb | the extra fancy water bottle stickers (basically an evolution of the laptop sticker that handles water better) are all the rage right now. "Bug killing device" with an image of water drowning a mosquito or something | 18:44 |
| JayF | [I survived the 2026 LLMSecuroPacalypse] | 18:51 |
| fungi | aipocalypse | 18:54 |
| * TheJulia has a silly idea to surface | 18:55 | |
| gouthamr | ya’ll are too optimistic, we have three more months | 18:56 |
| fungi | nah, i think 2026 will stretch on for many years, much like the eternal september | 19:00 |
| JayF | gouthamr: I self-edited a (so far) outta that message lol | 19:00 |
| TheJulia | Who has the fast forward button then? | 19:39 |
| TheJulia | (and if it is actually a relativistic drive, I'll be worried) | 19:40 |
| *** Unknown123 is now known as Mike-- | 19:43 | |
| gouthamr | it's shaped like fast-forward on amazon prime video than the one on netflix | 19:48 |
| TheJulia | :( | 19:53 |
| fungi | gouthamr: is that the button labeled "please show me another commercial"? | 20:07 |
| opendevreview | Jeremy Stanley proposed openstack/governance master: Propose SECURITY.rst goal https://review.opendev.org/c/openstack/governance/+/1002692 | 20:44 |
| JayF | I don't have a fast forward button, but I am an expert in time travel. | 21:03 |
| JayF | Been moving forward at a rate of 1 second per second for approximately 42 years ;) | 21:03 |
| opendevreview | Merged openstack/security-doc master: OSSN canonical URLs are in docs.openstack.org, now https://review.opendev.org/c/openstack/security-doc/+/1002673 | 21:14 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: Move OSSN process documentation into build https://review.opendev.org/c/openstack/security-doc/+/1002661 | 21:17 |
| fungi | JayF: i have a magic time travel bag that i can put over my head go forward in time at the speed of normal time | 21:31 |
| fungi | when i take the bag off my head i've been magically transported into the future that amount of time | 21:31 |
| JayF | I have one of those, but instead of a bag, I just position myself horizontally on it to zoom 8 hours into the future | 21:32 |
| fungi | comes in really handy for sleeping in airports | 21:32 |
| JayF | it even helps slow down aging if you do it regularly enough! | 21:32 |
| clarkb | a few weeks ago I watched someone sleep in an airport across the armrests of those awful chairs that are built to prevent you from sleeping on them. I was very impressed. A real time traveler | 21:35 |
| opendevreview | Brian Rosmaita proposed openstack/security-doc master: Move OSSN process documentation into build https://review.opendev.org/c/openstack/security-doc/+/1002661 | 21:36 |
| opendevreview | Brian Rosmaita proposed openstack/security-doc master: Move OSSN process documentation into build https://review.opendev.org/c/openstack/security-doc/+/1002661 | 21:38 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: Move OSSN process documentation into build https://review.opendev.org/c/openstack/security-doc/+/1002661 | 21:51 |
| fungi | clarkb: you have convinced me to take up the challenge! | 22:04 |
| opendevreview | Merged openstack/security-doc master: Move OSSN process documentation into build https://review.opendev.org/c/openstack/security-doc/+/1002661 | 22:09 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: Trivial: Migrate README.md -> README.rst https://review.opendev.org/c/openstack/security-doc/+/1002698 | 22:12 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: Split out OSSN index page headers https://review.opendev.org/c/openstack/security-doc/+/1002699 | 22:12 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: Trivial: Remove redundant OSSN txt, move others https://review.opendev.org/c/openstack/security-doc/+/1002704 | 22:28 |
| opendevreview | Jay Faulkner proposed openstack/security-doc master: Backfill publication dates for OSSNs; publish them https://review.opendev.org/c/openstack/security-doc/+/1002707 | 22:57 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!