Feature: Lock state file without exiting

[malexmave]

Sometimes it may be desireable to lock the pond state file without exiting the program (e.g., when running a permanent instance of pond in a screen instance on your server / a raspberry pi).

This is probably a quick change, but I am not familiar with the Go Language.

[agl]

Sorry, do you mean unlock? Normally the statefile should be locked whenever Pond is running. There was a bug where it became unlocked after the first save, but that's fixed in git now.

Unlocking the statefile while Pond is running would be bad and would probably lead to messages getting lost. Would running with --cli and screen work for you?

[malexmave]

Sorry, I was using the wrong terminology. I meant the following: Once I start pond, I have to enter a passphrase to decrypt the statefile. I would like to be able to re-encrypt the statefile and go back to the passphrase prompt without closing down pond. An analogy would be the "lock database"-Function of KeePass or the "Lock Screen" function of any OS.

[agl]

Pond could not function in the background while the state file was locked (unless the "locking" is just cosmetic and the process is operating on the plaintext in memory). Did you have a cosmetic lock in mind, or do you just wish to have the program running as if just started?

[malexmave]

In this case, I'd that the added convenience of having a specific persistent screen-instance is probably not worth the work if the program can't continue its network operations in the background (which would come in handy, but probably be too insecure). I'll let decide if you think it is worth the work regardless and close the ticket accordingly.

[burdges]

In principle, one could create a "transact only" mode for pond in which pond retained only the user's public identity key, and maybe the private one too, but not their passphrase or message public keys or contact information including ratchets :

• Any outgoing messages were encrypted and queued to actually be sent, but marked only as "probably sent" in the state-file. Upon return from "transact only" mode pond would check the actual send results of all "probably sent" messages.
• Any incoming server reply packets would be retrieved from the server using the user's identity key. They could not be decrypted to determine if they contained incoming messages or just random noise until pond returned from "transact only" mode.

In particular, pond would record about 4 megs of garbage per day that it'd need to process when it returned from "transact only" mode, but that number might increase if pond's frequency of contacting the server was ever increased from the average of 5 min.

There is an important issue about such a "transact only" mode : If authorities raided your pond while in "transact only" mode, then they would still gain access to your identity key. Assuming said authorities had hacked the pond server previously, this would allow them to determine the number, sizes, and timings of all pond messages you received, which could provide evidence as to an activist's importance or such.