Tuesday, 2026-09-08

fungihttps://bugs.launchpad.net/ironic/+bug/2166511 is now public (duplicate of 2150332)13:35
JayFDo we have a practice for when a bug is public security vs public?15:13
JayFIronic has some class d things I'd like to get outta our "security meeting" dashboard as they aren't urgent15:13
fungithe practice, generally speaking, is we use public security for anything that got or is planned to get an ossa, and regular public (often coupled with the security bugtag) for everything else15:14
fungiideally everything that's public security type has an ossa task that is either open or fixed, not other closed states15:15
fungiwe can certainly revisit that practice, but it's (not-well-recorded) patterns we followed for most of the project's lifetime15:17
JayFhttps://bugs.launchpad.net/ironic/+bug/2166500 is now open15:20
JayFfungi: that's the answer I wanted15:20
JayFfungi: maybe with the exception of "leave it public sec if it might get an OSSN" in ironic cases :)15:21
funginow that the vmt is overseeing ossn publication more, i can see maybe extending public security type to cover both ossa and ossn15:21
fungii suppose the more we can treat those alike, the simpler it may make our lives15:22
JayFthat is basically where my mind has been the whole time15:36
JayFhint: if OSSAs and OSSNs both have schemas now, that's step 1 down a path to them being /the same/ schema with a "advisory_type:" key15:37
fungiyes, that was my thought process as well15:42
fungibaby steps15:42
gouthamr> the practice, generally speaking, is we use public security for anything that got or is planned to get an ossa, and regular public (often coupled with the security bugtag) for everything else16:39
gouthamri haven't followed this consistently16:39
fungiit was never a hard and fast rule, which is why it's not reflected in our process document16:39
gouthamror never i think, if i think this is class E (not a security bug), yes, i switch to direct public and let the team triage.. but, if this has _some_ OSSA/OSSN potential, i was just keeping things in "Public Security" - causing us much cleanup debt16:40
fungithe goal of that was mainly to make it easier to query for things16:42
JayFgouthamr: fungi: My original question was centered around some Ironic Class D hardening stuff, which we would never advisory... and I just wanted it outta the dashboard16:44
gouthamrJayF: ack, would you want operators to still find that security issue easily? if yes, a tag could work.. I can get behind setting "public security" for OSSA worthy bugs alone16:46
JayFI am -1 to the assumption that all Class D hardening opportunities are stuff operators need to track16:47
JayFin Ironic cases, it often means just adding to the docs "you are accepting implied security risk A" to the docs16:47
JayFinstead of just leaving the 2+2 = equation in the docs for someone to sum together themselves16:47
JayFAI security bots are not as good at devops as actual humans, who woulda thought16:47
gouthamryou've angered a potential civilization with that statement16:48
JayFOh no! This ephemeral prebuilt ramdisk which you access via ssh doesn't have a well-known host_key!16:48
fungithe horror!16:48
JayFNormal devop: "Yeah. Ephemeral, reusable ramdisks don't have host keys". LLM: "SECURITY ALERT: HOST KEY CHECK MISS CWE-12345 YOU ARE INSECURE"16:49
JayFand I take the approach of yeah, we shouldn't assume folks have that context anymore because [gestures generally at the industry], so being more explicit in the docs is valuable16:49
JayFbut those bugs? I don't want any operator thinking about them ever. They are not valuable except in the output of the improved docs.16:50
gouthamrack makes sense.. switch to "public", and don't need a "security" tag either.. 16:51
*** mrunge_ is now known as mrunge23:12

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!