Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#186 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
30/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
cryptography

Direção de pesquisa

Comece rastreando share_keys() pelo gerenciador de criptografia e pelo estado crypto_megolm_outbound_session descrito na issue, usando o aviso "No one-time keys nor device keys got when trying to share keys" como ponto de falha. Determine como um estabelecimento Olm malsucedido leva a shared=1 e defina se a conclusão exige tentar novamente com dispositivos pendentes, manter uma sessão não compartilhada ou seguir outro caminho de recuperação.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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
Linguagem predominante
Python
Estrelas
250
Forks
85
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de mautrix/python

Todas as issues de mautrix/python

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.