On-demand migration of sources' private keys to database-backed storage upon login #6802
Assignees
Milestone
Comments
14 tasks
This was referenced May 17, 2023
|
Likely the main work here is that pretty_bad_protocol (AFAICT) doesn't already have a function to export private keys, so that will need to be done as part of this task, whether in p_b_p or just separately and directly calling GPG. |
legoktm
added a commit
that referenced
this issue
Aug 3, 2023
As part of the Sequoia migration, we want to export secret keys out of the GPG keyring and into our new database storage. So, have the gpg.export_keys() function accept a passphrase to export encrypted keys that GPG wants a passphrase for. Internally we switch it to use the `_handle_io` function since that has support for taking passphrases; the one weird thing is that it requires an input file (e.g. if you were encrypting a file) but since there's no input here an empty temporary file works just fine. For whatever reason I couldn't get a simple `p.stdin.write(passphrase)` to work, it would hang on stdout, which is probably related to the pre-existing comment about "stdout will be empty in case of failure"... A new test generates a new GPG key pair, exports the public and secret keys from the keyring and then encrypts and decrypts a message using Sequoia to test compatibility. TODO: test error cases like incorrect fingerprint, incorrect passphrase, etc. Refs #6802.
4 tasks
legoktm
added a commit
that referenced
this issue
Aug 7, 2023
As part of the Sequoia migration, we want to export secret keys out of the GPG keyring and into our new database storage. So, have the gpg.export_keys() function accept a passphrase to export encrypted keys that GPG wants a passphrase for. Internally we switch it to use the `_handle_io` function since that has support for taking passphrases; the one weird thing is that it requires an input file (e.g. if you were encrypting a file) but since there's no input here an empty temporary file works just fine. For whatever reason I couldn't get a simple `p.stdin.write(passphrase)` to work, it would hang on stdout, which is probably related to the pre-existing comment about "stdout will be empty in case of failure"... A new test generates a new GPG key pair, exports the public and secret keys from the keyring and then encrypts and decrypts a message using Sequoia to test compatibility. It also checks a few error cases like invalid fingerprint and missing secret key. Refs #6802.
This is implemented in #6907. |
legoktm
added a commit
that referenced
this issue
Oct 4, 2023
legoktm
added a commit
that referenced
this issue
Oct 5, 2023
For the final part of the GPG->Sequoia migration, we export sources' secret keys out of GPG and into database-backed storage for use with Sequoia/redwood functions. Because we don't have access to a source's GPG passphrase, we can only do this migration when they log in. If everything has been successfully migrated, then we delete the GPG key out of the keyring as well. Tests have been added that cover the pre-existing keypair generation code and the new secret key migration. Fixes #6802.
8 tasks
github-project-automation
bot
moved this from In Progress
to Done
in SecureDrop dev cycle
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As part of our work to migrate to Sequoia, we will migrate sources' private keys on-demand when they log in to the database-backed storage.
As discussed in #6499, gpg stores keys in their own encrypted format, and we need the source's passphrase to unlock them, so we can't do it offline (like the public key migration). The plan is that when a source logs in, we'll see that they don't have a private key in the database, so we'll try to export their private key from gpg and then store it in the database in the armored and encrypted OpenPGP format.
The text was updated successfully, but these errors were encountered: