OpenSSH 3.9 released (fwd)

[Fairlight]

With neither thought nor caution, Kenneth Brody blurted:
> 
> I assume that Bob is saying that it now supports the setting of any
> environment variable "name=value" pair?

Sounds like that's exactly what he's saying.  My question is actually
(besides being outside the scope of this forum) whether PuTTY will adopt
this, or whether it's already set up to use the ones defined under the
Telnet tab in the configuration.  You can already define arbitrary ones for
telnet, but I'm kind of thinking there'll be an 0.56 soon.  :)

I'm not so sure this is a Good Idea[tm].  It's bound to lead to sloppy
coding and bad assumptions.  Yes, it can be valuable, but the second people
start feeling encouraged to depend on variables that "they just KNOW"
'everyone' will have set, then someone will misconfigure a client, not
enter the variables, and their code, assuming a 100% perfect case scenario,
will promptly crash and burn.

HOW many times has the TERM=something for cron and other non-tty-based
jobs question had to be answered here?  It assumes something that isn't
guaranteed, and it encourages sloppy coding.  And just so nobody thinks
I'm picking on fP, that's only the most fP-centric example that leaps
immediately to mind.  People tend to assume a correct $PATH exists as well,
not to mention $HOME, $LOGNAME, and a slew of other things.

Handy, yes...used in moderation, with a high degree of caution.  But its
very presence is like the fertiliser for cultivating poor coding practices.

Besides that, it could be a security/auditing nightmare.  Assume you get a
rather thoughtless developer that sees this and thinks, "Hey, I can have
them stick this unique ID in here and track this particular user by this
data."  Then you get some wiseacre who knows how the system actually works
and steals the ID from another user and your auditing goes straight to
hell.  If the server itself doesn't set it, it probably shouldn't be used
for much of anything except triggering conveniences, such as what Brian was
talking about inasfar as setting an ANZIO string to tell him it's safe to
passthru print or whatnot.  It definitely shouldn't be taken as a "carved
in stone" dataset though; client-side settings never should be.

YMMV, and I have a hunch Brian or someone else is going to try and clean
my clock with a counter-argument.  He's welcome to his views, as is anyone
else to theirs.  These are mine, and I stick by them without further
argument.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html