Re: [sqlite] Best way to wipe out data of a closed database

On Mon, Oct 24, 2016 at 4:28 PM, Wade, William wrote: > It sounds like you've got a way forward on leaks via the malloc() system > within the process space. > > 1) The region of the C process stack that was reached by some deep call stack. > 2) Processor registers. > 3)

Re: [sqlite] Best way to wipe out data of a closed database

It sounds like you've got a way forward on leaks via the malloc() system within the process space. Be aware that depending on your system (and the attackers' capabilities), you might have to worry about other leaks. For instance, if I did a query that involved a FLOAT index, and then closed

Re: [sqlite] Best way to wipe out data of a closed database

On Mon, Oct 24, 2016 at 1:36 PM, Richard Hipp wrote: > > Memsys5 is also faster than your global system memory allocator > (before the extra overhead of zeroing, at least). But on the other > hand, you have to know the maximum amount of memory SQLite will want > at the very

Re: [sqlite] Best way to wipe out data of a closed database

Simon, thanks never heard of secure_delete, interesting, but probably no use in case of VFS Layer that leaves only encrypted data on disk. As for zero-malloc option, it looks promising. On Mon, Oct 24, 2016 at 1:34 PM, Simon Slavin wrote: > > On 24 Oct 2016, at 9:58am, Max

Re: [sqlite] Best way to wipe out data of a closed database

On 10/24/16, Max Vlasov wrote: > > One of the trick possible is to add additional zeroing out to the > global free handler, but this can probably introduce performance > penalties. > > Is there any other way to do this? If you set up to use memsys5 at compile-time

Re: [sqlite] Best way to wipe out data of a closed database

On 24 Oct 2016, at 9:58am, Max Vlasov wrote: > in an application that implements encryption/decryption with VFS, what > is the best way to ensure that the memory of the application doesn't > contain decrypted data after the database is closed. We can't answer about memory