Use TS in tests and fix type definitions of decryptMessageLegacy, decryptMIMEMessage
#127
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
larabr
changed the title
decryptMessageLegacy and decryptMIMEMessagedecryptMessageLegacy, decryptMIMEMessage
larabr
changed the title
decryptMessageLegacy, decryptMIMEMessagedecryptMessageLegacy, decryptMIMEMessage
twiss
reviewed
Oct 11, 2021
| @@ -4,6 +4,11 @@ const protonmailCryptoTailMessage = '---END ENCRYPTED MESSAGE---'; | |||
| const protonmailCryptoHeaderRandomKey = '---BEGIN ENCRYPTED RANDOM KEY---'; | |||
| const protonmailCryptoTailRandomKey = '---END ENCRYPTED RANDOM KEY---'; | |||
|
|
|||
| /** | |||
| * Extract armored encrypted message from email | |||
| * @param {String|Object} EmailPM | |||
There was a problem hiding this comment.
I know the function kinda sort accepts it, but do we ever pass an object here? If not I don't really think we should start explicitly allowing it now. Maybe we can even get rid of the checks at some point
Suggested change
| * @param {String|Object} EmailPM | |
| * @param {String} EmailPM |
| @@ -14,6 +19,11 @@ export function getEncMessageFromEmailPM(EmailPM) { | |||
| return ''; | |||
| } | |||
|
|
|||
| /** | |||
| * Extract (legacy, custom) armored encrypted random key from email | |||
| * @param {String|Object} EmailPM | |||
There was a problem hiding this comment.
Idem
Suggested change
| * @param {String|Object} EmailPM | |
| * @param {String} EmailPM |
| @@ -50,7 +50,7 @@ export async function decryptMessage(options) { | |||
| } | |||
|
|
|||
| // Backwards-compatible decrypt message function | |||
| // 'message' option must be a string! | |||
| // `options.message` must be a string, to properly handle legacy messages (and avoid misusing this function) | |||
There was a problem hiding this comment.
As written, it kind of sounds like it only needs to be a string if you care about legacy messages, which is true - but I would rather change that and remove the checks, so that this function always throws for other types, so that we enforce this rather than write a comment about it.
Suggested change
| // `options.message` must be a string, to properly handle legacy messages (and avoid misusing this function) | |
| // `options.message` must be a string |
There was a problem hiding this comment.
Let's change the behaviour in a separate PR, to keep this one about TS fixes only 👍
twiss
approved these changes
Oct 12, 2021
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.
decryptMessageLegacy,decryptMIMEMessageto accept a string input message (used to accept aMessageinstead).avato v3 to support its typescript integration.