-
Notifications
You must be signed in to change notification settings - Fork 52
refresh keys from EKM except removed keys #4477
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
Conversation
36d3f0e to
bc092e7
Compare
da83c05 to
f49b12a
Compare
|
This pull request introduces 1 alert when merging 39228cb into 0a6bf7c - view on LGTM.com new alerts:
|
tomholub
left a comment
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.
early review
| getFilesInDir(`${sourceDir}/common/core/crypto/smime`, /\.js$/, false), | ||
| getFilesInDir(`${sourceDir}/common/api/shared`, /\.js$/, false), | ||
| getFilesInDir(`${sourceDir}/common/api/key-server`, /\.js$/, false), | ||
| getFilesInDir(`${sourceDir}/js/common/platform`, /\.js$/, false), |
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.
I'm a bit baffled about how and when the directory got shifted.
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.
Likely by one of the linked files importing some additional dependency that is outside /js folder. Is that possible?
Could likely find out by looking at the sourceDir directory at the moment it gets built, and see what other content is there outside of the js folder.
tomholub
left a comment
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.
From code, this looks correctly implemented, nevertheless I have some comments for improvements, for code clarity and also functionality. Thanks!
extension/js/content_scripts/webmail/setup-webmail-content-script.ts
Outdated
Show resolved
Hide resolved
extension/js/content_scripts/webmail/setup-webmail-content-script.ts
Outdated
Show resolved
Hide resolved
…key with valid lastModified
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.
I forgot to submit my review earlier, so here are some unsubmitted comments from before. From the look of it, I could probably merge it before these are resolved. I'll take one more look and potentially merge it now.
| if (passphrase === undefined && !existingKeys.length) { | ||
| return { needPassphrase: false, updateCount: 0 }; // return success as we can't possibly validate a passphrase | ||
| // this can only happen on misconfiguration | ||
| // todo: or should we throw? | ||
| } |
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.
Is this a situation in which the user has no keys set up on their account?
In this situation, we could allow any pass phrase to be used, as long as it has sufficient strength, like during setup. We could in fact probably just send that user to the setup screen where all the necessary UI is already present. What do you think? (it's exactly what we do on iOS anyway)
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.
Yes, exactly, no keys set up is a misconfiguration.
Send the user from gmail page to setup? By changing window.location? Or opening another tab? I can try it.
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.
You could try another tab, if no local keys & some remote keys exist now. That may work ok without upsetting the user.
| const { privateKeys } = await keyManager.getPrivateKeys(idToken); | ||
| if (privateKeys.length) { | ||
| await processKeysFromEkm(acctEmail, privateKeys.map(entry => entry.decryptedPrivateKey), factory, ppEvent); | ||
| } |
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.
We should do the update in all cases, including when EKM returns 0 private keys. In that situation, all users keys should be removed from the browser extension. (they no longer have access to them).
It may cause the extension to misbehave, which we can improve later. But anyways, their keys should indeed be removed.
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.
Oh, I was adhering to this specs: // stage 4 - modified key gets updated, removed key does not get removed in FlowCrypt/flowcrypt-ios#841
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.
I wasn't very clear in the issue definition - sorry. I've tried to also point to FlowCrypt/flowcrypt-ios#1559 but may have been confusing. Anyway, I've filed an issue for it now at #4596
| return result; | ||
| }; | ||
|
|
||
| export const processAndStoreKeysFromEkmLocally = async ( |
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.
I haven't seen any code doing removals of private keys. When EKM no longer returns a particular key, the browser extension should forget the key too. Unless the the local version of that private key is revoked, in that case the extension should not forget the fact that it was revoked (and I suppose could keep the revoked private key too, if that's the simplest way to implement it).
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.
Right, there aren't any removals, I was adhering to this specs: // stage 4 - modified key gets updated, removed key does not get removed in FlowCrypt/flowcrypt-ios#841
As for revocations, we are storing revoked keys' fingerprints in a separate table revocations forever (and optionally the revoked private keys there too), so no need to worry.
This PR sends a query to EKM for private keys on content scripts initialization
close #2602
Tests (delete all except exactly one):
To be filled by reviewers
I have reviewed that this PR... (tick whichever items you personally focused on during this review):