OpenSSH 3.9 released (fwd)

[Brian K. White]

Fairlight wrote:
> 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.

No your points are all valid. My take on it is that it is not just
convenient but extremely convenient to the point of being extremely valuable
because it makes a lot of "magic" possible, makes it possible for more
transparent/ubiquitous experience for the user.
Users are always asking for things to behave conditionally. That is very
hard to arrange purely from the server side.
It's not just trivial conveniences nor dangerouse security landmines. As
always, there is a whole world of in between that you are not giving enough
benefit of the doubt to.

here's one example:
Instead of having a single login icon on the desktop, which leads to a
filepro menu.
how about a set of icons that are all the same except they set a "program"
variable differently, and something in /etc/profile or .profile looks for it
and launches a different program depending, and maybe does a lot of other
conditional stuff.
How about a set of web pages with links instead of desktop icons? Now you
can draw fully graphical menus with none of the fp menu limitations. That
isn't neccessarily a security problem, and isn't necessarily of trivial
value either.
We've realized we could do that with facetwin since forever, but just never
got around to doing it.

Really there are a lot more simple and basic places where it's just the one
little key ingredient that makes some bit of automation possible, or
effortless vs impossible or wildly impractical for the value of the end
result.

Having the ability to have things behave really dynamically and
conditionally is not inherently insecure. It's what you do with it.
Sure, this idea is exactly why Windows is so insecure. M$ went hog wild with
the idea and invented 37 forms of signaling and scripting and reacting and
ole embedding and what not and built it all into every single function call
and as a result a lot of really slick things are possible and also it's
utterly impossible to secure the system because basically what it all
amounts to is practically every line of code is written to be the exact
opposite of secure by design.

But the idea of all that interoperation and cooperation and dynamic
behaviour is not bad. The goal is righteous. Merely M$'s
instant-gratification-driven implimentation is hainous.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani