Re: Replay attack of query cancel

Stephen R. van den Berg wrote:
> Magnus Hagander wrote:
>> Gregory Stark wrote:
>>> "Magnus Hagander" <magnus(at)hagander(dot)net> writes:
>>> We could have the server indicate it's the new protocol by sending the initial
>>> cancel key twice. If the client sees more than one cancel key it automatically
>>> switches to new-style cancel messages.
>
>> That will still break things like JDBC I think - they only expect one
>> cancel message, and then move on to expect other things.
>
> Why didn't they follow recommended practice to process any message
> anytime? Was/is there a specific reason to avoid that in that driver?
> (Just curious).

No idea, but that's how it is IIRC. And there are other drivers to think
about as well.

>> What would work is using a parameter field, per Stephen's suggestion
>> elsewhere in the thread. Older libpq versions should just ignore the
>> parameter if they don't know what it is. Question is, is that too ugly a
>> workaround, since we'll need to keep it around forever? (We have special
>> handling of a few other parameters already, so maybe not?)
>
> You only need to keep the runtimeparameter for as long as you don't bump
> the protocol version.
> Then again, runtimeparameters are cheap.

Yeah, I guess that's true. Once you break backwards compatibility once,
you can break a couple of things at the same time :)

//Magnus