Skip to content

Comments

auto include pubkey based on rules discussed in #3445#3487

Merged
tomholub merged 6 commits intomasterfrom
issue-3332-auto-include-pubkey
Mar 17, 2021
Merged

auto include pubkey based on rules discussed in #3445#3487
tomholub merged 6 commits intomasterfrom
issue-3332-auto-include-pubkey

Conversation

@rrrooommmaaa
Copy link
Contributor

@rrrooommmaaa rrrooommmaaa commented Mar 16, 2021

This PR is part of #3332 refactoring
It implements "auto include pubkey" feature based on
this comment #3445 (comment)

close #3491

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.

Excellent! Thank you for splitting it out. Some comments below.

export class ComposeMyPubkeyModule extends ViewModule<ComposeView> {

private toggledManually = false;
private wkdLongids: { [acctEmail: string]: string[] } = {};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is preferable to compare fingerprints over longids whenever possible - fingerprints are slightly more secure, and there is no advantage using longids.

The only place that makes sense to use longids is when looking up public keys of a signed message, because the signature only contains a longid. Similarly encrypted message only mentions longid of the key it's encrypted for. In all other situations, let's use fingerprints.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, but I had to parse the KeyInfo.private field as we don't currently have the primary fingerprint there, only longid and a set of all fingerprints. Or do we have to do a "must include all fingerprints" check? Also, do we need to attach our key only if "Sign" option is ticked?

for (const recipient of foreignRecipients) {
// new message, and my key is not uploaded where the recipient would look for it
if (! await this.view.recipientsModule.doesRecipientHaveMyPubkey(contact.email)) {
if (! await this.view.recipientsModule.doesRecipientHaveMyPubkey(recipient)) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doesRecipientHaveMyPubkey seems like it would be better to place it in this file and not in recipients module, but hard to say for sure without opening the IDE, and not overly important

}
// if recipient uses same domain, we assume they use flowcrypt
const pgpClient = this.myOwnDomain === recipientDomain ? 'flowcrypt' : 'pgp-other';
const pgpClient = this.myOwnDomain === Str.getDomainFromEmailAddress(email) ? 'flowcrypt' : 'pgp-other';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose we'll be dropping pgpClient from everywhere. If you want to chunk up the upcoming PR, this could also be done in a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's drop it in the PR #3445 that actually "deletes" the client field from the database. This branch still attempts to store it.

}

public static getDomainFromEmailAddress = (emailAddr: string) => {
// todo: parseEmail()?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think parseEmail would be sensible here, and throw if it returns "undefined"

tomholub
tomholub previously approved these changes Mar 17, 2021
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.

Looks good, should I merge it?

@rrrooommmaaa
Copy link
Contributor Author

Looks good, should I merge it?

This test compose - auto include pubkey is inactive when our key is available on Wkd fails on the enterprise mock setup.
Do we have to configure hosts additionally?

@tomholub
Copy link
Collaborator

Looks good, should I merge it?

This test compose - auto include pubkey is inactive when our key is available on Wkd fails on the enterprise mock setup.
Do we have to configure hosts additionally?

From memory, enterprise extension has a more restricted manifest file which means we have to list the mock domains in manifest file. Or in OS hosts files, or both. Is it possible to use an existing mock domain that some other tests use? Just a different user on the same domain? If yes, please try that to limit amount of external configuration needed for the tests.

@tomholub tomholub merged commit 5b3f4dd into master Mar 17, 2021
@tomholub tomholub deleted the issue-3332-auto-include-pubkey branch March 17, 2021 20:02
@rrrooommmaaa
Copy link
Contributor Author

Enterprise is still failing to access Wkd at google.mock.flowcryptlocal.com:8001

@tomholub
Copy link
Collaborator

I fixed that tests on master now.

@tomholub tomholub added this to the 8.0.4 milestone Mar 25, 2021
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.

Drop pgpClient from all lookupEmail results

2 participants