Refactor & simplify the handling of the packet stream and errors in
packet parsing & grammar validation.
This PR also makes the following observable changes:
- Packet parsing errors in not-yet-authenticated streams (i.e. SEIPDv1
with `allowUnauthenticatedStream: true`) get delayed until the
decrypted data stream is authenticated (i.e. the MDC has been
validated)
- Non-critical unknown packets get turned into `UnparseablePacket`
objects on the packet stream instead of being ignored
- The grammar validation internals are changed to a state machine where
each input packet is only checked once, for efficiency (before, the
entire partial packet sequence was checked for every packet)
Co-authored-by: larabr <larabr+github@protonmail.com>
It enforces a message structure as defined in
https://www.rfc-editor.org/rfc/rfc9580.html#section-10.3
(but slightly more permissive with Padding packets allowed in all cases).
Since we are unclear on whether this change might
impact handling of some messages in the wild, generated by
odd use-cases or non-conformant implementations, we
also add the option to disable the grammar check via
`config.enforceGrammar`.
GrammarErrors are only sensitive in the context of
unauthenticated decrypted streams.
In case of equal creation timestamps, pick the signing/encryption subkey
with the highest algorithm ID, on the assumption that that's the most
modern/secure algorithm.
The tests work correctly in Epiphany, but not in the WebKit build,
where the native X25519 implementation throws non-standard errors on
importKey (DataError) and generateKey (OperationError).
Patching this would be simply a matter of catching such errors and falling back
to the JS implementation, but since only the CI WebKit build seems to be
affected, we prefer not to relax fallback checks in the context of crypto
operations without issues reported in the wild.
Reverting commit ccb040ae96acd127a29161ffaf3b82b5b18c062f .
Firefox has fixed support in v132 (https://bugzilla.mozilla.org/show_bug.cgi?id=1918354)
usage of v130 and 131, which have a broken implementation, is now below 1%.
Also, Chrome has released support in v133.
iOS tests sometimes fail to start due to some "server disconnect" issue on BS side.
This seems more prominent on certain devices (e.g. iPhone 16 with iOS 18).
So, we also change the 'iOS latest' target to a more stable one.
To avoid issues with the lightweight build:
for now it works fine, but it could mess up chunking in the future,
and it already results in a circular import.
The existing md5 module brought in the util module,
which messed up the chunking structure in the lightweight build;
inlining those functions is an option, but the noble-hashes code
is also more modern and readable.
Every submodule under the 'crypto' directory was exported-imported
even if a handful of functions where actually needed.
We now only export entire modules behind default exports if it makes
sense for readability and if the different submodules would be
imported together anyway (e.g. `cipherMode` exports are all needed
by the SEIPD class).
We've also dropped exports that are not used outside of the crypto modules,
e.g. pkcs5 helpers.
This adds back support for decrypting password-protected messages which
were encrypted in OpenPGP.js v5 with custom config settings
`config.aeadProtect = true` together with
`config.preferredAEADAlgorithm = openpgp.enums.aead.experimentalGCM`.
Public-key-encrypted messages are affected if they were encrypted using the same config, while also providing `encryptionKeys` that declared `experimentalGCM` in their AEAD prefs.
Such keys could be generated in OpenPGP.js v5 by setting the aforementioned config values.
`experimentalGCM` should not be used anymore,
as a different a different algorithm ID was standardized
for GCM, and using the experimental value could give
interoperability issues with e.g. SEIPDv2 and AEAD-encrypted keys.
We could also drop the browser's directive `"./dist/node/openpgp.min.cjs": "./dist/openpgp.min.js"`,
since that build cannot be used with `require()`, and it's instead meant
to be the target of <script> tags.
But we keep it around for now to avoid potentially breaking changes, in case it's
used in some setups.
The `expect().to.not.throw` check as written is a no-op.
In fact, `throw` should have been called as a function.
We drop the relevant check altogether since if the wrapped
operation throws, the test will naturally fail due to the
unexpected error.
