POSSIBLE EXPLANATION OF initramfs VS init.d BEHAVIOR:
initramfs=no console under usplash
init.d=active console under usplash
The right fix is to fix askpass.c so that no matter how you use cryptsetup the passphrase is secure. The bug doesn't exist with a start-of-boot passphrase call now, but what if the boot sequence changes in the future to put an active console under usplash in the initramfs?
I experimented with a simple, hardcoded script using usplash_write INPUTENTER that worked for initramfs passphrase entry, to allow a swap partition on an LVM volume to give encrypted hibernation. Then, of course, I found cryptsetup already handles this fine as released-but what about possible future boot sequences?
What source package contains the source code for the askpass.c binary? I wanted to give this a try but never found the source of askpass.c
POSSIBLE EXPLANATION OF initramfs VS init.d BEHAVIOR:
initramfs=no console under usplash
init.d=active console under usplash
The right fix is to fix askpass.c so that no matter how you use cryptsetup the passphrase is secure. The bug doesn't exist with a start-of-boot passphrase call now, but what if the boot sequence changes in the future to put an active console under usplash in the initramfs?
I experimented with a simple, hardcoded script using usplash_write INPUTENTER that worked for initramfs passphrase entry, to allow a swap partition on an LVM volume to give encrypted hibernation. Then, of course, I found cryptsetup already handles this fine as released-but what about possible future boot sequences?
What source package contains the source code for the askpass.c binary? I wanted to give this a try but never found the source of askpass.c