Alistair Crooks <a...@pkgsrc.org> writes: >> What's the threat model this is protecting against? Presumably, if a >> user can execute the program, and the program can read his keys, the >> uesr can already read his own keys, so having a core dump doesn't give >> the user information he didn't already have. > > Heh, yeah, it's not really to do with keys, much more the passphrase, > which is dynamically allocated in a number of places in the library, > and I haven't finished auditing all of the places just yet. I've > added code to zero out that memory after use when I can - some more > are still needed.
Fair enough -- the passphrase (and the unencrypted private key for that matter) is never supposed to hit the disk, so you've identified a threat this addresses. I'd suggest having a flag that stops the behavior, though, to make debugging less irritating. > The threat that I'm protecting against here is that of information > disclosure coming from committing the passphrase to disk in a core > dump. By that token, it would be of use for NetBSD to port over the encrypted swap features other OSes have (it should be essentially no performance hit), and I think it would also be nice if NetBSD could zeroize or randomize RAM on voluntary shutdowns. Neither, of course, is a NetPGP issue. > I'd really recommend source-changes-full for reviewing the changes > that are made - the setrlimit(2) call is only made in the driver > program, not the library. That I got already. Perry -- Perry E. Metzger pe...@piermont.com
