feat+docu(EncFS): Deprecation warning in the GUI and details in whitepaper

[buhtz]

Related to meta issue #1734

Details and wording need to be discussed and developed.

• Create a "document" for users explaining easy the issue, the roadmap and how they can contribute and join the discussion.
• Where to put the document? Markdown in the repo as an entry point (landing page)?
• Warnings in the GUI (short and polite; linking to the whitepaper)
  • MessageBox: When an "SSH encrypted" or "local encrypted" profile is loaded in the GUI.
  • QLabel (red letters) in the Manage profiles dialog for existing "SSH encrypted" or "local encrypted".
  • MessageBox when creating a new "SSH encrypted" or "local encrypted" profile.
• Modify man page section "A NOTE ON SECURITY" according to the new situation.

[buhtz]

Here is a first draft as plain text and as screenshots:

MessageBox if GUI starts and one of the profiles is encrypted

The support for encrypted snapshot profiles is undergoing significant changes, and EncFS will be removed in the foreseeable future.

The following profile(s) use encryption with EncFS:

• Main profile (1)
• Foobar (8)
• ...

A decision on a replacement for continued support of encrypted backups is still pending, depending on project resources and contributor availability. Users are invited to join this discussion. Updated details on the next steps and alternatives are available in this [whitepaper].
This message will not be shown again. This dialog is available at any time via the help menu.
Your Back In Time Team

QLabel in General TAB of Manage Profiles dialog

Support for EncFS will be discontinued in the foreseeable future. A decision on a replacement for continued support of encrypted backups is still pending, depending on project resources and contributor availability. More details are available in this [whitepaper].

MessageBox when new encrypted profile is created or the mode of an existing one is changed to encryption

Support for EncFS will be discontinued in the foreseeable future. It is not recommended use that mode for a profile. A decision on a replacement for continued support of encrypted backups is still pending, depending on project resources and contributor availability. More details are available in this [whitepaper].

[aryoda]

All of the three warnings are adequate IMHO.

I just propose some small wording changes due to "typos":

A decision on a replacement for or continued support of encrypted backups is still pending

Perhaps also the mode names could be improved to make it clear enough when EncFS is used:

• Local encrypted --> Local (EncFS encrypted)
• SSH encrypted --> SSH (EncFS encrypted)

Esp. "SSH encrypted" is misleading IMHO because SSH is (transport) encrypted but what we mean here is "at rest" encryption.

[buhtz]

Thanks for the feedback.

I just propose some small wording changes due to "typos":

A decision on a replacement for or continued support of encrypted backups is still pending

Not sure about this. I would keep it as it is because the "support of encrypted backups" is a consequence of a "EncFS replacement". Or don't I get it? 😄

Perhaps also the mode names could be improved to make it clear enough when EncFS is used:

* Local encrypted --> Local (EncFS encrypted)

* SSH encrypted --> SSH (EncFS encrypted)

I support that idea. But I would work on that in a separate PR after the upcoming release. The code around that is quit awkward and I am not sure if there might be side effects with modifying that labels currently living in a dictionary (common/config.py::Config.SNAPSHOT_MODELS).

[aryoda]

Not sure about this. I would keep it as it is because the "support of encrypted backups" is a consequence of a "EncFS replacement". Or don't I get it? 😄

I see 😄 I was just confused what the sentence shall mean but now I understand it. No need to change anything here I'd say.

Perhaps also the mode names could be improved to make it clear enough when EncFS is used:
I support that idea. But I would work on that in a separate PR after the upcoming release.

Yes, this is the most fail-safe approach (no need to change year-old labels ASAP).

PS: Just found a forgotten word in another sentence:

It is not recommended to use that mode for a profile (furthermore)

[DerekVeit]

These notices, with the slight edits, look very good to me. I'm not using the feature, but I very much like the considerate approach for how to handle it.

I wonder if maybe a link directly to #1734 in the notice would be worthwhile.

[buhtz]

I wonder if maybe a link directly to #1734 in the notice would be worthwhile.

I wouldn't pollute the messages with to much links and references. We do link the whitepaper. That document is good starting point to all other relevant documents (Issues, Security Audits, etc). The messages are for users, the issues are for developers.

[DerekVeit]

Now that I look at the whitepaper, I see it covers everything.

[buhtz]

I will take your comments as Approval, if it is OK.