For some reason webpack seems to not be transpiling that properly.

Fixes: https://github.com/jitsi/lib-jitsi-meet/issues/1722

An alternative to Insertable Streams, currently implemented in Safarii / WebKit.

https://w3c.github.io/webrtc-encoded-transform/

Fixes: https://github.com/jitsi/jitsi-meet/issues/9585

remove legacy APIs which are not even supported anymore

Get rid of noisy logs related to SDP transformations which are redundant. Fix formatting and add missing information.

Drop end to end signature. The impersonation attack vector is deemed out of
scope since insiders are already part of the meeting.

When E2EE is disabled we need just set the last key to `false`. When decoding we
need to check if the last key is not false, otherwise we might try to decrypt
the unencrypted video frames, thus resulting in breakage.

- After ratchet do not set it as new key for current index. Set it to correct position in crypto ring.

Signs and verifies frames. For now this is done on every frame.
This is not the long-term goal and there needs to be a better strategy.

and add a few new ones.

and make them a bit more concise. No functional changes

this uses the full four bits in the wire format. The wire format
looses the (currently not implemented) extensibility with variable
length keys.

Both for just encode function as well as an end-to-end test.

to allow writing tests

in particular this allows sharing the ratcheting between the E2EEncryption
module and the Worker.

similar to what is explained here:
  https://tools.ietf.org/html/draft-omara-sframe-00#section-4.3.5.1
but we do it on authentication tag failures since it is not possible
to tell whether decrypt.

this needs to be called with an Uint8Array, not an ArrayBuffer

refactor the signature checking to make it clear when we need to ratchet.
This is similar to
  https://tools.ietf.org/html/draft-omara-sframe-00#section-4.3.5.1
but we verify the hash before attempting to decrypt.

following
  https://tools.ietf.org/html/draft-omara-sframe-00
but putting the frame metadata into a trailer instead of a header.
We call this JFrame.

Also the key we get from OLM is high entropy so we do not need
to use PBKDF2 but can use HKDF instead. See
  https://wiki.developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/deriveKey#HKDF

This the second stage in our E2EE journey.

Instead of using a single pre-shared passphrase for deriving the key used for
E2EE, we now establish a secure E2EE communication channel amongst peers.

This channel is implemented using libolm, using XMPP groupchat or JVB channels
as the transport.

Once the secure E2EE channel has been established each participant will generate
a random 32 byte key and exchange it over this channel.

Keys are rotated (well, just re-created at the moment) when a participant joins
or leaves.

Avoid having to use a code blob.

see https://bugs.chromium.org/p/chromium/issues/detail?id=1119653
We'll probably do similar renaming in the future.

Moves the logics which deal with JitsiConference events to a separate module.

which landed in
  https://bugs.chromium.org/p/chromium/issues/detail?id=1069295#c4

derived from the participant id in addition to the salt, separated by a null
byte to avoid ambiguity attacks along the lines of
  (someRoom, someParticipant)
  (someRoo, mSomeParticipant)

as suggested during the community call recently

moves the cryptography bit to a datastructure which allows per-sender keys.
Does not yet use per-sender keys.

Also fixes lots of lint errors in the worker.

currently unused, will allow moving to per-participant keys

Mobile breaks otherwise, since creating those types of URLs are supported.

Moveѕ e2ee operations to a worker that is included as text/blob for now
to simplify deployment.

If we are encrypting and the key index from a (potentially unencrypted)
frame exceeds our key ring size (1 currently) drop the frame.

This is a heuristic. We currently don't have the signaling for whether a
remote end does encrypt its frames or not.