But these
days, [vttest] uses ./configure, which is a security
nightmare waiting to happen.
Uhh...WTF? Do you do your builds as root or
something?
No (well, not most of them); why? Do you think running malicious
code is fine provided you're not running as root?
What portion of it is
malicious (asking honestly)?
None...probably.
The thing is, configure is an excellent place to hide a malicious
grappling hook: it is frequently run by na?ve installers, not
uncommonly as root; by the nature of what it does, it is hard to
sandbox (for example, it *must* be able to compile and run new
programs); it is large and comparatively difficult to read over for
human verification.
This means that unless I take an hour or two and read through
configure, I'm basically betting the security of my system that the
distribution didn't get trojaned. Even if I *do* take that hour or
two, reading configure is mind-numbing enough that it's easy to miss
something subtle. (I've read through a couple of configure scripts.)
I've thought about how I'd go about trojaning a configure script, and
the answers scare me enough that I have to want something quite a lot
before I'm willing to "just run ./configure".
This is why I called it "a security nightmare waiting to happen".
As interested as I am in how mterm -termtype decansi stacks up against
vttest, I'm not nearly interested enough to be willing to either take
that risk or take that boring couple of hours (still leaving some
slight risk).
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
