GSSAPI Key Exchange Patch

Chris Rapier rapier at
Tue Nov 20 02:36:35 EST 2007

Simon Wilkinson wrote:
> On 16 Nov 2007, at 08:25, Damien Miller wrote:
>> Yes - we are very scared of adding features that lead to more
>> pre-authentication attack surface, especially when they delegate to
>> complex libraries with patchy security histories.
> I'm not convinced that adding key-exchange actually increases the pre- 
> authentication attack surface. At the end of the day the same  
> payloads are getting passed through to the same privileged process  
> (and onwards to the same complex library) as happens when doing  
> GSSAPI user authentication. The only difference is that one happens  
> after the key exchange step has been performed, and the other happens  
> as part of it.

Part of the problem, at least as far as I can see is it, is maintaining 
any patch that is incorporated. Any time something like this is included 
there is the strong possibility that the responsibility for keeping the 
included features up to date will fall onto the shoulders of an already 
overworked development team. Even if it's just included as a compile 
time option this can become a bit of a burden.

The more integral the patch is to a critical aspect of the code base the 
more likely this becomes. That being said, I've occasionally wondered if 
  there is a solution for all of this that would make things easier for 
the end users without overwhelming the developers. Perhaps a 
pre-configure utility that can be used to fetch well known patches from 
a maintained canonical repository and automagically incorporate them. 
Obviously, that can be problematic in its own right (conflicting 
patches, who maintains the patch repository, what gets included, etc).


More information about the openssh-unix-dev mailing list