It would be great if Vault UI had the ability to import existing vaults, that would make thing more accessible for more casual users and when you sync different devices. I was however able to achieve just that by copying ~/.config/plasmavaultrc from my pc i did the vault setup on. I'm running the latest KDE Neon (with latest updates) on both my devices. Thank you for a really great job on Vault!
*** Bug 387090 has been marked as a duplicate of this bug. ***
Same here, i did put a vault on dropbox and just wanted to open it on second pc and i don't see any option, and by trying creating vault from scratch it crashed/window disapeared at finish. But for now you need to copy the plasmavaultrc or mount manually (depending on encryption type): cryfs /path/to/encrypted/dir /path/to/mount encfs /path/to/encrypted/dir /path/to/mount
The same for me. Also I can't change path to encrypted folder (for eazy using with cloud)
This will be implemented in Plasma release after the LTS. I didn't want to introduce new features in this release - just to polish the existing ones. As for changing the path to encrypted directory - that will not be allowed from the UI. For that, you'll have to dig through the config file. I guess documenting this somewhere might be beneficial.
Git commit 42ad78f258019eb244901b3cf2fbd8abe1e437f0 by Ivan Čukić. Committed on 26/07/2018 at 08:12. Pushed by ivan into branch 'master'. Importing existing encrypted directories added to the backend Adds the dbus command for importing vaults. Running qdbus org.kde.kded5 /modules/plasmavault requestImportVault will start the vault importing wizard. M +2 -0 kded/CMakeLists.txt M +10 -3 kded/engine/backend_p.h M +22 -0 kded/engine/fusebackend_p.cpp M +4 -0 kded/engine/fusebackend_p.h M +16 -7 kded/engine/types.cpp M +36 -2 kded/engine/vault.cpp M +5 -3 kded/engine/vault.h M +24 -22 kded/service.cpp M +1 -2 kded/service.h A +290 -0 kded/ui/vaultimportingwizard.cpp [License: GPL (v2/3)] C +22 -29 kded/ui/vaultimportingwizard.h [from: kded/engine/types.cpp - 069% similarity] A +85 -0 kded/ui/vaultimportingwizard.ui https://commits.kde.org/plasma-vault/42ad78f258019eb244901b3cf2fbd8abe1e437f0
I didn't even know there was such an option/action already implemented... Had to dig through the code and find out it's done through a dbus call... Any plan implementing this in the UI - a button or something like this?
The diff appears to indicate that there's a wizard. Bug I agree, it's much too hidden since there's no actual UI for triggering it. Re-opening.
The reason this is not in the UI is that I don't find the use-case of syncing with other computers via a public cloud service a particularly secure practice. I'm open to being convinced otherwise. The feature exists for more tech savvy users that are willing to dig a bit into it. One thing that I plan to do is to collect all these things in the Vault docs on the userbase (when I create the Vault docs on the userbase).
I think there are more use cases than just the one in the OP's description. Besides, having a feature only accessible from a DBus call is practically the same thing as not having the feature at all. Why do the work to write the feature only to make it almost entirely inaccessible?
(In reply to Ivan Čukić from comment #8) > The reason this is not in the UI is that I don't find the use-case of > syncing with other computers via a public cloud service a particularly > secure practice. > > I'm open to being convinced otherwise. Well my purpose will not be to convince you in something ;) It's your application and so your decision how to do the things :) But in my case I have a couple of Vaults in other places in my home folder... They are created either by directly using the cli of encfs or by other applications like cryptkeeper, kencfs-plasma etc.... I want them to be listed and accessible in one interface though - preferably a KDE app and I want them to stay where they are (not to be moved to some hidden folder)... Sadly kencfs has problems, so I was happy when I first saw Vault. But next the lack of adding already existing vaults was a turn off.. So having Vaults in other places locally is a valid use case IMHO... Even if that place is not local but a cloud... no matter of the security implications.. it should be a valid case too... 'cause I think one of the most important reasons users still stay in KDE is the vast options of configuration of almost all things in it... as opposed to GNOME.. where it's more like a disaster when trying to configure something ... > > The feature exists for more tech savvy users that are willing to dig a bit > into it. One thing that I plan to do is to collect all these things in the > Vault docs on the userbase (when I create the Vault docs on the userbase). If you ask me KDE is all about tech savvy users :) But this dbus call... well it is too tech savvy.. People either have to go through the code carefully, or have to see this bug report where you mention the dbus call ;) or of course go through all the dbus interface of kded5.. Anyway as @Nate Graham said.. why do something so functional that would stay deeply hidden ;) Sorry for the long post... It has nothing to do with bug reporting I know... but couldn't help expressing my opinion...
Don't apologize for the post length - you explained very well your use-case. > Well my purpose will not be to convince you in something ;) > It's your application and so your decision how to do the things :) This is not how I like to do things - at least not with Vaults. Users and their desires are quite important, and I try to be open to ideas as long as they don't significantly lower the security. And, in this case, I don't think the import feature has a big negative impact on security. So, convincing me has a purpose :) The answer to Nate's question of why spend time to implement something while not exposing it in the UI is simple - 1) to help the users who asked me for the feature and are willing to roll up their sleeves a bit 2) to test the feature on those users. Thanks to this, I already god some feedback on the wizard. @Nate if you have an idea on how to expose this feature in a nice way - without making it into a yet another button in the applet, I'm listening :) I had two ideas and I'm not sure about either of them: - add 'Import existing vault' and 'Create a new vault' (for completeness) to the applet-right-click menu - add the option to import existing vault to the creation wizard which would be more streamlined, but bad usability-wise (IMO)
Can I propose one more idea: Make the Vault applet like the Network Manager applet - clean of any buttons on bottom, with a configure icon at the top right side at the level of the applet's name + enlisted Vaults that when clicked has their current options. The configure icon button to open a kcm module (just like the Network manager's kcm_networkmanagement) where left side has the Vaults enlisted (if any) with a + and - button at the bottom. The right side of the kcm module to enlist the selected vault's properties.... The + button may be a submenu with two choices: "Import existing vault" and "Create new vault"... This way there will be consistency in user experience because a lot of apps use this like Network Manager, KTP (KDE Telepathy), KDE Connect....
Is there any way I can help? I think this feature would be great.
Would you like to submit a patch? See https://community.kde.org/Get_Involved/development
You can test how well the current implementation of importing works, and then we could think of a way to expose it to the user without it being overly accessible for the reasons mentioned before.
Nate Graham's comment actually encouraged me to setup a KDE dev-env to write a patch regarding this bug, and perhaps start contributing a bit to KDE development in general. Yes, sure. I will make sure to test the import vault implementation. Thank you very much.
Great to hear that!
Thanks for developing the import functions which I feel is essential to allow recovery from backup. I have a number of vaults that were encrypted with cryfs on kubuntu 18.04. I moved to fedora kde spin and tried to import these vaults. I installed cryfs from copr as it was not available in the repo (this should be reported to fedora perhaps). I launched the import function with qdbus org.kde.kded5 /modules/plasmavault requestImportVault ; selected cryfs, the location of data and mount point but the "next button" remains greyed, only back and cancel are clickable. The terminal does not show any message. I have a backup of unencrypted data so it is not a problem but if I can of any help...
Hi Sylvain, Which version of cryfs dod you install? Did you select an existing, empty directory for the mount point? (seems like the error message does not appear always, need to investigate why) If the UI fails, you can 'import' by manally editing the config. 1. kquitapp5 kded5 2. killall kded5 3. cp ~/.config/plasmavaultrc ~/.config/plasmavaultrc.backup 4. open .config/plasmavaultrc in an editor of your choice 5. In the section [EncryptedDevices] add the device as /location/to/encrypted/data=true 6. Create a new section called [/location/to/encrypted/data] and add these fields in it: mountPoint=/path/to/an/empty/directory/where/you/want/the/vault/mounted backend=cryfs name=Name of the Vault 7. Save the file and "killall kded5" again just for good measure 8. Start kded5: kded5 &>/dev/null& 9. Check whether the things you added are still present in ~/.config/plasmavaultrc 10. Check whether you can mount the vault
Sorry for the delay. I was working from home and the problem is on my lab pc... I attach a screenshot to show what I mean. In the screenshot attached I am trying to import the vault named "Grades and Scores", for which the encrypted data is in the folder "/home/sylvain/Classes/Grades and Scores" and the mountpoint is "/home/sylvain/Vaults/Grades and Scores/" which is an empty folder. I tried to rename the folder to remove space. For cryfs, the package I installed is : https://copr.fedorainfracloud.org/coprs/fcsm/cryfs/ Is there any way to turn debug flag on? The backup from plasmavaultrc contains the following for that vault. I could try to reimport manually but I am ok to try to debug first: [/home/sylvain/Classes/Grades and Scores] activities=1bfcdc1a-fe56-4234-93d6-1379e47f85a2 backend=cryfs lastError=Unknown device (code: 1) lastStatus=2 mountPoint=/home/sylvain/Vaults/Grades and Scores name=Grades and Scores
Created attachment 129037 [details] cannot import vault the "next" button is greyed on the last step is greyed and no error is shown in the terminal
Sadly, no debugging output is present. Can you try one stupid thing - add a trailing slash manually to both paths?
The trailing slash worked! That was not stupid :) When we use the browse button, the trailing slash is not added, so it has to be added manually afterward. Another minor point, there is no cursor appearing when we click in the text field and (for example in the next screen for password input) it is not possible to use tab to go to the next field.
I believe it is in types.cpp the normalise function. I tried to look at the code (I dont know C++) but it seems it removes the trailing slash if it exists. But it was there on purpose I believe... Sorry it would take time for me to understand why this function is here and if on the reverse adding a slash here would break stuff somewhere else.
Seems like the field validation does not happen always after the browse button. Will have to see what that is about. The slash should really be of no importance. It is removed so that people don't accidentally create /some/path and /some/path/ vaults. Thanks for the report!
No problem and sorry to not be that useful. Thanks to you for vault and your contributions.
(In reply to Ivan Čukić from comment #8) > The reason this is not in the UI is that I don't find the use-case of > syncing with other computers via a public cloud service a particularly > secure practice. The use-case also applies to existing (in my case encfs) files on removable media like USB sticks, BTW.
(In reply to Ivan Čukić from comment #8) > The reason this is not in the UI is that I don't find the use-case of > syncing with other computers via a public cloud service a particularly > secure practice. I am very new to the subject, but I'd be interested if you could explain a little further. What is that you don't like about using public Cloud service + CryFS (or w/e), exactly? Is it about the fact that you don't trust Cloud services in general? Is it because, perhaps, this use case could corrupt the files/folder in case of an internet connection loss? Is there something else I don't see
For now I'm stuck on how to recover my important encrypted data, after upgrading to 5.25.5 I removed my current account and created new one to solve some of the hard to produce bugs, for now I have my encrypted folder in separate partition and I remember the password but don't know how to access my private data.
Hi medin, First, I'd create a backup of the encrypted data just in case. Next, mount the vault manually from terminal. BACKEND_COMMAND ABSOLUTE_PATH_TO_ENCRYPTED_DATA WHERE_YOU_WANT_TO_MOUNT Depending on which backend you used to create the vault, BACKEND_COMMAND will be cryfs, encfs or gocryptfs. So, for example, if you used encfs and your vault data is in /home/user/.local/share/plasma-vault/VaultName.enc and you want to mount it to /home/user/vaults/VaultName, you'd do this: encfs /home/user/.local/share/plasma-vault/VaultName.enc /home/user/vaults/VaultName You'll be able to access the unlocked data in /home/user/vaults/VaultName. You can copy the data somewhere (for example, to a new Vault you created). To close/unmount the vault, just do fusermount -u /home/user/vaults/VaultName If you want to test out the (hidden) import feature, after all of the steps above (including the call to fusermount -u), do: qdbus org.kde.kded5 /modules/plasmavault requestImportVault And go through the steps of importing the vault. Please report back if it worked.
@Sebastian Schuberth The USB use-case is a practical one and it will most likely happen after I do the Vault refactor that is in works. Though, for USBs, I'd advise full-disk-encryption instead of using Vaults (cryptsetup-based). But I guess creating an encrypted drive can be more tedious than using a Vault. @Carlo For cloud stuff sync (apart from the downsides you mentioned), doing a sync of encrypted data means that all your devices share the same encryption key (not only the passphrase, but the internal key used by the encryption algorithm). Now, cryfs author did design it with cloud in mind, so I might be overly restrictive here... I guess a nicer (and public) import mechanism could be added along with removable devices support.
(In reply to Ivan Čukić from comment #30) > Please report back if it worked. The first way worked perfectly. But the hidden import has two problems : 1) The folder selector add folders names for both encrypted location and mount point but the next button remains disabled, the only way to enable it is by adding "/" at the end of both encrypted location and mount point. 2) The import operation failed by giving me the error : "This device is not initialized. Cannot import it."
> I guess a nicer (and public) import mechanism could be added along with removable devices support. That would be awesome, thanks in advance!
@medin thanks for reporting back!
`qdbus org.kde.kded5 /modules/plasmavault requestImportVault` works for me, with the caveat of having to manually append the trailing `/` for both paths as @medin mentioned. However, the hidden `.directory` (to add the `folder-decrypted` icon) gets persisted which is undesirable in the case of gocryptfs.
> with the caveat of having to manually append the trailing `/` for both paths as @medin mentioned Actually it is not about the trailing `/`. Any manual changes in the textboxes would do.
are there any workarounds via plasmavaultrc or something?
I tried all suggested workarounds, but I always get a lastStatus=2 within plasmavaultsrc. Mounting manually with encfs works just fine. EDIT: Finally I found a workaround to "migrate" my "old" vaults: - rename ~/.local/share/plasma-vault/MyCredentials.enc to ~/.local/share/plasma-vault/MyCredentials.enc.bkp - create a new "MyCredentials" vault via plasma vaults and mount it - mount ~/.local/share/plasma-vault/MyCredentials.enc.bkp to /tmp/MyCredentials manually with encfs command - copy the decrypted data from /tmp/MyCredentials to the new vault /home/user/Vaults/MyCredentials manually which is a regular user's horror regarding security. So if you are under risk, disconnect your network during procedure.