-
Notifications
You must be signed in to change notification settings - Fork 750
Description
When working with an encrypted database, my library needs to ensure that none of the fetched-then-dropped data from the database stays resident in the client's heap (where it can be found by a memory scanner). So, for example, if a query returns an iterator over fetched row data, I need the fetched data for the prior row to be zeroized when the next row is requested from the iterator.
Similarly, if database fetch works by buffering fetched data in re-allocated slices, then any data in a re-allocated-and-freed slice would need to be zeroized once it's copied to the new allocation.
The same constraint applies to any data copied into database buffers when executing insert and update queries. Once the query has been executed, any of the data not directly held by client references should be zeroized before being dropped.
Ideally, data would be zeroized as soon as neither the client nor the database held a reference to it. But as long as there's a documented, client-driven discipline for when the data will be zeroized, clients can probably adapt. For example, if all the buffered data associated with a given connection were zeroized when the connection was closed, clients could be careful not to hold connections open when they are not being used.