element-hq / element-hq/element-web

regression: failure to recognize a verified device if it has an empty device_keys.algorithms array

Open
#30,709 11 comments 0 reactions 0 assignees View on GitHub
A-E2EE A-Session-Mgmt O-Uncommon S-Minor T-Defect Team: Crypto
Dominant language
TypeScript
Stars
13.5k
Forks
2.8k
PR merge metrics
PR metrics pending

Description

### Steps to reproduce

Recent versions of Element Web are reporting a device with correctly signed keys as unverified, if its `device_keys.algorithms` array happens to be empty.

This regression was apparently introduced some time after v1.11.92. That version (and every earlier version I tried) recognizes such devices as verified.

### Outcome

#### What did you expect?

I expected newer versions of Element Web to recognize that the device's keys are uploaded, consistent, and properly signed, and therefore display it as a verified device. Just as Element Android and earlier versions of Element Web do.

#### What happened instead?

Recent Element Web versions fail to recognize the device as verified.

#### Why is this a bug?

Because clients exist that do not participate in message encryption/decryption, but still need to log in on the user's behalf in order to do their job. (For example, an unread message indicator like [messageflag](https://codeberg.org/forestix/messageflag).) In order to avoid annoying the user with "verify your device" warnings and scaring their contacts with red shield icons, these devices must show up as verified.

The spec says the `algorithms` field is required, but does not forbid it from being empty. This makes sense, for the reason stated above (some clients will never support message decryption).

https://spec.matrix.org/v1.15/client-server-api/#post_matrixclientv3keysupload

Common chat clients generally populate the `algorithims` array with two values: `m.olm.v1.curve25519-aes-sha2` and `m.megolm.v1.aes-sha2`. Adding one or both of these to the array (and signing the device keys) sort of works around the problem, in that it convinces Element Web to display the device correctly. However, neither of these is suitable for a client of the kind described here, because those values indicate support for Olm and Megolm encryption, which clients like this do not support.

https://spec.matrix.org/v1.15/client-server-api/#molmv1curve25519-aes-sha2

https://spec.matrix.org/v1.15/client-server-api/#mmegolmv1aes-sha2

Adding a nonsense value like `foo` to the array works around the problem as well, demonstrating that these newer Element Web versions are complaining about something that they clearly don't need.

So, I think this regression is clearly a bug.

### Operating system

_No response_

### Browser information

_No response_

### URL for webapp

_No response_

### Application version

Element version: 1.11.110, Crypto version: Rust SDK 0.13.0 (f64839e), Vodozemac 0.9.0

### Homeserver

matrix.org

### Will you send logs?

No

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.