Skip to content

Conversation

@rrrooommmaaa
Copy link
Contributor

@rrrooommmaaa rrrooommmaaa commented Jun 6, 2022

This PR sends a query to EKM for private keys on content scripts initialization

close #2602


Tests (delete all except exactly one):

  • Does not need tests (refactor only, docs or internal changes)
  • Difficult to test (explain why)
  • Not worth testing
  • Tests will be added later (issue #...)
  • Tests added or updated

To be filled by reviewers

I have reviewed that this PR... (tick whichever items you personally focused on during this review):

  • addresses the issue it closes (if any)
  • code is readable and understandable
  • is accompanied with tests, or tests are not needed
  • is free of vulnerabilities
  • is documented clearly and usefully, or doesn't need documentation

@rrrooommmaaa rrrooommmaaa force-pushed the issue-2602-pull-from-ekm branch from 36d3f0e to bc092e7 Compare June 13, 2022 06:53
@rrrooommmaaa rrrooommmaaa force-pushed the issue-2602-pull-from-ekm branch from da83c05 to f49b12a Compare June 28, 2022 12:41
@lgtm-com
Copy link

lgtm-com bot commented Jul 3, 2022

This pull request introduces 1 alert when merging 39228cb into 0a6bf7c - view on LGTM.com

new alerts:

  • 1 for Incomplete regular expression for hostnames

Copy link
Collaborator

@tomholub tomholub left a 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),
Copy link
Contributor Author

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.

Copy link
Collaborator

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.

@rrrooommmaaa rrrooommmaaa marked this pull request as ready for review July 11, 2022 12:38
Copy link
Collaborator

@tomholub tomholub left a 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!

Copy link
Collaborator

@tomholub tomholub left a 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.

Comment on lines +92 to +96
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?
}
Copy link
Collaborator

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)

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Comment on lines +274 to +277
const { privateKeys } = await keyManager.getPrivateKeys(idToken);
if (privateKeys.length) {
await processKeysFromEkm(acctEmail, privateKeys.map(entry => entry.decryptedPrivateKey), factory, ppEvent);
}
Copy link
Collaborator

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.

Copy link
Contributor Author

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

Copy link
Collaborator

@tomholub tomholub Aug 10, 2022

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 (
Copy link
Collaborator

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).

Copy link
Contributor Author

@rrrooommmaaa rrrooommmaaa Aug 10, 2022

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.

tomholub
tomholub previously approved these changes Aug 10, 2022
@tomholub tomholub enabled auto-merge (squash) August 10, 2022 14:35
@tomholub tomholub changed the title refresh keys from EKM refresh keys from EKM except removed keys Aug 10, 2022
@tomholub tomholub merged commit 415f80b into master Aug 10, 2022
@tomholub tomholub deleted the issue-2602-pull-from-ekm branch August 10, 2022 14:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

re-pull keys from the EKM periodically

3 participants