| fungi | https://bugs.launchpad.net/horizon/+bug/2163119 is now public | 14:01 |
|---|---|---|
| opendevreview | cid proposed openstack/ossa master: OSSA-2026-008: Errata 2 - socat console regression https://review.opendev.org/c/openstack/ossa/+/1000735 | 17:50 |
| JayF | fungi: gouthamr: rosmaita: ^ curious what other VMT folks think about that errata? unsure how to handle the weirdness around 2024.2 not existing (and 2026.2 not existing) when the original OSSA hit | 17:54 |
| JayF | I think this is probably OK as it's written, but I'm tempted to suggest we add a line to both of those releases saying why they don't have (original fix) or (errata 2) patches | 17:54 |
| gouthamr | isn't this a regular bugfix JayF? you have the release notes to explain this regression, and fix it up? or am i missing why this needs to be advisoried? | 17:57 |
| gouthamr | is it about the reach of the advisory? | 17:58 |
| JayF | the advisory patch *introduced the bug* | 18:04 |
| JayF | we secured the feature so well we broke it | 18:04 |
| gouthamr | we've done this sorta thing, but rarely | 18:04 |
| gouthamr | > we secured the feature so well we broke it | 18:05 |
| gouthamr | yes, i'm hoping distros/packagers that notice the bug are going to pick up the fixes | 18:05 |
| JayF | hm | 18:05 |
| JayF | I think I disagree strongly. | 18:05 |
| JayF | That's based in an assumption that OSSA is only used at the point-in-time | 18:06 |
| gouthamr | the precedent to publish errata patches: OSSA-2023-003, OSSA-2017-005, OSSA-2021-002 | 18:06 |
| JayF | right now, we have a doc merged to our security repos saying "install this patch to secure this feature" but really those patches just break things | 18:06 |
| JayF | I don't care about the emails/notifications/etc | 18:06 |
| JayF | I just do not want that doc to say wrong things forever | 18:06 |
| JayF | that's primarily where my head is at, and why I thought it was a slam dunk to errata it | 18:07 |
| gouthamr | https://security.openstack.org/ossa/OSSA-2023-003 | 18:07 |
| gouthamr | https://security.openstack.org/ossa/OSSA-2017-005 | 18:07 |
| gouthamr | https://security.openstack.org/ossa/OSSA-2021-002 | 18:07 |
| JayF | 2017-005 is a straight "we broke functionality with this security patch; errata patch fixes it" | 18:08 |
| JayF | 2023-003 is two non-security bugfixes, just fixing regressions too | 18:08 |
| JayF | So I think we have historical backing for errata'ing an OSSA when the original patch was breaky | 18:08 |
| gouthamr | no you're not wrong, my devils-advocate argument is also to learn | 18:09 |
| gouthamr | > So I think we have historical backing for errata'ing an OSSA when the original patch was breaky | 18:09 |
| gouthamr | yeah | 18:09 |
| JayF | tbf I didn't come with any reciepts | 18:09 |
| gouthamr | but, who discovered the problem/ | 18:09 |
| JayF | probably the only human in the world still using this feature /s (but probably closer to the truth than not) | 18:10 |
| JayF | but it was an operator who applied the patch and was like "this is totes broken" | 18:10 |
| gouthamr | JayF: ack, adding comments for some changes.. but am okay with it.. the timeline is ~4 months apart, which is longer than prior bugs had erratas.. but we have no time cutoff.. maybe fungi/rosmaita'll have a different opinion | 18:32 |
| fungi | sorry, was on a conference call but catching back up now. yes the original reason for errata was when we needed to announce patches that fixed regressions introduced by the original fixes, though we've co-opted that same process for any other updates we make to advisories for the sake of transparency | 19:10 |
| fungi | and now it tends to mostly be the latter, but it's also still very much for the former | 19:12 |
| fungi | the only related exception is when a security fix introduces a new vulnerability or doesn't completely solve the original vulnerability, then we've preferred an entirely new advisory for those cases | 19:12 |
| rosmaita | JayF: left a comment for you | 19:12 |
| gouthamr | > the only related exception is when a security fix introduces a new vulnerability or doesn't completely solve the original vulnerability, then we've preferred an entirely new advisory for those cases | 19:13 |
| gouthamr | ah, good to know.. | 19:13 |
| gouthamr | (since this hasn't happened this year so far) | 19:13 |
| fungi | mainly because if you're an operator and you've applied security fix x and it broke your deployment you'll be looking for updates to the advisory for x, but if applying x silently left you still partly vulnerable or opened up a wholly new vulnerability you probably aren't looking for updates to x | 19:15 |
| rosmaita | fungi: what's our stance on what to call an individual item in an errata? Red Hat pretty much uses 'errata' for this, but i believe the traditional term is 'erratum' | 19:20 |
| fungi | i took (too) many years of latin in my youth and so also prefer erratum (errata is the plural form) | 19:21 |
| fungi | same for datum vs data | 19:21 |
| fungi | in my opinion if you're going to just steal words from another language, don't half-ass it | 19:22 |
| fungi | like indices instead of indexes, axes instead if axises, and so on | 19:23 |
| rosmaita | i had an argument with an editor at routledge about data vs datum in the context of a von neumann machine ... i said the content of a memory location could be an instruction or data, and she said it should be 'instruction or a datum'; my argument was that without interpreting it, you couldn't know whether it was a singular piece of data or several, so she let me get away with using "data" | 19:24 |
| fungi | https://bugs.launchpad.net/horizon/+bug/2163088 is now public | 20:25 |
| opendevreview | cid proposed openstack/ossa master: OSSA-2026-008: Errata 2 - socat console regression https://review.opendev.org/c/openstack/ossa/+/1000735 | 20:27 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!