XPost: linux.debian.bugs.dist, linux.kernel   
   From: TWR@tylerwross.com   
      
   Weird behavior I just discovered:   
      
   Explicitly setting allowed-enctypes in the gssd section of /etc/nfs.conf   
   to exclude aes256-cts-hmac-sha1-96 makes both SHA2 ciphers work as   
   expected (assuming each is allowed).   
      
   If allowed-enctypes is unset (letting gssd interrogate the kernel for   
   supported enctypes) or includes aes256-cts-hmac-sha1-96, then the XDR   
   overflow occurs.   
      
   Non-working configurations (first is the commented-out default in nfs.conf):   
   allowed-enctypes=aes256-cts-hmac-sha384-192,aes128-cts-hmac-sha2   
   6-128,camellia256-cts-cmac,camellia128-cts-cmac,aes256-cts-hmac-   
   ha1-96,aes128-cts-hmac-sha1-96   
   allowed-enctypes=aes256-cts-hmac-sha384-192,aes256-cts-hmac-sha1-96   
   allowed-enctypes=aes128-cts-hmac-sha256-128,aes256-cts-hmac-sha1-96   
   allowed-enctypes=aes256-cts-hmac-sha384-192,aes128-cts-hmac-sha2   
   6-128,aes256-cts-hmac-sha1-96   
      
   Working configurations (first is default sans aes256-cts-hmac-sha1-96):   
   allowed-enctypes=aes256-cts-hmac-sha384-192,aes128-cts-hmac-sha2   
   6-128,camellia256-cts-cmac,camellia128-cts-cmac,aes128-cts-hmac-sha1-96   
   allowed-enctypes=aes256-cts-hmac-sha384-192,aes128-cts-hmac-sha256-128   
   allowed-enctypes=aes256-cts-hmac-sha384-192,aes128-cts-hmac-sha1-96   
   allowed-enctypes=aes128-cts-hmac-sha256-128,aes128-cts-hmac-sha1-96   
      
      
   Is this gssd mishandling some setup/initialization?   
   Or is there a miscalculation happening somewhere further up?   
      
      
   TWR   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)