On Apr 6, 2012 3:58 AM, "Branko Čibej" <br...@apache.org> wrote: > > On 06.04.2012 09:51, Daniel Shahaf wrote: > > Branko Čibej wrote on Fri, Apr 06, 2012 at 08:06:32 +0200: > >> This makes me wonder if we couldn't perhaps keep the whole thing as an > >> in-memory-not-disk-backed SQLite database, then encrypt and dump the > >> whole SQLite memory snapshot to disk. The real trouble with that > >> approach is that debugging the database using the SQLite command-line > >> tools would be impossible, everything would have to happen through the > >> SVN API. > > Presumably we'd write a tools/dev/ helper that decrypts the memory > > snapshot and dumps it to an on-disk SQLite db? > > This really has other problems, too. Actually, /any/ passphrase-based > system we use has it: "in-memory" does not, by itself, imply that the > unencrypted data never end up on disk. At the very least, the > unencrypted bits need to be stored in locked, access-protected memory, > so that they don't get swapped out and can't be accessed by (non-root) > users. > > OS-provided password storage systems typically already account for this. > And, whilst Subversion doesn't take these precautions with individual > passwords, a passphrase that protects a number of different credentials > needs more attention to preventing plaintext leaks.
Yeah, I switched the master passphrase param to an svn_string_t on the probable outcome that we would immediately SHA1 the thing, and then use the resulting hash as the nominal password. That would avoid having the plaintext in memory (and yes, I recognize it is quite possible that other copies exist; gotta start somewhere, and provide a data flow that avoids the requirement of plaintext). Cheers, -g
