-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make sure source fingerprint is updated on sync #1092
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, approved. I will wait for someone who reproduced the issue to verify the patch in their Qubes system. Then we can merge.
@@ -170,6 +170,7 @@ def update_sources( | |||
lazy_setattr(local_source, "is_starred", source.is_starred) | |||
lazy_setattr(local_source, "last_updated", parse(source.last_updated)) | |||
lazy_setattr(local_source, "public_key", source.key['public']) | |||
lazy_setattr(local_source, "fingerprint", source.key['fingerprint']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this change makes sense and I see why this fixes #1091 because the issue was that new sources don't always come with a key and fingerprint, so we need to make sure we update the key and fingerprint every sync. I have to verify this, but my guess is that the server still creates sources during a "source surge" without new keys, and instead of waiting until the keys are generated, the server tells the client about the new sources ahead of time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just needs a unit test for this case:
- A new source is returned from the server without a key or fingerprint
- The replybox is disabled
- A sync happens with the source, and this time it has a key and fingerprint
- The replybox is enabled
Test added. |
It was missing from the list of attributes updated on existing sources, so a source which had no key when first synced would never be completed, even once the keypair were generated on the server, and journalists would never be able to reply to them.
Add a test to check that ReplyBoxWidget will be disabled when constructed for a source that doesn't yet have a key pair, then enabled when the source's key arrives via sync.
424dd12
to
54d5118
Compare
Looks good, if you add one more assertion to your test then you'll have added a regression check: diff --git a/tests/gui/test_widgets.py b/tests/gui/test_widgets.py
index f3884ff..abf50f2 100644
--- a/tests/gui/test_widgets.py
+++ b/tests/gui/test_widgets.py
@@ -4211,6 +4211,7 @@ def test_ReplyBoxWidget_enable_after_source_gets_key(mocker, session, session_ma
rbw._on_synced("synced")
# ... and the widget should be enabled
+ assert rbw.source.fingerprint
assert rbw.source.public_key
assert rbw.replybox.isEnabled()
assert rbw.text_edit.isEnabled()
This currently fails on master |
Yep, thanks. Both are also checked in |
Description
It was missing from the list of attributes updated on existing sources during sync, so a source which had no key when first synced would never be completed, even once the keypair were generated on the server, and journalists would never be able to reply to them.
Fixes #1091.
Test Plan
Tough to test manually, as the failure is dependent on a new source being synced before having its keypair generated.
Checklist
If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:
If these changes add or remove files other than client code, the AppArmor profile may need to be updated. Please check as applicable:
If these changes modify the database schema, you should include a database migration. Please check as applicable:
master
and confirmed that the migration applies cleanlymaster
and would like the reviewer to do so