Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support modification times on changes and new entries #140

Open
charliemb2 opened this issue Oct 19, 2023 · 0 comments
Open

Support modification times on changes and new entries #140

charliemb2 opened this issue Oct 19, 2023 · 0 comments

Comments

@charliemb2
Copy link

The rationale for supporting modification times is as follows.

File-level syncing has risks. These risks include losing access to all of your passwords. A single bit error in a saved file could/should cause a checksum error in an encrypted file. Such an error makes the entire file unreadable. If this file is blindly propagated at the file-level, whether by sneaker-net or cloud storage apps, all devices will lose access to all passwords.
Single bit errors can happen for many reasons, bad memory on a computer, bad drive or thumb drive, unreliable internet connections, caching problems with cloud storage, OS updates breaking apps, etc. If you search the internet for keepass and sync errors you will see that the list never seems to end.

However, while other solutions can be proposed, such as telling each and every family member to make regular backups (will everyone do it religiously?, will I always?), one solution is appealing: namely to have one of the devices run a database manager (alongside PfP) that supports entry-by-entry sync; I'll use the original KeePass application as an example of this. KeePass supports, entry-by-entry sync. And the sync can be from multiple files saved at different times and from different devices. All conflicts will be resolved as long as modification times are respected by developers. Then after incorporating all changes in KeePass, that file can then be blindly replicated to all other devices without fear of complete loss of all passwords and site data.

Should a kdbx database file contain one or more bit errors during KeePass' entry-by-entry sync, the sync is aborted saving the integrity of the file stored locally on the KeePass machine. All that is lost are the updates in the bad file. This file stored locally on the KeePass instance should be treated as immutable / export-only / and excluded from blind file-level syncing.

With this as one solution, files can then be automatically and blindly synced at the file level for all other machines except for the KeePass/PfP machine. This can be done with Syncthing, cloud storage, or other. (For now I've been using LocalSend, which is cross-platform FOSS and works beautifully while keeping all kbdx files offline and away from any cloud storage provider.) When something goes wrong, there is a way to recover without manual entry by entry procedures.

TL:DR ... Entry-by-entry syncing, and its advantages, can coexist with PfP without PfP being responsible for them. They can be done externally with another application. However, this is only possible if PfP supports modification times on changes and new entries. Users who understand the need for, or insist on, entry-level syncing can still use PfP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant