Gordon Matzigkeit <[EMAIL PROTECTED]> writes:
> >>>>> Niels M�ller writes:
>
> NM> I think it would make sense to have a configure time option
> NM> --with-sshd1, to make it possible to (i) disable the callback
> NM> code completely, and (ii) specify a default path for the sshd1
> NM> program.
>
> I'm not sure I understand your rationale. Could you describe any
> reasons why you would want to compile out the fallback code? With my
> patch, ``disabling it completely'' is done when --ssh1-fallback is not
> specified.
I'm afraid my rationale is not very rational. I feel that sshd1
support is an optional feature of any ssh-2 implementation. And that,
in a few years, it will also be considered a really obscure feature.
That is why it makes sense, to me, to be able to #ifdef away all
support for it.
And another reason to keep the --with-sshd1 compile time option is
that it seems like a good way to specify the default path for sshd1.
But that issue is quite orthogonal to whether or not the support for
sshd1 can be disabled at compile time.
> except that the second form forces you to recompile the package if you
> accidentally forgot a configure switch.
As soon as the sshd1 support works, I think it should be
(compile-time) enabled by default, so you would not forget it
accidentally.
> If we have both runtime and compile-time options, then we create four
> separate code paths. Then, also, other people's programs might have
> to do configure tests to see if --ssh1-fallback is supported by a
> given lshd. I'd rather go for consistency across all platforms and
> implementations, where possible.
As you have noted, in most places it will just be an
#if COMPILETIME_ENABLED
if (runtime_enabled)
construction, so there will be just two codepaths.
As for hypothetical configure scripts, I don't quite see when you
would want to do this. Do you have any example where it would do good?
Whether or not to support sshd1 on a particular machine is a decision
with some security implications. I suspect that in most cases it will
be a bad idea to delegate that decision to somebody elses configure
script. And in any case that configure script would also have to do
some tests to see if the installed sshd program supports falling back
to; one more to test if the installed lshd supports falling back to
sshd1 should be rather trivial.
As for consistency, I'm afraid that in this particular case it is a
futile mission. Some machines will have an sshd1 program installed
that can be fallen back to, some will not.
Regards,
/Niels
