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)
copied to disk by the OS (this could be a problem
even if you otherwise have a good handle on clearing malloc() blocks).
Regards,
Bill
-Original Message-
From: Max Vlasov [mailto:max.vla...@gmail.com]
Subject: [sqlite] Best way to wipe out data of a closed database
Hi,
in an application
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
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
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
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
Hi,
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. So no side
application could retrieve sensitive information by reading this
process memory. Not only
7 matches
Mail list logo