Magnus Hagander <magnus@hagander.net> writes:
> 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.
+1 for that one; we have done it already for several send-at-startup
parameters that didn't use to be there, eg standard_conforming_strings.
I'd go with defining it as the maximum cancel version number
supported, eg "cancel_version = 31", with the understanding that
if it's not reported then 3.0 should be assumed.
So the plan looks like this, I think:
* Main FE/BE protocol doesn't change, but there might be an additional
value reported in the initial ParameterStatus messages. We believe that
this will not break any existing clients.
* Server accepts two different styles of cancel messages, identified
by different protocol numbers.
* Client decides which type to send based on looking for the
cancel_version parameter.
This seems back-patchable since neither old clients nor old servers
are broken: the only consequence of using an old one is your cancels
aren't sent securely, which frankly a lot of people aren't going
to care about anyway.
Note after looking at the postmaster code: the contents of new-style
cancel keys ought to be the backend PID in clear, the sequence number in
clear, and the hash of backend PID + cancel key + sequence number.
If we don't do it that way, the postmaster will need to apply the hash
function for *each* backend to see if it matches, which seems like
a lot more computation than we want. The postmaster needs to be able to
identify which backend is the potential match before executing the hash.
The main drawback I can see to keeping this backward-compatible is that
keeping the cancel key to 32 bits could still leave us vulnerable to
brute force attacks: once you've seen a cancel message, just try all
the possible keys till you get a match, and then you can generate a
cancel that will work. Can we refine the HMAC idea to defeat that?
Otherwise we're assuming that 2^32 HMACs take longer than the useful
life of a cancel key, which doesn't seem like a very future-proof
assumption.
regards, tom lane
