fix gpg key import / replies / encrypt to source on qubes #377
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
this also simplifies parts of our gpg wrapper, which we should keep as feature limited as possible and expand only when we need to - we don't need to support importing private keys, nor can we easily get the fingerprint that is imported without brittle parsing of stdout (stdout is significantly different between qubes and other platforms so we'd need to maintain it on both - much simpler to use the fingerprint that the server provides for us).
the -o- option cannot be passed through the qubes gpg wrapper, and ciphertext will go to stdout regardless
|
closed #375 and removed blocked label, this should be ready for review |
|
👍 Both local and (hours later 😉) Qubes scenarios worked as described. I was able to reply with no errors logged, and the reply persisted across multiple syncs. |
kushaldas
suggested changes
May 21, 2019
There was a problem hiding this comment.
In my Qubes setup, I can see error messages like:
2019-05-21 18:13:16,319 - securedrop_client.logic:621(send_reply) ERROR: Failed to encrypt to source f482a492-2e35-4229-9d95-bfbc2d09f49f:
@redshiftzero Can you please tell me how to debug more?
|
Steps to debug:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #363
The reviewer of this PR should test this on both Qubes and non-Qubes. If you need/want additional clarity on how to test please let me know and I will happily elaborate on any unclear parts of the test plans below.
Testing on non Qubes
developPOST /api/v1/sources/<source uuid>/repliesendpoint)Testing on Qubes
Make sure you have applied the RPC policy change merged in rpc policies: allow sd-svs to get sd-gpg to import gpg keys securedrop-workstation#254. If you like you can test this part works by trying to import a key from
sd-svsintosd-gpg. Note that if you see some error output containing a note aboutno-ttywhen you try to import a test gpg key, you will need to apply the (unreleased) fix merged today over in Qubes land: GpgImportKey: pass --no-tty through to gpg invocation QubesOS/qubes-app-linux-split-gpg#23.Next, make sure your staging server is running on anything after this server-side API change was merged: api: expose gpg fingerprint of source securedrop#4436.
In your dev env in
sd-svsAppVM on Qubes, check out the branch in this PR (I attach a NetVM to mysd-svsAppVM for dev purposes), run the client application (without passing—no-proxyto the client invokation), monitor the logs, and verify that:qubes-gpg-client: unrecognized option '--import-options’error described in gpg key import not working in Qubes #363