LUKS Unlock prompt should be reworded

[bugproxy]

== Comment: #0 - Michael Roesch <email address hidden> - 2016-02-16 04:08:05 ==
When using LUKS-encrypted partitions, it should be more obvious that the system wants you to enter a password to unlock the respective partition. The current message is misleading.

Current message:

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ...
Please unlock disk dasda2_crypt

I suggest the following change:

Please enter passphrase to unlock disk dasda2_crypt

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1546144/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Dimitri John Ledkov (xnox)]

It really is unlock, as one can use, if configured:
* remote unlocking via ssh
* keyfile / hardware tokens to unlock (a secret stored in a file on a drive)
* execute arbitrary script to unlock (e.g. to use TPM, smartcards, U2F, OTP, multi-factor, etc...)

In previous releases we also listed the full UUID of the partition to unlock, which has been dropped some time back as being essentially unrecognizable to the user.

I'm not sure new wording is that much better. Maybe adding a training colon would help:

with possibly showing the cursor too? (not sure, but cursor maybe especially disabled).

I do appreciate testing LUKS encrypted volumes on s390x, however it is only a protection for physically insecure devices. I am struggling to identify a usecase in which mainframe and mainframe storage has zero physical security to access it.

On desktops, we use plymouth, and thus no boot messages are shown and the full screen is taken with a prompt for password. There is no video / splash available for s390x over serial console during boot.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-02-19 05:14 EDT-------
(In reply to comment #7)
> I'm not sure new wording is that much better. Maybe adding a training colon
> would help:
>
> with possibly showing the cursor too? (not sure, but cursor maybe especially
> disabled).

I guess this would be an improvement, yes. It would still be more obvious if you had "enter passphrase" in there somewhere. But maybe this is only my opinion :-)

> I do appreciate testing LUKS encrypted volumes on s390x, however it is only
> a protection for physically insecure devices. I am struggling to identify a
> usecase in which mainframe and mainframe storage has zero physical security
> to access it.

OK understood. But should the encryption support (LUKS and ecryptfs) then not be removed completely or only be a hidden option?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-11-16 08:09 EDT-------
Move to new Target 17.04

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-02-03 05:11 EDT-------
Changed target release to 17.10

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-02-10 06:35 EDT-------
Here is another suggestion for a message:

"Please supply the passphrase to unlock disk dasda2_crypt"

That leaves open where the passphrase would come from but makes clear that the unlocking process requires to obtain some passphrase.
"Enter" clearly makes only sense in an interactive setting.

As for the value of dm-crypt for z Systems (and other servers).
You are right serer disks cannot easily be stolen lie laptop disks can. But server data residing typically on some remote storage serve in some SAN might be accessible by unauthorized systems. Further the owner of the storage subsystem and the Linux image may not be the same (cloud scenario). dm-crpt provides E2E security for the date of the owner of the operating system.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-02-27 04:06 EDT-------
Test Entry for mirror checking only !

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-11-27 08:06 EDT-------
IBM bugzilla status closed -> will not be fixed by Canonical, Low Prio.