deltachat-core-rust icon indicating copy to clipboard operation
deltachat-core-rust copied to clipboard

Exporting private keys silently overwrites existing files (and does not provide filenames being used)

Open fleish opened this issue 1 year ago • 4 comments

I am testing out DeltaChat and found that exporting private keys does not allow the user to name the files and if files by the same names (private-key-default.asc & public-key-default.asc) already exist in the target location they will be silently overwritten with no prompt or ability for the user to save the existing or rename the new files.

  • Operating System: Mac
  • Delta Chat Version: 1.44.1 (git: v1.33.0-669-gc878fc787)
  • Expected behavior: provide filename being used and/or prompt if files already exist and would be overwritten
  • Actual behavior: no notice about what filename is being used and/or prompt if files already exist and will be overwritten
  • Steps to reproduce the problem: open app -> settings -> advanced -> export private keys -> save
  • Screenshots: n/a
  • Logs: n/a

fleish avatar Jun 16 '24 16:06 fleish

This is a core issue, it's imex::export_key_to_asc_file() deleting a file if it already exists. I agree that at least files mustn't be deleted silently. EDIT: not marking as a bug, though this intended behaviour looks strange to me.

iequidoo avatar Jun 16 '24 22:06 iequidoo

"export keys" does not export a file, but a number of files (one can have several keys, also public keys are exported additionally), therefore providing a filename is not useful, it is okay to ask for a directory.

prompting is of course doable, however, requires to change APIs and all UIs and our limited resources are probably spent better elsewhere (note: we are in "advanced" so in "not recommended/encouraged workflow" - and for keys, this is even more true, most ppl do not know what to do with these keys anyways :)

however, the filenames are pretty specific already, so in real-world probably only sth. exported before by delta chat gets overwritten.

one can imagine some confusion wrt multi-profile, of course. the following improvements may be easy and are reasonable even for an "advanced" feature:

  1. we can make the filenames more specific by adding the email address to the filename, same as we did for backups recently

  2. we can tweak the message before exporting to "Export secret keys to DIR? Previously exported keys will be overwritten.". but maybe that is already over the top when 1. is done

r10s avatar Jun 17 '24 11:06 r10s

We will eventually need a new (JSON-RPC only) API to list keys and export secret/public keys for each key. At least when we start adding crypto-refresh/v6 keys, each user will have two keys, one v4 and one v6, so better debugging tool will be necessary.

link2xt avatar Jun 17 '24 16:06 link2xt

  1. we can make the filenames more specific by adding the email address to the filename, same as we did for backups recently

  2. we can tweak the message before exporting to "Export secret keys to DIR? Previously exported keys will be overwritten.". but maybe that is already over the top when 1. is done

I'd say, instead of "2" we could add a suffix "-DATE-EXPORT_NUMBER" like we do for backups. So, basically generate file names the same way as for backups. Then we don't need to overwrite files.

iequidoo avatar Jun 26 '24 16:06 iequidoo