Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Remove the capability to send and receive unencrypted

Aperta
  • Qualcosa non va?
#8,775 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Hocuri ci sta già lavorando.

Dal 7/10/2026.

  • #8808 di @Hocuri — aperta
  • #8809 di @Hocuri — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
api, backend, security

Direzione di ricerca

Start by mapping the core migration, legacy Securejoin handling, ForceEncryption configuration, and the listed APIs and types. Read the relevant core code and existing migration or messaging tests first. Done means unencrypted messages are no longer sent or received, existing data is rewritten as specified, obsolete APIs and UI-dependent code are removed, and the migration behavior is tested.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

We would like to remove the capability to send and receive unencrypted messages/emails. This is both in order to have a simpler and safer security model that encrypts without exceptions, and to be able to implement new features more easily since the whole concept and complexity is easier.

first round, UI and user facing:

  • In the UIs, the password needs to be visible, so that users can switch away from DC to a classical MUA. Already in progress: https://github.com/deltachat/deltachat-android/pull/4717 https://github.com/deltachat/deltachat-ios/pull/3338 https://github.com/deltachat/deltachat-desktop/issues/6806
  • In core: A migration that rewrites unencrypted chats into encrypted ones; the new 0-member groups will get the gray letter icon as an avatar and a fake, deterministically generated group-id (i.e. the group-id should be the same on all devices, if possible).
    • all unencrypted (i.e. ad-hoc) groups into regular groups with 0 members.
    • all unencrypted 1:1 chats into a group with 0 members. (that turned out to be unnecessary; can_send() will return false simply because there is no key)
    • all chats of type Mailinglist into a group with 0 members.
    • all address-contacts into a key-contact with "Hidden" origin, and with a fake key fingerprint. We still need the contacts because we want to keep the messages, and every message needs a sender.
      • We should make sure that the address is available somewhere, e.g. by explicitly setting the name of these contacts to their email address (or appending the email address if there is a name already)
      • Users can try and send a message to these contacts or add them to a group, but it will fail since there is no key (we should test that this is actually the case).
      • If this turns out to be hard, we try something else, like rewriting the messages to all come from some "ghost" contact.
  • A device message that is added into the "Device messages" chat. We might also put a system message into every migrated chat. At the same time, the "Force Encryption" config is removed from the UIs, and it is always enabled for everyone. The device message says something like

    We are removing support for unencrypted messages. You can still see old messages, but not send or receive them. Please use a different application for your emails; if you need it, you can see your email password in Delta Chat at "Settings -> Advanced -> Relays -> Tap or right-click on your email address -> Edit Relay". See https://... for more details.

  • Remove APIs for is_encrypted, is_key_contact, Chattype::Mailinglist and show_padlock/showpadlock, and have the UIs adapt
  • In UIs, remove all the now-unused code and UI elements that was only needed if ForceEncryption is off
  • It needs to be announced publicly in a blog post.
  • what to do with legacy blog posts and forum posts, eg. https://delta.chat/en/2021-05-05-email-compat

second round, core cleanup, we want to have that soon, but not necessarily required immediately, if larger refactorings are needed

  • In core, remove support for legacy Securejoin, which sends the first message unencrypted. This means that getting into contact via QR codes or links will be incompatible with versions before core v2.45.0, which was released 6 months ago (on Android, it was released on 2026-03-24, on Desktop on 2026-03-30, and on iOS, on 2026-03-31).
    • We could defer this step a bit, but then we need to keep around quite some code that is needed for these unencrypted messages
    • If we want, on scanning a legacy Securejoin QR code, we can show an error message like

      This QR code or link was generated with an outdated version of Delta Chat. Please ask this person to update Delta Chat, and then give you a new QR code.

  • In core, remove all the code that was needed for unencrypted messages, which includes:
    • is_encrypted
    • is_key_contact
    • Encryption::No
    • Param::ForcePlaintext and Param::GuaranteeE2EE
    • We can also remove ChatAssignment::AdHocGroup, but we need to consider the case of an encrypted email being sent with a classical MUA to multiple recipients. The simplest approach is to just assign it to the 1:1 chat. In this case, we can also get rid of setting mime_references in the database, lookup_chat_by_reply(…), ChatAssignment::ExistingChat, all calls to grpid.is_empty(), and SyncId::Msgids.
      • A this point, References: headers will only be used for an ephemeral timer rollback protection (https://github.com/chatmail/core/commit/085a899de2a0284d7217d97d295a3dfdead48c46). We may be able to remove it since we already have EphemeralSettingsTimestamp. Then, we can stop sending and receiving References: headers, which will also make every outgoing message a bit smaller. (we may need it in the future e.g. for message-ordering, but this should not affect what code we remove now; we can easily re-add it later.)
Lingua principale
Rust
Stelle
937
Fork
150
Merge medio
1g 21h
PR unite (30g)
76

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di chatmail/core

Tutte le issue di chatmail/core

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.