Tom Lane wrote: > 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?
Um. By looking at it only from the backend perspective? *blush* > [ 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? Yeah, that's the point that will require a protocol bump, I think. Since there is no response to the cancel packet, we can't even do things like sending in a magic key and look at the response (which would be a rather ugly hack, but doable if we had a success/fail response to the cancel packet). I guess bumping the protocol to 3.1 pretty much kills any chance for a backpatch though :( Since a "new libpq" would no longer be able to talk to an old server, if I remember the logic correctly? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers