I don't think choosing a random backend makes sense without at least some information provided to the user. How about adding a text view below the combobox showing a quick human-friendly summary of the purported advantage of each backend? like this:

"EncFS is older and may have X advantage"

CryFS is newer and may be more secure"

Or whatever; I'm hardly an expert in encryption.

In D8449#159337, @ngraham wrote:

I don't think choosing a random backend makes sense without at least some information provided to the user. How about adding a text view below the combobox showing a quick human-friendly summary of the purported advantage of each backend? like this:

A distro may have a preference, and only install one. This is the main reason where the above approach makes a difference. We pick the one that is available. With debian (and all derivatives) already having flagged encfs, I think that this will have a big impact for a very small price.

But you make a good point. We should not choose randomly.

As I do know a bit about crypto, I can list the differences. Unfortunately the difference to end users is probably something they won't care about because the differences between the two systems are not really seen in the usecases that Vault currently provides. Though I don't know about future plans.

Differences are;

• CryFS has a storage that looks more like a git database than a dir. EncFS has a one-to-one connection between user-file and encrypted file.

We do allow the user to set the "encrypted data location" dir, as such they may choose a shared drive (BAD!), but that's not the default and as such this difference between systems doesn't really expose much. If it did, I'd suggest you avoid encFS as it leaks a lot of metadata that CryFS protects.

• EncFS just one-to-one encrypts a file, and its filename. This means that filesystem features like chmod/chown of the main storage are transparently visible on the mounted drive. Filename length is similarly limited. Symlinks in your mount are symlinks on the target device.

As such you will get a nasty surprise if you store your data dir on something like vfat (usb pen) where most of these examples are not available.

• EncFS has a "volume-key-file", which is like your gpg key, a file on the filesystem. It additionally requires a password.

This might be useful to do a 2factor authentication, but Vault would need quite a lot of extra work to support that. As such this feature is unused.

When it comes to security, both use external libraries (openssl et all) to do the actual hard lifting, which are peer reviewed and everything.

more; https://www.cryfs.org/comparison

I'm not sure what to write in a short summary, other than that encfs should NOT be used if there is even a small chance of a 3rd party being able to see or add to the encrypted files (for instance on a usb-pen).

Ok, what about this;
we turn off the ability of the user to select a location to store his encrypted data if they choose encFS, because it would be insecure.

as such we pre-select cryFS (should it be available), so the user can have all the features they want.

We also provide some user-visible information, like you suggested, on actual differences for the user. For instance;

CryFS: most secure and user friendly.
EncFS: Do not use this if you ever expect your encrypted files to be copied where others can see them. For instance for backup or on a usb-key or cloud-service.

ps. I'd like to see more backends, so this is not a fight between just CryFS and EncFS.

That sounds good to me, but yeah, since these differences are super-technical and not really relevant to most users, I think that regardless of our messaging, a good default is important here if multiple backends are available. Based on what you've written, it looks like CryFS is a better default than EncFS, but you seem to know a lot about crypto, so I'll defer to you.

Having a default backend (IMO) has nothing to do with the UI. What is the rationale behind changing a combo-box (a widget designed for multiple choice questions) to a button?

As far as CryFS vs EncFS - yes, CryFS is designed to avoid all the problems that EncFS has. No, we do not know that it is more secure since there was no independent audit of CryFS. It might have serious problems in other areas.

I do not mind making CryFS the 'by default selected' choice. But going more than that... at this point no.

The only "new generation" system that I've seen the audit of is gocryptfs. And that will be probably the next backend Vault will get.

p.s.

Do I need to relogin to make a kded module show up?

No. You can just kquitapp5 kded5; kded5 to restart it.

In D8449#159406, @ivan wrote:

Having a default backend (IMO) has nothing to do with the UI.

I'm not sure what else it would have an effect on. Default to me means its just a suggested one and users can still override it.

Where else would you do that than in the UI ?

What is the rationale behind changing a combo-box (a widget designed for multiple choice questions) to a button?

The combobox is still there. Its just not made visible until the user indicates they want to actually see it.

I pasted two screenshots. I'll try to implement the actual functionality soon so you can play with it.

I do not mind making CryFS the 'by default selected' choice. But going more than that... at this point no.

Thats all I suggested anyway :)

The only "new generation" system that I've seen the audit of is gocryptfs. And that will be probably the next backend Vault will get.

Awesome!

I was not clear enough probably - I meant that "Have a default backend" does not warrant a change to the UI. Especially when it makes the UI more complex.

Or even more precisely - if this were to be split into two patches (1) Change to the UI (2) Making CryFS the default, the (2) would be approved.

p.s. BTW, do you have push access? If not, and you plan to help around with Vault (which would be great), you should probably ask for it.

Ok, I see the confusion. The name of this pull request uses the word 'default' and that confused everyone.

What I meant with that is that the User Interface should respond to the packager picking a default. The UI itself does not pick a default. It just avoids showing an option that isn't actually an option for the user.

So if you have a neon install and the packager only auto-installs CryFS, then we simply auto-select CryFS for him. Making the UI simpler.
In the rare case where a user finds multiple backends installed, then I added a priority to start the user with the highest prio.

The word "default" here is just respecting the distros choice.

p.s. BTW, do you have push access? If not, and you plan to help around with Vault (which would be great), you should probably ask for it.

No, I don't. Can you point out how that works? I'm rather new to the KDE development process.

https://community.kde.org/Infrastructure/Get_a_Developer_Account

What's the status of this patch?

FWIW, @ivan I think the UI change goes quite nicely with the new default. It's nice and streamlined now.

What's the status of this patch?

The status is that I don't have a developer account and am waiting on someone to merge this.

As this change is practically not doing anything more than making the dialog react to the distro/packagers, I can't think of a reason why this should not be merged.

I have not seen any requests for changes, so I have no idea why its not merged yet.

@ivan? I know you had some reservations about the UI, but can we discuss those and either merge or abandon this?

I was on a vacation, sorry. I'll test everything today and merge it if I don't find a problem.

I still don't like the UI change, but lets go with it.