[Bug 877] ssh 3.8.1p1 client cannot disable encryption with "-c none"

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=877





------- Additional Comments From indy94538 at yahoo.com  2004-06-08 05:24 -------
> Problem is most don't understand.  Just like most kids that find guns don't
> always understand that pulling the trigger causes it to fire.  Why would we
> want to endanger our users any more than we have to?  And like aways it is
> "never the user's fault".. It has to be the software and programmer.  Even
> if they are abusing the software in a way it was never designed to be used in.

A naive user can be protected in the following ways: (1) having the command
line options "-o Cipher=none" and "-o Mac=none" are arcane enough that most
ordinary users won't know about them - finding them out would require reading
documentation which would give then sufficient warnings, (2) these options
would only work if the sshd allows them - thus a naive user won't be able 
to shoot oneself unless the system administrator explicitly permits these.

> My view is if a company wants to hack mac=none, ciphers=none into their
> SSH code.  That's fine. Not as if it is that hard or complex. However, if they 
> are now taking that risk into their hands, and can't blame us for not thinking
> through how they use the feature.

Why would someone ever blame the developers if they're providing sufficient
warnings both in the code and documentation and if the defaults do not allow
this unsecure mode. And I've seen the changes that our own administrators have
made to support Cipher=none - they are easy once you know where to put them.
Learning where to put them is what takes the time. If one does it incorrectly,
there is always the danger of introducing bugs - e.g. even making initial
user authentication unsecure. If a feature is being widely requested (and this
one I believe is), its the developers who're most qualified to provide the
appropriate changes to the code.

> > If people are really opposed to providng cipher=none and mac=none options, 
> > is it possible to provide an option to the "configure" command so that these
> > options can be put in when the build is appropriately configured ? 
>
> Which I strongly object to. Either code should be used or not be included. 
> Having additional code paths that are not compiled by default only adds more
> complexity to testing and platform verification.  

By eliminating all ways of having a ssh channel without encryption, you're
hurting seasoned users who know what they're doing. And a seasoned user may 
not be competent enough to actually go change the openssh code to remove
encryption.

> Plus it litters the source code with #ifdef/#endif garbage that makes it 
> harder to read and understand.

It doesn't have to be done using #ifdef/#endif. Even when used, they can
be restricted to some header file. Anyways, code complexity is hardly a reason
to justify not providing a widely requested feature.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.