Comment 37 for bug 55159

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