Managing persistent values

otrv4 / pidgin-otrng

Fork of https://bugs.otr.im/plugins/pidgin-otr. This is a mirror of https://bugs.otr.im/otrv4/pidgin-otrng

GNU General Public License v2.0

16 stars 5 forks source link

Managing persistent values #72

Closed claucece closed 5 years ago

claucece commented 5 years ago

Some ideas:

if the private key file is deleted, the client profile, prekey profile and prekey messages should be regenerated as well.
if the forging key file is deleted, the client profile and (maybe) prekey profile should be regenerated as well.
if the shared prekey file is deleted, the prekey profile should be regenerated as well.
if the prekey messages are deleted should we deleted the published ones as well?

olabini commented 5 years ago

Actually, if the private key file is deleted, we don't need to regenerate the prekey messages. They will still be valid. And with regard to the forging key, if that file is deleted, we can still get the public key value from a client profile - so we only need to regen the forging key if both client profiles AND the forging key file is gone. We probably don't need to regen the prekey profile in this case

About prekey messages - yeah, if we notice that we don't have as many prekey messages locally as are published for us, then something is definitely wrong - we should probably try to drain the prekey messages from the prekey server to get back to a good state.

claucece commented 5 years ago

Thanks @olabini

It should be then:

if the private key file is deleted, the client profile and prekey profile should be regenerated as well.
if the forging key file is deleted get it from the client profile.
if the shared prekey file is deleted, the prekey profile should be regenerated as well.
if the prekey messages are deleted, delete the published ones as well
if the client profile is deleted, get its info from the current priv key if there is
if the prekey profile is deleted, get its info from the current shared prekey if there is

claucece commented 5 years ago

As discuss, the functionality to check for validity should be done the moment you read the persisted data, but we should have a timer that checks for this validity as well. I've been thinking that when we want to start a conversation; we should also check for the validity of data; but do no publishing/writing action if it is wrong, just fail (for example, if the long-term public key is invalid, just fail and not generate a new one and write it to a file).

claucece commented 5 years ago

@olabini @giovaneliberato @DrWhax thoughts?

olabini commented 5 years ago

Yeah, sounds good to me. So we have two different functions - one that "ensures", including reading from disk, creating stuff - and another that "verifies" and just returns failure if something is incorrect. The second one should ideally be used before most OTR actions are taken.

DrWhax commented 5 years ago

No extra thoughts, I agree with the idea outlined here.

olabini commented 5 years ago

Basically all of this functionality is there now. The only thing is we don't delete messages on the server if they are deleted locally. I'm not sure how to do this in a good way, honestly, and whether it makes sense. I'll close this for now.

claucece commented 5 years ago

The only thing is we don't delete messages on the server if they are deleted locally. I'm not sure how to do this in a good way, honestly, and whether it makes sense.

What we perhaps need to do, is show a good error message for the user in this case. I don't think we are showing anything at all.