summaryrefslogtreecommitdiff
path: root/bugs/lock-key-in-ram.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'bugs/lock-key-in-ram.mdwn')
-rw-r--r--bugs/lock-key-in-ram.mdwn23
1 files changed, 0 insertions, 23 deletions
diff --git a/bugs/lock-key-in-ram.mdwn b/bugs/lock-key-in-ram.mdwn
deleted file mode 100644
index a65396a..0000000
--- a/bugs/lock-key-in-ram.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!tag obnam-wishlist]]
-
-Joey asked:
-
-<joeyh> have you done anything in obnam to deal with it needing to keep
-the symmetric key, decrypted, in RAM?
-
-<joeyh> yeah, it's tough. probably could be avoided by having gpg decrypt
-the passphrase and pipe it to the encrypting gpg .. but then gpg would
-constantly be using the public key
-
-It might be possible to have a C extension that holds the symmetric
-key, locks it into RAM, and feeds it to gpg whenever necessary,
-via a file descriptor.
-
---liw
-
-
-I'm going to be switching from running gpg for symmetric encryption
-in the future, anyway. I'll be doing symmetric encryption in-process
-using python-crypt, and that means a lot of the sensitive data is going
-to be in Python strings anyway. Locking anything in memory doesn't seem
-feasible. [[done]] --liw