CopyQ icon indicating copy to clipboard operation
CopyQ copied to clipboard

Manually deleting the last item in an encrypted tab does not remove the data from the `.dat` file

Open dominicpalmer opened this issue 1 year ago • 3 comments

Describe the bug Say we have an encrypted tab with 5 items. On opening the UI and deleting 4 of the items, the .dat file is updated accordingly, such that on force close and restart, the deleted items will not be (and can't be) reloaded into the tab list.

However, deleting the last item does not result in any change to the .dat file. The deleted item's encrypted data is still there, and so on force close and restart, the item is loaded back into the tab list again. This is an issue - the data should be gone.

Interestingly after deleting the final item and then adding a new item to the list does result in an update to the .dat file. In this scenario, the deleted item will not be reloaded on restart.

To Reproduce Steps to reproduce the behavior:

  1. Copy 5 items into an encrypted tab.
  2. Delete 4 of the items.
  3. Verify that the .dat file in the saved items directory is updated, then force restart CopyQ and check that the 4 deleted items aren't reloaded into the tab list.
  4. Delete the final item.
  5. The .dat file should have been updated again, to remove the encrypted data of the final item. However it hasn't changed. Now force restart CopyQ again. The final item that should have been deleted will be incorrectly reloaded into the tab list.

Note, the issue is also reproducible if all items in the tab are deleted together. In this scenario, no data is removed from the .dat file, and on restart all of the items are restored.

Version, OS and Environment

  • CopyQ 7.0.0
  • gpg4win-2.0.4.exe
  • Windows 10

dominicpalmer avatar Jul 29 '23 22:07 dominicpalmer

I cannot reproduce the issue - though I'm testing this on Linux.

Is there anything in the logs (F12 shortcut from the main window)?

BTW, the data files are not saved immediately but with a delay or on exit. There could be rare cases when the app is terminated forcefully without not being able to run any cleanup code. In such cases the unsaved data will be lost.

Note, the issue is also reproducible if all items in the tab are deleted together. In this scenario, no data is removed from the .dat file, and on restart all of the items are restored.

I will fix this issue - the empty encrypted tab is not being saved.

Thanks for the report.

hluk avatar Aug 22 '23 11:08 hluk

At the point of deleting the last item and exiting CopyQ, this is what's logged:

CopyQ ERROR [2023-09-10 13:46:33.067] <Server-14688>: Tab “&clipboard”: Failed to save tab (save items to temporary file), file “C:/Users/Dom/AppData/Roaming/copyq/copyq_tab_JmNsaXBib2FyZA==.dat”: Writing canceled by application
CopyQ Warning [2023-09-10 13:46:49.356] <Server-13000>: [default] QtWarning: QSystemTrayIcon::setVisible: No Icon set
CopyQ ERROR [2023-09-10 13:46:51.769] : ItemEncrypt ERROR: GnuPG stderr:
CopyQ ERROR [2023-09-10 13:46:51.769] :    gpg: key <key>: already in secret keyring
CopyQ ERROR [2023-09-10 13:46:51.769] :    gpg: Total number processed: 1
CopyQ ERROR [2023-09-10 13:46:51.769] :    gpg:       secret keys read: 1
CopyQ ERROR [2023-09-10 13:46:51.769] :    gpg:  secret keys unchanged: 1

I've noticed a few other scenarios where deleting items doesn't update the .dat file quickly enough, and on restarting CopyQ they'll be restored. I think it would be more secure for data files to be updated immediately. This is to cover all edge cases.

E.g. let's say a user copies multiple passwords to sign in to some services. Then, a colleague or friend unexpectedly arrives at their desk to collaborate. The user deletes all the stored items and exits CopyQ. But while collaborating, the user needs to access CopyQ again. The user should be absolutely certain that reopening CopyQ will not display the deleted passwords. But a delay approach risks that happening.

dominicpalmer avatar Sep 10 '23 13:09 dominicpalmer

I've noticed a few other scenarios where deleting items doesn't update the .dat file quickly enough, and on restarting CopyQ they'll be restored.

Strange, that would indicate that CopyQ did not close in a clean manner, otherwise it would save all pending changes.

CopyQ ERROR [2023-09-10 13:46:33.067] <Server-14688>: Tab “&clipboard”: Failed to save tab (save items to temporary file), file “C:/Users/Dom/AppData/Roaming/copyq/copyq_tab_JmNsaXBib2FyZA==.dat”: Writing canceled by application

Are you using the recent version 7.1.0? I believe the error above was fixed.

I think it would be more secure for data files to be updated immediately.

You can modify the delay for saving tabs with the following options (listed here from copyq config including the default values):

save_delay_ms_on_item_added=300000
  Tab save delay after an item is added to the tab
save_delay_ms_on_item_edited=1000
  Tab save delay after an item is edited in the tab
save_delay_ms_on_item_modified=300000
  Tab save delay after an item is modified in the tab
save_delay_ms_on_item_moved=1800000
  Tab save delay after an item is moved in the tab
save_delay_ms_on_item_removed=600000
  Tab save delay after an item is removed from the tab

For example to save tab immediately after an item is removed:

  1. Open Action dialog with F5 key.
  2. Enter the following command: copyq config save_delay_ms_on_item_removed 0
  3. Press OK button.

hluk avatar Sep 12 '23 14:09 hluk