Do you understand that these specified bugs with Plymouth's behavior
and/or these critical crypto packages make it impossible to encrypt on
boot with a passphrase?
This is a fundamental feature and critical to running encrypted
services. Encryption of the home directory is functionally useless
In addition encrypting on boot with a USB is not a reasonable workflow
in many cases for multiple reasons. Please specify how to go about
fixing these bugs namely:
1. Are these bugs stemming from unexpected behavior of Plymouth from the
standpoint of the API used by these programs. Eg, please
Do you understand that these specified bugs with Plymouth's behavior
and/or these critical crypto packages make it impossible to encrypt on
boot with a passphrase?
This is a fundamental feature and critical to running encrypted
services. Encryption of the home directory is functionally useless
In addition encrypting on boot with a USB is not a reasonable workflow
in many cases for multiple reasons. Please specify how to go about
fixing these bugs namely:
1. Are these bugs stemming from unexpected behavior of Plymouth from the
standpoint of the API used by these programs. Eg, please
This bug remains. I was only able to resolve it functionally by
specifying a one letter p/w. With multiple character passwords, it
becomes impossible to submit the correct p/w. (both with regards to
libpam which is what I care about)
You want me to specify how to create a standard luks file
This bug remains. I was only able to resolve it functionally by
specifying a one letter p/w. With multiple character passwords, it
becomes impossible to submit the correct p/w. (both with regards to
libpam which is what I care about)
You want me to specify how to create a standard luks file
Please can you provide exact steps to reproduce on a fresh VM, including
setup of appropriate ecryptfs/LUKS volumes? Once done, please change the
bug status back to New. Thanks!
** Changed in: libpam-mount (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because
Please can you provide exact steps to reproduce on a fresh VM, including
setup of appropriate ecryptfs/LUKS volumes? Once done, please change the
bug status back to New. Thanks!
** Changed in: libpam-mount (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because
crypto_LUKS is a mount extension provided by libpam-mount and its
functionality does not fail outside of the scope of the specified
behavior.
Ah. Then this is a libpam-mount bug, for sure, for doing something that
is communicating directly with the console.
** Package changed: cryptsetup
crypto_LUKS is a mount extension provided by libpam-mount and its
functionality does not fail outside of the scope of the specified
behavior.
Ah. Then this is a libpam-mount bug, for sure, for doing something that
is communicating directly with the console.
** Package changed: cryptsetup
** Also affects: upstart
Importance: Undecided
Status: New
** Also affects: cryptsetup
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1258900
** Description changed:
1. With ecryptsfs:
/etc/fstab:
/root/ecfs_data /root/ecfs ecryptfs rw,exec,suid 0 0
a) Pressing the enter key quickly with no other input returns that some input
is required.
b) Pressing the enter key the first time subsequent to some input appears to
/etc/fstab:
/root/e_data /root/e crypto_LUKS defaults 0 0
What are you expecting this to do? crypto_LUKS is not a filesystem.
There's no way this is going to do anything meaningful.
cryptsetup-luks 2:1.6.1-1ubuntu1
There is no such package in Ubuntu.
2. The password prompt created by
What are you expecting this to do? crypto_LUKS is not a filesystem.
There's no way this is going to do anything meaningful.
crypto_LUKS is a mount extension provided by libpam-mount and its
functionality does not fail outside of the scope of the specified
behavior.
that is the package specified
Considering that the behavior of ecryptfs and crypto_LUKS is undefined
at this time with regards to mount at boot, I will provide behavior of
cryptsetup at boot to see if the crypto_LUKS behavior is presumed caused
by a call to cryptsetup.
The reason I am using crypto_LUKS is because I am
15 matches
Mail list logo
