sfttech / aiomatrix Goto Github PK

A number of one time keys have to be stored permanently on the server.

No long term handling implemented yet.

After the initial device key uploads about 100 OTKs are uploaded. They can be checked via the get_otk_count() function that yields the current amount of otks which come as a reply in the sync() message.

The class attribute subscriber_list has to be updated for every new event that wants to be parsed. A default dict would get rid of that.

However, maybe it is required to be forced to manually add the new event to the eventManager and the filter.

Hi! I'm developing client library for matrix in Python and wanted to publish it on PyPi as aiomatrix but found your library. It looks abandoned, so I thought it's okay to ask if you could rename your PyPi package.
Could you please change your library name to aiomatrix-py or something like that?

This is an important endpoint to offer for rooms especially for encryption purpose.
A room can only be set to "encrypted mode" (sending m.room.encryption event) by having Administrator (100) right, therefore if the API user creates the room using room.create_room() nobody apart from the API user can set the room to encrypted. Might be interesting to offer this functionality also regarding the possiblility of writing "guarding bots".

Create a config file that defines specific parameters that are now either set in the Session class itself or passed in the init like 'save_directory_path' or 'supported_encryption_version'

At the moment, everytime we share our MegOlm session key with one of the members of the room, we initiate a new OlmSession.
Riot, for example, uses (if possible) an existing olm session with the user that has been used before.
The current implementation is not wrong, however, it might be better to go for the Riot approach.

Things to change (theoretically):

• Check whether there's already a valid/known olm session in the self.session.olm_sessions list
• then encrypt the meg olm session keys using this session and set the message 'type' field to 1 (instead of 0 == prekey message)

Rooms are not static. Users are leaving, joining and changing their devices.

These events are not yet implemented.
Old keys have to be removed, new keys have to be added and distributed on user leave/join.

At the moment everything is implemented and tested in a secure environment. Everything is implemented for when "everything goes well".

Required: More checks of incoming parameters and handling the errors/wrong messages in a way that does not lead to DoS.

At the moment you do not get information e.g. error messages from coroutine task you add to the loop. Task management required.

At the moment, the own OutboundGroupSession (stored in self.meg_ses) triggers pickle of the whole self.room_keys after every sent of a message. This creates a lot of overhead if there are a lot of rooms and a lot of users in them.

Possible solutions:

• Only pickle the meg_ses after every sent (not the whole list)
• Pickle the whole list only within the destructor of the room object (which would be best)

Might be interesting to make it possible to use the API without encryption.

At the moment, as soon as you create a session the whole Olm Account/Key handling takes place including saving/uploading of new keys. Maybe a flag/paramter to indicate no encryption required.

One major problem is, that the PreKey event (parsed by the filter class and distributed by the eventManager class) is not room based.
It can't be, because the room information is part of the encrypted content of the message (see below).

At the moment, every room object listining for prekey message events get the message, creates an olm session and decrypts it just to realize that this message might not be for him. I also think that it might cause problems due to the fact that multiple olm sessions are created with the same initial message (don't know if that causes issues, short workaround would be to remove the subscription as soon as you receive an correct olm message, however, this would cause problems if a olm session in future is renewed for this room)

Therefore, one idea would be to have a Encryption class that takes are of creating olm sessions and distributing the decrypted prekey messages to the relevant rooms. This Encryption class could also take care of the storing/pickling/loading of the room keys.

Also, the strict separation of lowlevel (JSON parsing) and highlevel is broken at the moment. The PreKey class accesses the JSON itself despite being a high level class. That's another reason for a lowlevel Encryption class.

{
"sender":"@ebnera:in.tum.de",
"sender_device":"IXSABTUFJC",
"keys":{"ed25519":"0Bk1QwAj2a4+E9ZNbL6szC0qj9JcScVIpdrNI5ZTowU"},
"recipient":"@fuhhbarmatrixtest:matrix.org",
"recipient_keys":{"ed25519":"qGUDoyysVcD3wgQZk6fu0aJNm01IeVn9m5WsJ09diok"},
"type":"m.room_key",
"content":{
"algorithm":"m.megolm.v1.aes-sha2",
"room_id":"!pvAiYjulqdNNXdjfHT:in.tum.de",
"session_id":"MEXyh8flJdc1nHRCbT6UEpM3ySL3lyVJk2lLkdN+sPA",
"session_key":"AgAAAAApKLafaR2+c+TS1pxnVeOIykeS4xiuABE7QDBofTGdUD0x7MvhCcYNyqsPWgtLzMuO+J+EK68KYY+HFaxY8cTOQgd/ZOGlCiSAa/+OhzDd/+Xk4f0mEkjehOVxQnPfWK1zTVhRKZN9DOUAXWtpfppbzaGX1tQz0LQVvDAflGR3DTBF8ofH5SXXNZx0Qm0+lBKTN8ki95clSZNpS5HTfrDwTHJAr0UN7w1aPMXi7H+rmeJxNZhmUQiptU9hmy6BF6ZpCHFEjN19s0TN2STAUF0oKkjeDnDZpU1okbVoBhOdCA",
"chain_index":0
}
}

The partner sends us the prekey and the m.room.enrypted message of the first room message almost at the same time.
The sync() reads both events in one HTTP response and puts both into the corresponding event loops.
Due to the fact that we have an asynchronous behavior it can happen that we are trying to decrypt the message before the prekey message is handled. Therefore, at the moment, we have this workaround:

        if not meg_ses:
            await asyncio.sleep(5)
            meg_ses = self.room_keys.get((message[1], sender_device_id, session_id))

Maybe a better solution can be found to synchronize the events.