I guess I'm not sure if/why the patch to disable this by default really needs to happen in total unison with the advisory. Since this is already disable-able via policy (and we'd just be flipping policy defaults in said patch), I would expect the least-effort and lowest-latency approach would be to issue the advisory, basically suggesting that people tweak their policy files to disable this. They don't really need new packages from their vendors in order to do that.
I'm also not sure on the backports, as that may surprise users who 'apt upgrade' (as opposed to dist-upgrade) their way to an API that is now disabled.
But, if Abhi wants to do all the stuff you suggest (and/or you think it's critical do it that way) then ... yes your list is correct :)
I guess I'm not sure if/why the patch to disable this by default really needs to happen in total unison with the advisory. Since this is already disable-able via policy (and we'd just be flipping policy defaults in said patch), I would expect the least-effort and lowest-latency approach would be to issue the advisory, basically suggesting that people tweak their policy files to disable this. They don't really need new packages from their vendors in order to do that.
I'm also not sure on the backports, as that may surprise users who 'apt upgrade' (as opposed to dist-upgrade) their way to an API that is now disabled.
But, if Abhi wants to do all the stuff you suggest (and/or you think it's critical do it that way) then ... yes your list is correct :)