Since we don't interpret these notations, it is up to the caller
to handle them, and thus also to decide whether they are "known".
If they are marked as critical, and aren't handled by the caller,
we should consider the signature unverified.
Assign most signature subpacket types a criticality based on whether
failing to interpret their meaning would negatively impact security.
For Notation Data subpackets, let the user indicate their criticality
using the `signatureNotations[*].critical` property.
The changes do not affect the public API:
`RandomBuffer` was used internally for secure randomness generation before
`crypto.getRandomValues` was made available to WebWorkers, requiring
generating randomness in the main thread.
As a result of the change, the internal `getRandomBytes()` and some functions
that use it are no longer async.
Move the Issuer, Issuer Fingerprint, and Embedded Signature subpackets
to the hashed subpackets for new signatures. While we allow these to be
unhashed, it's safer to hash them, and this simplifies the code as well.
When re-serializing a signature packet, don't add Issuer, Issuer
Fingerprint, and Embedded Signature subpackets to the unhashed
subpackets if they weren't already there.
Also, store all unhashed subpackets in `signature.unhashedSubpackets`,
not just the "disallowed" ones.
Signing a `CleartextMessage` containing trailing whitespace and \r\n line
endings (as opposed to \n) would result in an unverifiable signature. The issue
seems to have been present since v3.0.9 . These broken signatures were
unverifiable even in the OpenPGP.js version(s) that generated them.
Recent Node.js seems to have dropped support for ripemd160.
Thus, properly check the availability of hashes before using them.
Also, add Node.js 18 to CI.
Calling `openpgp.decrypt` with a message that contains encrypted session keys
followed by a non-encrypted packet (e.g. Literal or Compressed Data packet)
used to succeed, even if a wrong passphrase/key was provided.
With this change, the operation will always fail, and the user is warned that
the data was not encrypted.
NB: a message that did not contain any encrypted session key packet would fail
to decrypt even prior to this change.
