I agree that sounds like the most pragmatic approach. I don't see a reasonable way to "fix" this in stable releases without introducing new dependencies, adding config options, and potentially breaking existing production deployments. An OSSN and documentation improvements describing the actual intent for internal HTTPS support in these components seems like the only way to avoid having this embargoed more or less indefinitely.
Also, once the bug is an open/public hardening feature request it becomes much easier to pool the developer community to collectively solve instances of this much more quickly.
I agree that sounds like the most pragmatic approach. I don't see a reasonable way to "fix" this in stable releases without introducing new dependencies, adding config options, and potentially breaking existing production deployments. An OSSN and documentation improvements describing the actual intent for internal HTTPS support in these components seems like the only way to avoid having this embargoed more or less indefinitely.
Also, once the bug is an open/public hardening feature request it becomes much easier to pool the developer community to collectively solve instances of this much more quickly.