On Thu, Oct 17, 2002 at 10:35:50AM -0400, Ben Collins wrote: > On Thu, Oct 17, 2002 at 10:49:06AM +0100, Jonathan Amery wrote: > > Ben Collins wrote: > > > On Wed, Oct 16, 2002 at 09:50:10PM +0100, Matthew Vernon wrote: > > > > ssh is using getpeername() in accordance with the manual. The > > > > structure that getpeername() returns is causing gatenameinfo() to > > > > barf. That seems to me to be unambiguously a bug. > > > > > > Only because kernel 2.2 is broken, not becuase glibc is. The reason is > > > because kernel 2.2 uses an old obsolete api. > > > > Firstly - this is not a bug in sshd - sshd is interacting with libc's > > API in good faith. > > > > Secondly - it is the job of libc to ensure that the APIs it exposes > > function correctly. If the IPv6 code in 2.2 is incompatible with > > these APIs then libc should not be attempting to provide IPv6 on > > systems with a 2.2 kernel, rather than functioning outside of the APIs > > that it claims to implement. > > No, sshd should be checking the validity of the data that is returned to > it.
sshd does check the validity of its data, and correctly throws an error because it finds that getnameinfo() returns -1. That is not the problem here. Could we at least have some documentation that getnameinfo() with IPv6 addresses is not supported on pre-2.4 (or non-RFC2553) kernels? This is evidently the state of affairs, and a simple note would help other programmers to know that this call will fail with a surprising errno. In response to "nobody sane would use IPv6 on 2.2", well, that may be true, but that's not exactly obvious to new people who see that the module's available and some things appear to work - documentation would go a long way here. Since you're saying that glibc doesn't want to work around a kernel bug, I'm sure you can appreciate that we aren't keen on working around what we see as an inadequacy in glibc either. The mutual unwillingness to perpetrate workarounds is why this argument has dragged on for so many months. The proposed solutions in openssh so far seem to have involved hacks like testing utsname.release to see whether the kernel is 2.2, which is clearly quite nasty (at least test features, not version numbers ...). Is there any compromise we can reach *without* applying hacks that cover up the fact that glibc doesn't cope with the differently-sized kernel structure? Perhaps having some documentation in glibc, and outputting a loud error message in ssh and trying to gracefully downgrade to AF_INET? -- Colin Watson [EMAIL PROTECTED]
