>...the attacker is already able to read the process’s address space. The rest of us here are saying that, in that case, as far as we’re concerned the attacker has already won.
I understand that. What I'm saying is your standard is not nuanced. Applying a security standard that amounts to best practice web server administration is insufficient for all environments. Extra care is warranted where compromised apps can be installed alongside yours. Maybe there is no exploit to take over the app or host but there could be very good ones for your app to assist in eavesdropping and boosting social engineering attacks. The goal should be "secure in the wild" rather than merely secure on the server. A bit of reading reveals how the most spectacular SQLite exploits so far occurred in desktop and portable environments marketed as a platforms for users to commingle apps of their choice and quality. Therefore, a more realistic security threat standard comes from imagining an environment where unknown threats and partially effective countermeasures are presently in a precarious stalemate equilibrium. Introducing an app with secure in isolation but unorthodox implementation may not have the secure in the wild guarantee that is expected. At this point I've got no dog in this fight. The new pointer API is now fairly complete and can be mechanically patched to use a more sensible key type. Serious implementors anticipating widespread desktop or mobile deployment can do this easily for themselves. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
