The video link that was provided in the explanation does a very good job of illustrating the problem.
My heart jumped when he ran strings on the temp file system and the contents of his scrollback from the SSH session were shown.
I guess I had always assumed that stuff wasn't going to be written to any local disk in any way.
Edit: added "often"
I can't think of a realistic situation right now that will catch you out, but with full disk encryption I don't have to.
This still means that an encrypted swap is a good idea. Either that or don't even have it as a separate partition, since some point in linux 2.6 series of kernels it got to be very efficient at using a file as swap. This means that you've only got one set of keys to manage, and it's much easier to setup (in fact it's likely supported by nearly every distro that supports encrypted root filesystems out of the box).
I personally like to name my swap files /WIN386.SWP
Now this security issue, it's very dangerous and causes many issues.
Thanks a lot for warning me, I probably will stop using Vte, I've just been recommended TermKit and others, time to check those out!
Unencrypted swap means ANY sensitive data in memory may well end up on disk (including a term buffer that has been carefully kept away from /tmp by the emulator author!).
Surprisingly, many Linux distros, including Ubuntu, do NOT encrypt swap by default. That's probably something that should be higher priority than this specific (Linux platform specific) bug, IMHO.
OS X, for what it's worth, DOES use secure swap by default starting with Snow Leopard (http://docs.info.apple.com/article.html?path=Mac/10.7/en/mh1...). In prior releases, turning it on is a single checkbox. (There is at least one Google hit saying it was off by default in 10.6, but that's not the case, it was off in 10.5.)
The standard trick with encrypted swap on Linux is to pull an encryption key out of /dev/urandom on boot and never store it anywhere. I suspect libVTE could do something similar without a lot of code, though it would be a bit strange for a terminal emulator to depend on crypto libraries.
Might be a good idea to set up a once-a-week cronjob that does this in any case.