[263] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: [brlewis@MIT.EDU: Re: getopt paradigm]

daemon@ATHENA.MIT.EDU (John Hawkinson)
Wed Jan 18 13:31:11 1995

Date: Wed, 18 Jan 1995 13:30:52 -0500
To: Mike Barker <mbarker@MIT.EDU>
Cc: brlewis@MIT.EDU, cfields@MIT.EDU, release-team@MIT.EDU, krb-apps@MIT.EDU,
        ghudson@MIT.EDU.release-team@MIT.EDU
In-Reply-To: "[262] in Release_7.7_team"
From: John Hawkinson <jhawk@MIT.EDU>


Mike Barker writes:

> Personally, I like programs to tell me when they change behavior (e.g.
> not providing encryption), but I have to agree with Craig, doing a lot
> to provide our users with sensible behavior could be a problem when
> they go to other systems.  I'm not sure we need to worry too much
> about it, though:-)

If you bring this up, is not making an encrypted connection the default
just as bad? (users will go to other systems and expect an encrypted
connection but not get it?).

> Why not write up what you would propose for a consistent, easy-to-use
> telnet interface and start working toward that?

This seems directed at me :-). I've added such an item to
/afs/sipb/user/jhawk/telnet-todo...


Bruce wrote:

> Please look at how telnetd handles -debug with getopt.  We didn't do
> this; it was already there.  It isn't heresy to use getopt that way.

I wasn't going to bother instantiating a new message for this, but I
think the argument is specious. Just because the -debug and -safe people
decided to break the paradigm doesn't mean we should keep doing so...

> 1.  not sure why we go out of our way to make sure -s won't work, only
> -safe (or "-s afe")

Presumably we're saving the -s option for later?

> 2.  if ENCRYPTION and AUTHENTICATION aren't available this turns into
> a complicated version of -a, BUT doesn't warn the user.  it would be
> nice to do something like the -x option and add some else handling

Yeah. The right way to do this is how telnetd/telnetd.c does it, which
is to set the string for getopt depending upon the compiler macros, so
that -safe (err, -s) would be rejected out of hand, anyway, as an
invalid option. (calling a non-uber-telnet (:-)) with -safe should
result in an error).

> ghudson
> -> 	  * What if I just specify -x?
>  
> jhawk
> -Nothing. This has never worked. It is a bug that it does not
> -error out.
>  
> John, why do you think it has never worked?

Because it doesn't! Try it :-). The wonders of empirical evidence.
I've always assumed it doesn't work because the method of encryption
(the default, and only real available one) used relies upon
authentication.  (That is, you cannot get an rcmd.foobar without
having tickets and performing authentication to do so... Whether that
authentication actually needs to be *used* by telnet is not a case
covered in the current paradigm).

> [yech! here's encrypt_auto()--you tell me what that bind of ?: works
> out to...]

> 		  autoencrypt = on ? 1 : 0;

Eh? If on is true, autoencrypt is one, otherwise it's 0.


You asked how these command-line options affect typed commands.

	-a	is the same as		toggle autologin
	-x	is the same as		toggle autoencrypt
				AND	toggle autodecrypt

--jhawk

home help back first fref pref prev next nref lref last post