To protect the wp-config.php file using htaccess is a well known security precaution for any WP pro.
The issue however is if you have a copy of said file, in which case protecting the main version would be useless.
Also I'd say the blame if you can assign any is on Vim, Emacs, Gedit, and Nano which would have had to crash in order to set these chain of events in motion.
vim lets you choose where to put swp/backup files. Mine are always in ~/.vim/tmp. Avoids awkward issues with scripts that operate on the current directory recursively. And no, you cannot blame shitty security on a text editor.
(A) Database passwords are a security risk. You don't want them escaping to other servers when you clone or share code.
(B) Wordpress is commodity software. You are unlikely to need custom modifications to the source. "I'm on version 3.4.2" is sane enough version control.
(C) Database passwords are ephemeral. You don't need to keep a durable record of them. If your hard drive fails or you otherwise lose your record of them, you can just change the password. What is needed is a good backup strategy, not a durable password.
I would say live editing wp-config.php outside of version control is the best strategy, until you start needing to synchronize multiple webservers. At that point you should switch to some deployment and configuration manager like Chef or Puppet, not put passwords into version control.
You're right; on reflection, version control has nothing to do with it (besides a .gitignore with wp-config-anything ignore entries). I used to use a wp-config.php file in a shared directory on the server that gets symlinked in by Capistrano during deployments; there's no way to accidentally create new .swo/.bkp/.whatever files in production without both screwing up the Capistrano recipe and wp-config.php file creation.
(It seems I skipped actually writing something useful and went straight to durr version control, sorry.)
Points A) and C) are dead on. Addressing your point B), though:
Yes, it is commodity software. But most seem to use at least some plugins and themes, and making changes to those without a rollback is a nightmare. You can make backups before changing things, sure, but version control has that already built in.
(Sibling posts to yours point out that Wordpress looks in both the docroot and one level up for wp-config.php - if I ever manage a Wordpress site again I'll be sure to move it out.)
Our tutor in my first year uni course taught us to put sensitive information into a folder outside the web path, and use relative paths to include the files where needed. There is absolutely zero reason these sensitive files should be accessible via URL.
thanks for the summary, I had to read the whole article to pick that out. Also, if there is a connection error (such as FTP session ending) that could also leave the copy on the server.
Take away is to not use an editor that auto-saves or to save it on your local computer and put the finished file onto the server.
Why would they not have a config folder which uses .htaccess to protect everything inside? That would close this vulnerability without affecting convenience.
The issue however is if you have a copy of said file, in which case protecting the main version would be useless.
Also I'd say the blame if you can assign any is on Vim, Emacs, Gedit, and Nano which would have had to crash in order to set these chain of events in motion.