http://bugzilla.novell.com/show_bug.cgi?id=581341 http://bugzilla.novell.com/show_bug.cgi?id=581341#c1 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |jeffm@novell.com --- Comment #1 from Thomas Fehr 2010-02-22 10:08:42 UTC --- What exactly is the problem with forcing a format on swap? Calling mkswap is quite fast and there can hardly be any data destroyed on a swap device. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=581341 http://bugzilla.novell.com/show_bug.cgi?id=581341#c3 --- Comment #3 from Thomas Fehr 2010-02-23 17:03:03 UTC --- Problem is that when encryption is used we cannot decide a swap partition from a filesystem partition (Ok on msdos partition table we could use partition id, but this is not available on GPT disk label, LVM or MD devices). So we cannot know if mount point "swap" is valid or not in the mount dialog. The password is asked afterwards so it is also not possible to set up the dmcrypt device temporarily internally to peek at the filesystem id of the decrypted volume. So it is either allowing swap always (which would potentially confuse users using encrypted non-swap partitions) and potentially recognize later that the decrypted volume does not contain a swap signature at all and need to force the user to go back from password screen or have the current behaviour of forcing encrypted swap to get formatted. Since probably not many people use encrypted swap with a password anyway I think current behaviour is still better than allowing "swap" mount point unconditionally for all encrypted volumes. Comments? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=581341 http://bugzilla.novell.com/show_bug.cgi?id=581341#c5 --- Comment #5 from Thomas Fehr 2010-02-23 17:48:36 UTC --- Asking for password does not make sense before user has a chance to press the "encrypt device" toggle. A possibility would be to ask password in a popup when necessary (as it was with pre 11.1 UI), but this is not allowed any more in new UI guidelines. Arvin told me it was an explicit request for new storage UI that password entry is in a separate dialog after mount dialog. So I simply see no way to make this work as you would prefer with reasonable effort and without making other people displeased. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=581341 http://bugzilla.novell.com/show_bug.cgi?id=581341#c7 --- Comment #7 from Thomas Fehr 2010-02-23 18:09:59 UTC --- This is indeed a valid approach that would avoid current problems. Implementation-wise this would not be too much work (just tried to do luksOpen manually before starting "yast2 disk" and encrypted swap volume was successfully detected) but before I do this, someone with the decision making power should commit to that approach. Needless to say that this approach has other disadvantages: In systems with multiple installations one needs to type more passwords than currently necessary since one can hardly know which encrypted device contains what. Say there is a system with three installations each with two encrypted volumes (swap and root) one needs to enter 6 passwords before expert dialog shows up. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=581341 http://bugzilla.novell.com/show_bug.cgi?id=581341#c9 --- Comment #9 from Thomas Fehr 2010-02-24 17:17:56 UTC --- Would of course be doable and would also not be too complicated to implement. Nevertheless it would cause potentially more password popups than currently: Current state: - User is prompted for a password if and only if he explicitely manipulates (format or setup) a encrypted volume. This is what is to be expected and nobody should be surprised. Disadvantag: since without the password we c annot know about the content of the volume, we have to accept less comfort in some areas. Your suggested change: - User is prompted for a password whenever yast2 finds a volume containing a LUKS signature that has no accompanying crypt dm table. This is unexpected. Maybe the user simply wants to do something that does not involve manipulation of any encrypted volume at all. I do not think this is really much better than the current state. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=581341 http://bugzilla.novell.com/show_bug.cgi?id=581341#c11 Thomas Fehr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #11 from Thomas Fehr 2010-02-24 17:47:17 UTC --- Just talked to Arvin about the topic and he reminded me that we need to ask for any LUKS encrypted volume anyway in startup starting with 11.3 to be able to support the dreaded use case of PV encryption. If I consider this fact this discussion is moot, since we need to ask during installation for every LUKS volume anyway. If we do this (and the user provides correct passwords) detection has the needed information so that behaviour would be as you expect. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.