I was thinking of changing it with something like the following patch,
  which would still allow XOR to be reenabled at run-time if necessary.

The point is to make people who say "I as an admin do not want to
allow xor AT ALL" comfortable.  I guess the key question is what the
use cases are now.  For me, I am building coda from cvs and have been
for years, because i always want the latest bugfixes.  Perhaps a huge
warning should be emitted if xor is enabled, and something logged that
it is disabled, so people can look at the logs and be comfortable.
Right now it's way too opaque.

It may be that there should be the disable code I posted, but with the
default being disable and then in the non-disable case default to
disabling unless env var is present.  But I don't know how many users
still actually want xor.

  Then at a later point I would just remove the code that implements the
  old handshake which should be fairly easy to identify as it involves
  anything that is disabled by the RPC2_secure_only variable.

Sure, but that's a separate issue from how we deal with this in the
meantime.



-- 
    Greg Troxel <gdt_at_ir.bbn.com>