Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

share_keys() marks outbound Megolm session as shared despite failed Olm session establishment — silent key loss, no recovery

Ouverte
  • Quelque chose ne va pas ?
#186 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
30/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
python
Domaine
cryptography

Piste de recherche

Commencez par suivre share_keys() à travers le gestionnaire de chiffrement et l’état crypto_megolm_outbound_session décrit dans l’issue, en utilisant l’avertissement "No one-time keys nor device keys got when trying to share keys" comme point d’échec. Déterminez comment un établissement Olm échoué mène à shared=1 et définissez si l’achèvement nécessite de réessayer avec les appareils en attente, de conserver une session non partagée ou d’emprunter une autre voie de récupération.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

In mautrix-python 0.21.1, when the crypto manager shares a newly-created outbound Megolm session via share_keys(), a failure to establish an Olm session with a recipient device (e.g. the device has no claimable one-time keys) does not prevent the outbound session from being marked as shared. The share failure is only visible as a mau.crypto logger warning ("No one-time keys nor device keys got when trying to share keys"), which is easy to miss — from that point on, every message encrypted under that outbound session is undecryptable for the affected device, with no room-key request sent by the client and no built-in recovery path.

Observed behaviour (production, 4 episodes Jul–Sep 2026)

Gateway-style bot (the Hermes agent's Matrix platform adapter, which uses mautrix-python for E2EE) running against matrix.org, in encrypted rooms with a user holding 3 active devices:

  1. Process restart → new outbound Megolm session created for the room.
  2. During the initial share_keys(), one or more devices have no available one-time keys. Pairs of warnings are logged: 
    WARNING mau.crypto: No one-time keys nor device keys got when trying to share keys
    (two warnings per retry — observed 2–6 warnings per episode)
  3. The outbound session is nevertheless marked as shared (shared=1 in crypto_megolm_outbound_session) and all subsequent room messages are encrypted under it.
  4. Affected devices show m.unable_to_decrypt for every later event in the room. The sessions created before the restart remain readable — only the new outbound session's traffic is lost for the omitted device.
  5. The state persists until the outbound Megolm session is discarded and a new one is created after the affected devices have uploaded fresh one-time keys.

Traces from a live episode (2026-09-01, UTC):

01:54:10 WARNING mau.crypto: No one-time keys nor device keys got when trying to share keys
01:54:11 WARNING mau.crypto: No one-time keys nor device keys got when trying to share keys
01:57:37 WARNING mau.crypto: No one-time keys nor device keys got when trying to share keys
...
15:36:32  (new outbound Megolm session created, shared=1, message_count>0)
16:26:37 WARNING mau.client.crypto: Failed to decrypt $...: Failed to decrypt megolm event: no session with given ID <id> found
Expected behaviour

Either (a) the outbound session should not be marked shared while any recipient device failed to receive the key, with the share retried when the device comes back online / uploads OTKs, or (b) the omitted device's client should issue an m.room_key_request that the sender fulfils, per the standard key-recovery path. Today neither happens: the failure is silent at the protocol level, so recovery depends entirely on application-level workarounds.

Suggested directions
  • Return a per-device success/failure result from the share step and let the caller decide whether to keep or rotate the session.
  • Track "pending share" devices on the outbound session and retry the Olm-transport of the room key when the device reappears (OTK claim succeeds), instead of only warning.
  • On decrypt failure with OLM_PREKEY missing, consider prompting a room-key request from the affected side (this may be more natural at the client layer, but a library hook would help).
Workaround used (application level)

Discard the outbound Megolm session row while the process is restarting (the session is cached in memory by the running crypto manager — deleting the DB row while running gets it resurrected from cache), ensure the user's devices have uploaded fresh one-time keys (opening the client suffices), then have any member send a message so a fresh session is created and shared. Verified working, but it requires application-level surgery on the crypto store and a coordinated restart — not something every deployment can do.

Environment
  • mautrix-python 0.21.1 (latest release as of 2026-09-01)
  • Python 3.13, Linux, matrix.org homeserver
  • Bot account with cross-signing verified, store version 10
  • Affected clients: Element X (iOS/iPadOS), Element macOS — i.e. current, maintained clients
Langage dominant
Python
Étoiles
250
Forks
85
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de mautrix/python

Toutes les issues de mautrix/python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.