Description of problem:
Sorry this is something that has to be killed in birth..
Where shall I start... :\
I've encounter 2 bugs with the dialogue box one that I've filed which
happened against rawhide live image ( 441018 ) and then a different one
when I was going to duplicate 441018 with preview live install which
I have not filed ( anaconda insisted on using swap on /VolGroup03/LogVol01
instead of /Volgroup05/LogVol01 which I told it too then errors out, with an
logical error since I never told it to "Format" the swap partition in VolGroup03 ).
All seem to be related to the dialog box and when I provide the password
for the second encrypted VolGroup or hash Global passphrase. ( same password for
I dont know if it's failing because the number of encrypted VolGroups that
reside on the disk ( 2) or because the second encrypted one is EXT4 or because I
have 4 separated default partition layout except shrunk to 10 gigs each.
( ext3, ext3 encrypted, ext4, ext4 encrypted) installs on the same disk
( chainloading ) and am doing the fifth from an live cd and anaconda cant handle
Anyway these bugs aside the dialogue box is not a scalable nor a
user friendly solution.
When you have separated/multiple encrypted partition layout and you would
have a separated password for each of them the dialogue box will ask you
each and every time for each encrypted partition thou you only wanted to
unlock partition a and partition c and this leads to it becoming pain in the ass
after being asked ca 3 times.
That this be moved to custom layout menu where
an lock icon appears on the encrypted partition and when you
click/choose the encrypted partition you would then be asked to "unlock" it
or when you would choose the encrypted partition and then click [ Edit ] you
would have the ability to "unlock" it there
An separated menu created which lists all the encrypted partitions
Be it one or hundred and you would have the ability to choose and unlock
I recommend a over b since I'm strongly against extra menus in anaconda.
Hope this will be considered for F10 cycle and please share ideas etc.
since the current solution is not that good.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
bug 441018 is the originator of this RFE.
As it happens, we are leaning in the other direction. We are moving to a single passphrase for all encrypted block devices within a given system. We are also encouraging users to add this passphrase to their pre-existing encrypted block devices to establish a system-wide passphrase. This can actually increase security since you can use a passphrase which is a great deal stronger (and therefore harder to remember) than you could if you had to remember five separate passphrases.
1. Could you elaborate how the security experts at redhat came to the conclusion
that having a single passphrase for all your partions is securer
then having a different passphrase on multiple partitions?
Logic tells me that it would be harder and more secure to encrypt each
partition separately with different password as in if one password on one partition is cracked the other partition would not be compromised?
( or atleast would slow down the cracker )
2. Would it not then be better to support multiple passphrases
( For those of us that do not agree ) but recommend the single passphrase
( followed by a little info in the release notes on how you came to that conclusion ) hence serve both parties?
I already explained that by having only one passphrase you can make it a stronger passphrase since you only have to remember one.
If you insist on having different passphrases for different devices you can accomplish this with kickstart. You just supply a passphrase for each device instead of only one of them.
Well atleast it has been confirmed that this is not coming from the
security experts @ Redhat nor do I seriously doubt it that they would
even suggest what your saying here.
1xtime strong pass phrases never beats 5xtimes 5xdifferent strong pass phrases.
If the anaconda team does not have the time nor the resources to address this issue it's better to say so rather coming up with such an flawed logic.
Unless this is an order from certain agency's.
( And the plot gets thicker.. )
I'm not insisting on anything I was merely pointing out to server both parties.