Magnus Hagander <[EMAIL PROTECTED]> writes: > Andrew Gierth wrote: >> That's easily solved: when the client wants to do a cancel, have it >> send, in place of the actual cancel key, an integer N and the value >> HMAC(k,N) where k is the cancel key. Replay is prevented by requiring >> the value of N to be strictly greater than any previous value >> successfully used for this session. (Since we already have md5 code, >> HMAC-MD5 would be the obvious choice.)
> I like this approach. It's not a bad idea, if we are willing to change the protocol. > If we don't touch the protocol version, we could in theory at least > backpatch this as a fix for those who are really concerned about this > issue. Huh? How can you argue this isn't a protocol change? [ thinks for a bit... ] You could make it a change in the cancel protocol, which is to some extent independent of the main FE/BE protocol. The problem is: how can the client know whether it's okay to use this new protocol for cancel? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers