>To restate my argument: sshd1 support does not inherantly require any
>compile-time knowledge, and so our configure script should not require
>any compile-time knowledge about sshd1. It sacrifices consistency for
>no apparent reason.
I would argue that being able to disable an unwanted option at
compile time is a security feature. That and it removes unwanted
code from the executible that could introduce errors, etc.
The security argument: If the daemon is world executible (so that
users can use it on a personal basis if they don't want to use or
can't get to that port) users can exec it. I may not want them to be
able to fall back to sshd1 for policy reasons, etc.
(I understand that they can compile and run their own binary to get
around this, but that would perhaps be against policy too :)
The bug argument: If I can get rid of code that I don't want to ever
be executed, even in error, I think this is a good thing for
stability of a daemon, and it reduces the possibility of confusion
over the actions the daemon takes.
I see the runtime config option being in a config file, not just a command
line option...
steve
==========================================================
Steve Acheson [EMAIL PROTECTED]
Cisco Corporate Information Security Cisco Systems
