Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
RT-Send-CC:
X-RT-Original-Encoding: iso-8859-1
Content-Length: 933

Mulling this one over still.

It's very unusual for callers to call krb5_[ck]_encrypt like this, since 
normally the output needs a larger buffer than the input.  In this use 
case, the enctype is raw-mode DES, so in-place encryption is sensical.  
There are four kg_encrypt call sites like this in the krb5 mech.

Possible solutions are:

1. Declare the callers at fault and change them.  This would be fairly 
easy since the encryptions are of fixed-length (16-byte) buffers.

2. Use memmove instead of memcpy, or check if input->data == output-
>ciphertext.data + header_len and elide the memcpy in that case.  This 
would allow aliasing of input and output in krb5_k_encrypt only for raw-
mode enctypes.

3. Allow aliasing for all enctypes somehow.  (I'm not sure if it worked 
for non-raw enctypes prior to 1.8.)

I am currently tempted to go with #1 since the other solutions have a 
performance impact on well-behaved callers.