Comment 7 for bug 1842701

Thanks for linking the upstream bug and your experiments Horst!

In the bug there it was mentioned that this would not be related to the CVE fix CVE-2019-10092.
But it made me think as Horst clearly found it to be related to that update.

I did some of the same checks Horst did (in which patch is the balancer touched).
There are three patches in the package referenced for this CVE:
- debian/patches/CVE-2019-10092-1.patch: based on [1] which matches the upstream referred [2]
- debian/patches/CVE-2019-10092-2.patch: based on [3] which might be some related cleanup and no
  big changes (but not part of the upstream CVE change)
- debian/patches/CVE-2019-10092-3.patch: based on [4]
  This last one is what brings changes to proxy/mod_proxy_balancer.c
  It is not directly tied to CVE-2019-10092 but seems to be picked up in that context.

That at least somewhat explains upstreams confusion on "referenced change to mod_proxy/mod_proxy_balancer has NOTHING to do with CVE-2019-10092". I agree that this was an extra change unrelated to that.

And if I got Horst right in the former comment he confirmed that if he drops that change it seems to work again.

But it seems (other than the mis-tag to CVE-2019-10092) this hardening to XSRF was an intended change by upstream [5].
I wasn't able to follow all comments of the upstream bug, they mentioned lynx might be incompatible to it- but does that apply to some proxies as well then?
In that case this might be a hard call on security-SRUing this into Bionic and breaking things. But while this is a no-go for normal SRUs security sometimes required changes like that.

@sbeattie - could you outline what was going on in the CVE discussions when this XSRF protection was added. And if you have any known discussions on adding XSRF protection that includes balancing those proxies/browsers.