2008-11-30
My view on vi and vim (and nvi et al)
I have a confession: for all that I use it fairly often, I am a fairly
basic user of vi. As such, I have a pretty unsophisticated view of
what vi is; if I type 'vi' and something starts up that behaves like
vi and is not too freakishly super-intelligent,
I call it vi and don't think more about it, regardless of the name
of the actual implementation. Unless I actively think about it, I'm
only vaguely aware that there are at least two reimplementations of vi
(vim and nvi), each with their own distinct additions to the original
vi. I'm not generally conscious of any differences, and I'm certainly
not sophisticated enough to notice any incompatibilities with 'classic
vi' (which is still found on operating systems like Solaris 10).
Calling everything 'vi' is a bit sloppy of me, and no doubt confuses some people (and may irritate others). But it really is how I think about this; for my purposes, the advanced features of vim and nvi and so on are pretty much irrelevant, because all I ever use is a subset of basic vi.
(This is much the same way that I call /bin/sh 'the Bourne shell',
regardless of which implementation it actually is, and I expect that
all competent implementations will behave similarly enough that I can
not care. If you force me to care, I will deduct
points.)
Well, this isn't quite true. It turns out that there are two features of modern vi reimplementations that I really miss: multi-level undo and the ability to backspace back to a previous line. While I won't go much out of my way to get a version of vi that has them installed on a random machine (for instance, I certainly won't compile my own version), I will switch to using a version of vi that has those features if it's already there. But I still don't really pay attention to what version it is, and I still call all of them 'vi', despite this being technically incorrect.
(I actually don't know if anything but vim supports those two features.)
If I used vi intensively, this ignorance would be reasonably foolish; I could probably significantly improve things like editing code by learning the more advanced features of the vi family. But my vi usage is reasonably casual; I have other editors for more involved text editing, and most of my vi skills have basically been acquired through osmosis and other peculiar means.
(I believe that I learned a reasonable chunk of vi by going through the old BSD vi tutorial but in another editor, which sort of robbed the embedded editing exercises of their teaching power. Still, a reasonable amount of that has stuck with me, so it wasn't a total failure.)
Server problems caused by 'transparent' self-signed SSL certificates
One of the issues with allowing self-signed SSL certificates to be
automatically used for transparent encryption over https URLs is the
problems that they cause for server-side applications.
Right now, a server-side program that care can more or less assume that
a SSL-encrypted connection means either that it is securely talking
to the real end user's machine or that the end user has been actively
compromised (which it can't do anything about). It may thus use things
like 'you can only talk to this service over https' as a reasonable
security precaution, one that means something.
If you allow self-signed SSL certificates to be used transparently
for encryption in https URLs, you enable relatively trivial man in
the middle attacks. This negates all of the security properties of
SSL connections. Because the browser knows what level of security the
certificate it accepted had, browsers can recognize this and lie to
things like Javascript so that nothing thinks it's getting more security
than it actually is.
However, the web server does not know and cannot know this information,
since it has no way of finding out if it is talking to the real end
machine or to a man in the middle. As such, server side applications
can no longer assume that a https URL and a SSL connection means
actual security; it might be secure and it might not be, and they can't
tell the difference. This leaves them with no way to require something
approximating actual security from clients, and it breaks current
applications (to the extent that they assume that SSL means security).
(Server side applications cannot do things like feed Javascript to the client browser to see if it is really connecting directly to them, because the man in the middle can rewrite that Javascript on the fly.)
(In theory the one way out of this is to require everything to have client side certificates. However, I do not believe that this is any more practical than trying to make all server side applications instantly give up any 'SSL means security' beliefs that they may have.)