| d34dh0r53 | fungi: I can try to drive, can you point me to the documentation/notes on how to put out an advisory? | 12:48 |
|---|---|---|
| fungi | d34dh0r53: yep, have a read through https://security.openstack.org/vmt-process.html and keep in mind that it refers to both private and public workflows (in this case we're following our public workflow) | 12:50 |
| fungi | per the the process diagram on that page, i already handled the reception step, so the next thing to work on is an impact description (which i've also partly written in my comment, but should be wordsmithed into our standard impact description template) | 12:51 |
| d34dh0r53 | fungi: ok | 12:55 |
| fungi | once everyone's happy with the accuracy of the impact description, we can use that to request a cve assignment, and then we're basically waiting for the master branch fix that's already in review to merge and for someone to propose stable backports, at which point we can propose a change to the ossa repo to add the advisory metadata and hold there until all maintained stable branches | 12:55 |
| fungi | get fixes merged | 12:55 |
| d34dh0r53 | fungi: so I'll use what you've written in the bug to craft the impact description, where do I put that for review? | 12:56 |
| fungi | for the draft impact description step, see the impact description template at the end of that document, and propose your adaptation of it in a bug comment | 12:56 |
| fungi | that's the easiest place for the vulnerability coordinators and the devs working on the fix to coordinate such information | 12:57 |
| fungi | the impact description, once okayed, will form the core wording for the information we include in our cve request and in any eventual advisory publication | 12:58 |
| d34dh0r53 | ack | 12:59 |
| fungi | d34dh0r53: you can look at the bug corresponding to our most recent ossa for an example, if it helps: https://launchpad.net/bugs/1942179 (my impact description draft is in comment #24, and it didn't end up needing revision) | 13:07 |
| fungi | in that particular case i didn't write the impact description until after the backports had merged, but usually we like to get started on that sooner | 13:08 |
| fungi | in the example, that's the wording which eventually ended up as the basis for https://security.openstack.org/ossa/OSSA-2021-006.html | 13:10 |
| d34dh0r53 | got it, do we know the affected versions of this this one? | 13:13 |
| fungi | d34dh0r53: if it can't be easily inferred from the description, ask the folks involved on the bug (in this case gibi or sean-k-mooney), but you can also start from an assumption that all existing versions are affected and branches listed as being in "maintained" state will have fixes backported and new point releases made: https://releases.openstack.org/ | 13:17 |
| fungi | so that would be all historical nova versions prior to the next wallaby point release, all xena versions prior to the next xena point release, and all yoga versions prior to the next yoga point release | 13:19 |
| fungi | if someone manages to work out when the vulnerability was originally introduced into the codebase, we can put a lower bound at the start of the affected versions list and/or drop some ranges | 13:19 |
| d34dh0r53 | ack | 13:20 |
| fungi | but to be conservative we typically assume all versions are affected unless someone confirms otherwise | 13:21 |
| fungi | better to tell people to upgrade unnecessarily than mistakenly tell them they're safe | 13:21 |
| fungi | it's also easy enough to revise the affected versions once the backports are proposed, since that can give us a better idea (e.g. we can't backport this fix to wallaby because we discovered that the flaw merged after that time) | 13:24 |
| fungi | and we usually do a last-minute check of the affected versions list when reviewing the ossa prior to publication anyway, just in case we raced a point release on some branch and need to bump the version for it in the advisory | 13:25 |
| d34dh0r53 | ok, understood | 13:26 |
| fungi | none of the impact info is carved in stone, it's just a starting point. if we later discover we were wrong about something we can let mitre know to update the cve text, or even add an errata block in an already distributed advisory | 13:28 |
| fungi | and in the past we've sent out announcements about revisions to advisories if significant enough | 13:29 |
| d34dh0r53 | ok, cool | 13:35 |
| d34dh0r53 | I just posted the impact statement | 13:36 |
| fungi | thanks! i'll read through it in a bit and leave feedback on the bug | 13:41 |
| d34dh0r53 | fungi: ack, thanks | 13:42 |
| fungi | d34dh0r53: i left a couple of suggestions in a followup comment, but looks great overall. thanks for putting that together! | 14:49 |
| fungi | once we have some loose consensus, the next step will be filling in the cve request form on mitre's website | 14:49 |
| fungi | gagehugo: prometheanfire: dmendiza[m]: please take a look at the proposed impact description in comment #6 of https://launchpad.net/bugs/1981813 when you have a free moment. thanks! | 14:51 |
| fungi | in unrelated news, a fix has been proposed to swift for https://launchpad.net/bugs/1980954 so it's probably time to start thinking about whether that one will warrant an advisory too | 14:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!