rini17
5 hours ago
Unless you can ensure your whole stack always rewrites data in place, this is good for a compliance checklist at most. Both modern journalling filesystems and underlying storage such as SSD can now permanently write copies of data in various locations that will be kept even if the file is rewritten.
Either encrypt whole device. Or as stopgap measure, periodically overwrite all free space on device. For ext2, ext3 and ext4 there's zerofree tool, btrfs defrag can do it, other filesystems have own tools.
SQLite
2 hours ago
Correct.
"Secure delete" is sufficient to prevent forensic traces from persisting in the database file itself. So you could, for example, send the database file over a TCP/IP link after a secure delete and no deleted data would be transmitted.
"Secure delete" is sufficient to remove traces from the database file itself, but it is not sufficient to remove deleted data from the underlying SSD. That was known from the beginning and should be mentioned in the documentation; if it is not then the documentation needs to be enhanced.