| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
Pass the received image data through gcrypt to do the decryption
using the previously received keys.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
|
| |
For encrypted images the decrypted message contains key information
to decrypt the actual media once received.
Add a structure and a parser to extract the information from the JSON.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
Add a purple action (i.e. thing on the accounts->matrix-> menu)
to display the device ID and public key.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
| |
Cleanup on closing the plugin or leaving a conversation.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
| |
Update sessions stored in the db after starting sessions.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
| |
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
Keep a hash/list of olm sessions in memory and load them from the db
if we find we haven't got one.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
| |
Parse the decrypted JSON and route it back up to the room code.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
Decrypt m.room.encrypted messages sent to a room;
these come out with normal events.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
Decrypted olm messages of type m.room_key create inbound megolm
sessions.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
|
| |
Attach to the room storage for inbound megolm sessions.
TODO: Store to db
TODO: Clean up this list in matrix_room_create_conversation
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
Check the decrypted messages have matching keys/devices etc
before parsing them any further.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
Create an olm inbound session and use it to decrypt the message.
Later patches will handle storing/retrieving the OLM sessions.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
| |
Parse the top level of m.room.encrypted messages.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
|
|
| |
We're going to need a:
database of olm sessions
a device trust database
a database of megaolm sessions
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
Parse the key upload return to see if we need to send any one time
keys.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
| |
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The server returns the count of one-time-keys that it has,
we parse that and detect if we need to send more.
It's a little tricky in that a server that doesn't have
any keys will send an empty response, so force sending in
that case.
If we get to the point of multiple types of keys this will
need reworking to make sure we only send the key types needed.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
|
| |
If we've got a previously stored olm account state then use it,
else create us a new one.
Either way, upload the device keys to the server.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Parse the output of olm_account_identity_keys to get a list of
algorithms and the keys for them.
There really should be a better way; the algorithm names in here
match what we need in the keys section, but we have to append
the device id later, so it's a pain that it returns (undocumented)
JSON.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
Allocate a blob of memory and fill it with random data.
(There must be some existing portable function for this?!)
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
| |
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
The OLM account state can be 'pickled'; we store this in Purple's
account data store as a JSON string.
Note; OLM lets us encrypt the pickle, but we've got no key to encrypt
it with; I don't think Purple has anything for wiring into the
system key store.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
We can't rely on having memset_s, so add our own equivalent that
declares itself volatile.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
Given a JsonObject, produce a canonical json blob, sign it and
add the signature back into the JsonObject.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
|
|
Somewhere for the e2e magic to happen.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
