I can't believe you hardcoded this for MySQL instead of using PDOs, and I can't believe the 10k line count for this. Gosh. Is "de-engineering" a proper term for this?
So reading the data, applying crypto on the data, and then writing it back, is faster than just writing random data to the same cells to erase the data? How?
Edit - Adding my response here for later reading when the ridiculous hellbanning that filtered me and another user from the discussion is lifted...:
There's a problem with your theory here, in how you (and others responding to DanBlake's question) have misunderstood how a flash memory device works. How can the user or operating system, on software level, select a definite block of data for "zeroing out" when the storage medium is an SSD where wear-levelling is always present and ultimately what controls, on lowest possible level, what memory cell data is going to be written to? To my knowledge - and do correct me if I'm wrong - this is not doable on an SSD, and you thusly have to overwrite the entire SSD to be certain that the memory cell holding the key is erased. This is how flash memory controllers work - they always write data to the next free block, remap the old block and then marks it as unoccupied in the BAM.
If the case is a mobile unit that may have a small portion of separate PRAM or similar where you can store crypto keys, the principle is the same there as that's also a flash type memory, even if a much smaller one that is faster to erase. However, that solution isn't usually available in a "normal computer", nor available to a "normal OS", which are the two targets of SSD drives.
Alias does not change the root dir, according to Nginx documentation. This was what made us believe that through eventual exploit, it could be possible to reach the active root dir through a completely different path as set per alias. In addition to that, having an erroneous document root communicated to CGI components such as PHP or mod_perl can lead to problems. We're still following Nginx development, in case things evolve.
We used something just like that to map users' home directories, but it doesn't solve the problem of not being able to set a unique root directory for each user case. Nginx accepts just one root dir setting, and it can't be conditionally set (or overwritten in a later if-else scenario) by putting it inside a location clause. One solution is to globally set /home as the definite root for all user location cases, but this does not sit alright with me - the document root should just not sit outside the target's home.
I wasn't aware that this was a Q&A or issues tracker for Nginx, which is why I never had the intent of bringing details up. My apologies for posting these things in the official Nginx resources. The sarcasm is on the house.
One problem that comes to mind is Nginx' inability to have multiple root dirs set for one and the same host depending on what location directive will be in use, for example when wanting to set unique root dirs during userdir mapping - which also happens to be something that Nginx can't do as properly as Apache. Another problem I can recall is how some configuration scenarios require an abundance of PCRE matching clauses to fulfill, which in turn causes Nginx a tangible but most noticable delay for each request that happens to match the implied regexp portion. I am not sure why this is the case, and I am not sure why it isn't so in Apache, where regexp clauses introduce no noticable stall.
Did I hit a nerve of some zealous Nginx user when mentioning the fact that Nginx isn't a silver bullet? :) I'm sure you can downvote this comment, too! Knock yourself out!
Looking forward to a day when I can give Nginx another try when its feature set has matured in more directions. Its unfortunate lack of fine-grained versatility in some areas of configuration forced us to stick with Apache's httpd after trying to replace an old Apache setup with Nginx - everything looked much better in terms of resource efficiency, until we hit the problem of simply not being able to translate a few specific configuration scenarios from Apache to Nginx, forcing us to deem Nginx as a definite no-go for our case.
The proper term for this effect is "raster bars", from how you traditionally did the effect by waiting for the raster line register to hit a certain vertical position on the screen, and then changing f.e. the background color of that scanline, then wait for the next line, change the color again etc. The name "copper bars" came out of the Amiga scene from how you could easily and without involving the CPU do this effect (and much more) on the Amiga using one of its co-processors, nicknamed the "Copper".