New users without published OMEMO keys break groups/circles

[wilecoyote2019]

I created a self hosted server, everything worked fine. When it started it creates a group named chat.myserver.com But I added a user, mainly i have generated a link (using command line) test@chat.myserver.com, but the user has never joined the application. I have deleted that user (using web interface). Now it is impossible for users to send messages to the group chat.myserver.com. When I try it shows a screen asking to validate the fingerprints, but the user test@chat.myserver.com is present in the list and it says "No valid key is available for this user. [....]".

Now nobody can send messages to that group but I can create other groups and add all the users.

Strange thing is that now this users appear twice in the android app, but when I open the web admin interface the user is not present.

Server : Debian 10

[resoli]

Had the same problem. The user never sent a message to others, so they never had a chance to get his fingerprint. Deleting a user should remove him from group chat as well. Workaround: recreate the same user, remove it from the default circle, re-delete it.

[mwild1]

Steps to reproduce:

1. Create a new user but don't log in (e.g. create an account in the browser)
2. User gets added to circle MUC, but does not yet have any keys published
3. Other users' (Android) clients cannot fetch keys for the new member, and refuse to send messages to the group

Removing the user from the circle or them logging in would correct the issue.

Possible solution: postpone circle membership grants until initial join attempt.

[horazont]

Possible solution: postpone circle membership grants until initial join attempt.

Mind that this also needs to work when the server admin adds the "incomplete" user to another circle post-registration. This smells as if we maybe need circle half-memberships consist of:

• An autojoin bookmark
• Some internal state which notes the membership (i.e. the mod_groups_internal membership)

The autojoin bookmark will trigger a join attempt by the clients, and then mod_muc_?? needs to:

1. Check if the user is allowed to join per standard '45; if they are, exit this routine and proceed with join.
2. If the user is banned from the MUC, reject the join attempt (maybe?).
3. Check for an associated circle; if no circle is associated, reject the join attempt.
4. Check if the user is member of the associated circle. If yes, add them to the MUC members and let them join the MUC.

[mwild1]

Proposal:

• If setting an affiliation of ("member"/"admin"/"owner") of a JID that was previously ("none"/"outcast")

• If the MUC is a private MUC (for Snikket we can assume this implies encrypted)

• Check whether the user has OMEMO keys published

  • OMEMO keys published: allow the affiliation to be set as normal
  • OMEMO keys not published: cache the pending affiliation change and do not proceed

• When processing a join to a private MUC:

• If the user is not affiliated, check the pending affiliation cache

• If there is a pending affiliation for the user, check if they have OMEMO keys published

  • OMEMO keys published: set the affiliation for real and process the join
  • OMEMO keys not published: reject the join with an error