Encryption GUI with 9.1.0.1 (344)

[choctaw]

New thread started at the moderators request. With further testing, I have found very inconsistent behavior with the GUI for disk encryption.
I posted here first viewtopic.php?f=16&t=1404 as it was an upgrade issue to rev.344 from rev.323.
The resolution was that quoting was required of the pass-phrase and I was pointed here:
http://nas4free.svn.sourceforge.net/vie ... athrev=327

No manner how I quoted the pass-phrase it would not work from the GUI. I've used double quotes, single quotes, and neither works.
Frankly, any quoting needed should happen on the script side before passing arguments to /sbin/geli, not in pass-phrase entry input box. This should be completely transparent to the user. Input validation should also be implemented if these forbidden characters become an issue and become the new norm for future releases. Am I the only one who uses strong pass-phrases?

A suggestion to those upgrading to 9.1.0.1 rev.344. If you have an encrypted disk using a strong pass-phrase (numbers,alphas and special characters) that was created in a previous installation it would wise to reset the password to something a little more friendly before upgrading to to rev. 344, such as all numerals and alphas with no special characters. If you don't, you won't be able to attach the disk unless you reinstall a previous version that you had no problems with. I just don't know what the special characters, that are to be avoided, are at this point. The " & " is not a friendly character. I'll look for other bad characters until the problem is resolved. Maybe a note in the change log would help others. The " & " which is otherwise a valid character with the geli utility cannot be used reliably with the web GUI.

This is a major issue with those of us that use disk encryption with strong pass-phrases. Especially since the GUI exposes the first part of the pass-phrase up to the special character when using the "&" character. No need in obfuscating the pass-phrase entry if you echo the partial pass-phrase in the attach error response.

On a rev.344 system there is an issue which may be related, that is if you use such a character (my pass-phrase for testing was "~t3st&t3st") to encrypt the drive first, then the drive encrypts and returns "~t3st " in the returned status message reporting that it is done and attached. I then format the drive and confirm I can read/write to it. It works but clearly not properly. Okay, so I reboot and then create an encrypted drive with the pass-phrase " abcdef " it attaches and I can read/write to it as well. All is well and normal behavior with the use of "friendly" characters and no echoing of the partial pass-phrase.(Good)

It seems that for whatever reason the "eli patch" was removed in directory revision 327, it has created a bunch of problems for those of us using strong pass-phrases. Just as an aside in my research i created a pass-phrase "~!@#$%^*()_+" and attempted to encrypt a drive. Not only won't it complete, but it also appears to hang. Then when you hit the cancel button and look at "Management" tab, it has created an entry even though the encryption process failed and didn't complete. Fortunately, it is not attached so you can delete it and start over. Otherwise a reboot would be needed.

I'll throw this in just because I'm standing on the soapbox.(feature request) Would it be possible to eliminate from the disk drop down menu, the boot drive so we don't accidentally encrypt it?. Okay..I'm done.

These are just a bunch of observations I noticed as I tried to upgrade to rev.344.

Otherwise keep up the good work!

Regards,

Choctaw

[daoyama]

On a rev.344 system there is an issue which may be related, that is if you use such a character (my pass-phrase for testing was "~t3st&t3st") to encrypt the drive first, then the drive encrypts and returns "~t3st " in the returned status message reporting that it is done and attached. I then format the drive and confirm I can read/write to it. It works but clearly not properly. Okay, so I reboot and then create an encrypted drive with the pass-phrase " abcdef " it attaches and I can read/write to it as well. All is well and normal behavior with the use of "friendly" characters and no echoing of the partial pass-phrase.(Good)

You are misunderstanding a bit.
The special character bug exists in all version of NAS4Free and FreeNAS.
But previous verions are silently discarded the pass-phrase.
You can attach only by "~t3st" in this case.

"quote is required" I said means NAS4Free must quote in the proccess.

[choctaw]

I'll work up a validation script to handle the special characters.

Thanks for the clarification.

Choctaw

[raulfg3]

I notice some changes related with passphrase in GUI in latest build : http://nas4free.svn.sourceforge.net/vie ... vision=349

[daoyama]

I notice some changes related with passphrase in GUI in latest build : http://nas4free.svn.sourceforge.net/vie ... vision=349

Yes, we have fixed this!
Now you can use any characters in a pass phrase.