usplash prevents passwords from being not echoed on the console

I can confirm this bug with Edgy Beta.

Why has this bug low urgency? I would classify it high or critical!

This appears to be fixed in Gutsy (usplash 0.5.2): you get a password prompt through usplash

Confirmed in Feisty/Edgy.
A safety workaround is to switch early to console 1 (ctrl-alt-f1), just when the keyboard is initialized: then the password won't get displayed.

I am using a different setup now, so I can no longer help with tracking down the problem.

Daniel Hahler still seems to see it in feisty, so you might want to keep this issue open anyway (even though it does seem to be fixed in gutsy).

Daniel Hahler : I can reproduce this bug (which can be considered as a security flaw) in Hardy and Intrepid. This bug can be reproduced in these conditions :

Pre-requisites :
Having a configured cryptsetup with a luks partition and applying the patch provided in bug 139363 to re-enable cryptsetup password through usplash.

Steps to reproduce :
1. Reboot your computer
2. When asked by usplash, type your password, but don't press "enter" to validate your password.
3. Switch to tty 1 with CTRL + ALT + F1
4. Switch back to the usplash tty with CTRL + ALT + F8

Result :
The password is written in plain text in the console.

Strangely, this bug can't be reproduced with LVM cryptsetup installation that comes with hardy alternate install CD. "cryptroot" which is started by initramfs is almost identical to the patch in bug 139363 but the final result differ for two things :

1. The password never appears in the console.
2. asterisks appears as you type the password, instead of appearing only once you pressed "enter"

The fact that one is started inside initramfs and that the other one is started during the init.d boot sequence seems to have an impact on this bug.

Since bug 139363 has been fixed, this security issue can now be reproduced in intrepid.

The attached patch reverses last changes uploaded with cryptsetup 1.0.6-6ubuntu1 and break usplash again. This is a temporary workaround to patch the security issue until a fix which safely permits the use of usplash is developed.

Saïvann Carignan <email address hidden> writes:

> The attached patch reverses last changes uploaded with cryptsetup
> 1.0.6-6ubuntu1 and break usplash again. This is a temporary workaround
> to patch the security issue until a fix which safely permits the use of
> usplash is developed.

Well, it does not really reverse any of the changes of the last upload,
but merely re-adds the command to quit usplash just before asking for a
passphrase.

Btw, perhaps the problem is rather in askpass.c. If that is the place,
askpass.c should rather be fixed though.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Reinhard Tartler : That can make sense. However don't forget that this bug doesn't happen when started from initramfs hook. The problem appears only when started by init.d . Can askpass.c still be the problem in this case?

Well, sure, since AFAIU the code, /lib/cryptsetup/askpass is used by both the init script and the initramfs hook.

Exactly! So why it works in the initramfs hook and not in the init script? That's my main interrogation.

good question.

Btw, does the problem only occur when you switch the VT at the usplash
password prompt, or is the password echoed also without any VT switch?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

I assumed that the password was echoed without VT switch, but now that you are asking for it.. I don't know, and I really wonder how we could verify it!

askpass.c echoes back to the commandline when it exits. I am working on this to fix it.

---
tonic@Io:~/Projects/Usplash/$ /lib/cryptsetup/askpass "Test: "
Test: ghghg
tonic@Io:~/Projects/Usplash/$

it should be

tonic@Io:~/Projects/Usplash/$ /lib/cryptsetup/askpass "Test: "
Test:
tonic@Io:~/Projects/Usplash/$

Tonic

no wait... I'm a noob nm

tonic@Io:~/Projects/Usplash/$ /lib/cryptsetup/askpass "Test: " > /dev/null
Test:
tonic@Io:~/Projects/Usplash/$

It is doing exactly as it should be.... :(

after rereading the bugtrail, I don't see anything to fix here in the cryptsetup package.

intrepid ships with an askpass binary, that safly asks the password using the 'best' available means. Which includes usplash if available.

I can confirm that the password is echoed without a VT switch. For some reason usplash exits while setting up the swap, a few lines over the current cursor I’ll find my passphrase in plaintext. Which must have been echoed there prior to exiting usplash and there was no manual vt-switching.

Please close for Feisty as Won't Fix? This goes for all the other Feisty bugs.

This bug is a security problem. pretty severe in my eyes. If for whatever reason you get dropped to console after entering your harddisk password it is readable on the screen. This can be triggered quite easily and needs a fix.
Still happens with jaunty!

If it is not fixable usplash needs to be disabled if harddisk encryption (dm-crypt) is used.

I cannot reproduce this issue. What are the contents of your /etc/crypttab?

Kees Cook :

# <target name> <source device> <key file> <options>
X /dev/md0 none luks

The steps described in the bug description should always reproduce the issue. It's always reproducible for both intrepid and jaunty.

Kees Cook : The recent updates in jaunty cryptsetup package did change oen thing in usplash behavior :

It now show stars as you type in usplash prompt, as it already does when usplash asks for the passphrase from initramfs (LVM encrypted install). However, the security bug is still not fixed when for usplash prompt when started from init.d, it only works securely when it starts from initramfs.

@Kees: Try with retry=3 and enter the password wrong 3 times. should drop you to console

mfl@titan:~$ cat /etc/crypttab
# <target name> <source device> <key file> <options>
crypt /dev/mapper/vg--raid--lvm-lvcrypt none luks,retry=3,ciper=aes-cbc-essiv:sha256
cswap /dev/mapper/vg--raid--lvm-lvswap /dev/random swap,check=/bin/true

Setting to confirmed. This bug affects lots of people.

and confirmed even more !

could you guys please do ANYTHING about it ?

the current status of the system on my laptop is:

1) it starts to boot, launches usplash

2) disk activity stops and it just sits there FOREVER ! (waiting for input ? sometimes it accepts the password, sometimes it doesn't)

3) this can only be circumvented by using Magic SYSRQ Key + E (!)

4) then I have to log into the failsafe terminal / console - since with the latest nvidia-drivers switching to a VT results in a just blank / black screen

5) open the partition and mount it, log out

6) log in again

7) now I'm ready to use the system

--> BAD !

please please fix it ASAP - even if it's only to disable usplash when the system detects that there are encrypted partitions in use to be used after boot

thanks !

ah - sorry, forget to post system-information:

system is:

Jaunty (testing), 9.04 post Alpha6-state, amd64 on an Dell m1330

FIX FOR BOTH HARDY AND JAUNTY:

Some time back, I modified /lib/cnryptsetup/cryptdisks.functions to make Usplash work to mount a non-root LUKS partition in Hardy. The working principle is this: On b oth my AMD 64 single core and my Intel Atom, if you type the passphrase with Usplash running while cryptsetup is waiting for it, it goes right to cryptsetup same as if the console was showing, though there would be no prompt to tell you when to type it!

This altered code drops the usplash_write "quit" line from Hardy's version, and uses Usplash_write's VERBOSE and TEXT functions to prompt just before cryptsetup runs-but does NOT try to use anything like askpass or usplash_write_inputquiet due to bugs.

Since the Jaunty version leaves the password on the console, I must assume it would be easier for an attacker to scan all memory and recognize the password than it would be to recognize the actual key. This is unacceptable, so I have rolled back to my own code.

Here's the new cryptdisks.functions Cut and paste into gedit, etc and save as /lib/cryptdisks.functions as root after backing up the original file:
##########################################################

#
# This file is for inclusion with
# . /lib/cryptsetup/cryptdisks.functions
# and should not be executed directly.

PATH="/sbin:/bin"
TABFILE=/etc/crypttab
CRYPTDISKS_ENABLE="Yes"

#set -x

# Sanity checks
[ -x /sbin/cryptsetup ] || exit 0
[ -f "$TABFILE" ] || exit 0

. /lib/lsb/init-functions

if [ -r /etc/default/cryptdisks ]; then
 . /etc/default/cryptdisks
fi

MOUNT="$CRYPTDISKS_MOUNT"

case "$CRYPTDISKS_ENABLE" in
[Nn]*)
 exit 0
 ;;
esac

# Always output to console
stdin=`readlink /proc/self/fd/0`
if [ "${stdin#/dev/null}" != "$stdin" ] && [ "$ON_VT" != "yes" ]; then
    exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 "$@"
fi

# Parses the option field from the crypttab file
parse_opts () {
 local opts opt IFS PARAM VALUE

 opts="$1"
 LOUD=""
 PARAMS=""
 CHECK=""
 CHECKARGS=""
 PRECHECK=""
 TRIES="3"
 MAKETMP=""
 MAKESWAP=""
 USELUKS=""
 TIMEOUT=""
 KEYSCRIPT=""

 # Parse the options field, convert to cryptsetup parameters
 # and construct the command line
 IFS=','
 for opt in $opts; do
  PARAM=$(echo "$opt" | sed 's/=.*//')
  VALUE=$(echo "$opt" | sed '/=/!d;s/^.*=//')

  case "$PARAM" in
  readonly)
   PARAMS="$PARAMS -r"
   ;;
  cipher)
   if [ -z "$VALUE" ]; then
    log_warning_msg "$dst: no value for cipher option, skipping"
    return 1
   fi
   PARAMS="$PARAMS -c $VALUE"
   ;;
  size)
   if [ -z "$VALUE" ]; then
    log_warning_msg "$dst: no value for size option, skipping"
    return 1
   fi
   PARAMS="$PARAMS -s $VALUE"
   ;;
  hash)
   if [ -z "$VALUE" ]; then
    log_warning_msg "$dst: no value for hash option, skipping"
    return 1
   fi
   PARAMS="$PARAMS -h $VALUE"
   ;;
  verify)
   PARAMS="$PARAMS -y"
   ;;
  check)
   if [ -z "$VALUE" ]; then
    VALUE="$CRYPTDISKS_CHECK"
   fi
   if [ -x "$VALUE" ]; then
    CHECK="$VALUE"
   elif [ -x "/lib/cryptsetup/checks/$VALUE" ]; then
    CHECK="/lib/cryptsetup/checks/$VALUE"
   else
    log_warning_msg "check $VALUE is not an executable script, skipping"
    return 1
   fi
   ;;
  checkargs)
   ...

 BROADER PATCH FOR BOTH LUKS AND REGULAR MAPPINGS

After posting my patch, I realized I only wrote it for LUKS! Therefore, I spent most of today rebooting again and again to test revisions to add the code to the part of cryptdisks.functions that controls setting a regular mapping as well. It works, though with a regular mapping cryptsetup will not error out regardless of the passphrase-the mapping just won't mount if the passphrase is wrong.

This alone is a good reason to use LUKS. With this code and LUKS, if the password is wrong usplash (and cryptsetup underneath) will simply hold and wait until the right password is entered or you run out of tries-then the boot process resumes. Usplash is verbose while cryptsetup is running.

With these revisions, askpass(the source of the security hole) is NOT used and the passphrase is NOT echoed to the console (I checked). Verified to work on Intel Atom and AMD Athlon 64 w/32 bit Ubuntu Jaunty, earlier patch(posted above) also verified on 2 GHZ 32 bit(old style) AMD Athlon with Ubuntu Hardy. Either version of cryptsetup is fine with this patch.

TODO: Find a way to force tries=1 for each call of cryptsetup, then loop the script again so cryptsetup (and the Usplash prompts) are called once each time for every try in "tries=" in /etc/crypttab. This would make the splash screen text responsive to a bad password instead of the user having to know no response=bad passphrase. Still, usplash works, and the passphrase doesn't get echoed to the console.

Anyway, here is the new code-straight out of /lib/cryptsetup on the machine this is uploaded from.

PROBLEM with non-LUKS mapping was this: usplash keeps running with NO prompt, appearing to be a boot hang when the older cryptsetup code from hardy (source package=1.0.5 ,deb version(s)=2:1.0.5). I have not tested 1.0.6 with a non-LUKS mapping, but the "askpass" binary is used in both LUKS and non-LUKS mappings with the version of cryptdisks.functions included in version 2:1.0.6 cryptsetup. Presumably this fixed the "no passphrase entry" bug I saw when testing the unaltered 2:1.0.5 code(my original changes did not touch that section) on a non-LUKS mapping.

Therefore, my first patch would RE-INTRODUCE the "no passphrase entry" bug on a non-LUKS mapping and should NOT be used to fix the package-only to patch installations using LUKS, where I used it for months.

My second patch does NOT reintroduce this bug-and someone should see if "askpass" is echoing the passphrase to the console on non-LUKS mappings with 2:1.0.6, as the code in the provided cryptdisks.functions is similar. If so, my second patch closes that hole as well.

Luke : Thanks for your great work. Unfortunately I get a different result here. I overwrited my /lib/cryptsetup/cryptdisks.functions file by the one provided in your comment #30 and I'm still able to see my passphrase echoed in plain text on console if I switch to console before finishing typing my passphrase using the initial steps in the bug description.

I tested this with a luks partition which is mounted in "/media" (not a root partition) and therefore which is unlocked by cryptsetup during init.d and not initramfs.

Can you see something that could be missing in your current fix so it can apply to the configuration I described?

  Odd-I've tested this again and again on my own system. Reopen cryptdisks.functions from your machine in a text editor and make sure it is truly overwritten-a suprise there would be the first thing I would suspect.

  If you are NOT able to unlock the encrypted partition, but DO see you text echoed on the console, you have a different problem. In my early experiments, I sometimes had trouble in Hardy with usplash corrupting the console and got the result you describe-but with characters shown not being the ones typed. Never saw this again with later versions of my own code for unknown reasons-and never saw it once in Jaunty.

  BTW, it's the hardy version of Usplash I'm using for compatability with a customized splash screen, and I'm not getting either problem.

 First, check your cryptdisks.functions. If the local changes aren't there, it didn't copy.
I've sometimes seen issues in Jaunty with renamed backup files being called as though they had not been renamed-seen it with xorg.conf backup files corrupting VESA displays. Try putting the text "BAK" before and after the backup file to see if this is happening.

Askpass should NOT be called so its bugs should not be an issue. You could rename askpass or move it, but then would be locked out if you have the 1.0.6 version of cryptdisks.functions.

In cryptsetup 2:1.0.5 , askpass and the fifo are not used and not present in /lib/cryptsetup at all.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)

mQGiBElz9bERBADHbO/o4DHTv5tNDs0N/QCL2nXKbLDMwLJatti6QtEDOB98yNeW
1oKaJ4B9kWJQanMy4fZZLPBriYybxUudU5RCqKY64KK3Pnc9oAMuYk5PxVO+7hrx
8GIShwJtEFVBpS4K59Re3VTK6r6uBNgBfteST3jy/XvuvXQSWi9408lCswCgnnGK
KYYoOiI4G6k5WJaURzWn6vcD/2lW4sEUFnCfVSFuTdP0/CSJQq4XUJsys1thsm6W
320u7wt8VEvXUV8HfzmcqnYj9Tpi51XMCvqpi1vb2awxEE4PZ2AtKgWXkqfJHzl1
IyqtGHyf5JOQUQJGdkf571f61cJhtyWCmlTMu9TLd5NilwwPtxMTrQSzA+f1xlaH
+hneBAC1invLXDeypGmPr6buv1LYfaK3PMpwjAhxYvCKBsqjSk/KYiiliHyNIFnq
xZdhTBLS6BjVJ7lNUHbKHmICToDaxbuTQdIKbBjMCAzf3xLZCiRP3F3jPF66QDO/
iDTLzKkvjjNwIliI5xbUGhDQu3ym842NbmsrGBoE4b75S+5DzLQbTHVrZSA8bHVr
ZWt1aG5AaG90bWFpbC5jb20+iGAEExECACAFAklz9bECGyMGCwkIBwMCBBUCCAME
FgIDAQIeAQIXgAAKCRCrYZ03I1TDoo14AKCapTyOXADsXtR9oAjvSwAbF/zNIgCe
OQvVHgmQ266jsNq1alG38b4UHzu5AQ0ESXP1tBAEALhyO0p3hLYVywLkgUEImo1M
qthrNk6gIMdRKMULSHtyCQWz6trl8W/hqz8dLdlYAM7Mxv681PJHCC4PEo9bYIdk
K7QJT62A8mQCHOtmX7uvGgeZBH53mdUct0D7LUyDW/mOxUp/yVy49LUhqO4YcNiA
NdCk1/fzZq9Yc3XouZTTAAMFA/45PsuZ12ZZdZSCj0PH02ByN95qVzXYP7714eY2
IFcFImuFsGqf3vrkbKPAhmypHDdzFIBuAyP2VkMW3T/2JPNtY7VelD6B1mUEJGvd
rQCavsYox98QMAg34aD+UcqzDwwSPa+fDfy9JQIGQeUPhMGrzBc+ZGAvtq7xNMn9
6gqxnIhJBBgRAgAJBQJJc/W0AhsMAAoJEKthnTcjVMOiQBYAnjqEF54U0HUdJ3JE
oYo/l5t7j7RRAJ98TzjlIc1pGxlnWBE91IIUq4FzZA==
=mwCZ
-----END PGP PUBLIC KEY BLOCK-----

> Date: Fri, 10 Apr 2009 05:00:49 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 55159] Re: usplash prevents passwords from being not echoed on the console
>
> Luke : Thanks for your great work. Unfortunately I get a different
> result here. I overwrited my /lib/cryptsetup/cryptdisks.functions file
> by the one provided in your comment #30 and I'm still able to see my
> passphrase echoed in plain text on console ...

  One other thing: My LUKS partition mounts on /home-fstab then -o bind mounts folders TMP and VAR_TMP within it as /var and /var/tmp .

  Also, usplash in general I've found to be buggy. I've made two different splash screens (one in hardy and one in Jaunty) work fine, but what version are you using?
I would not be suprised if the original script works in some configurations, mine in others, both in a few-and neither in a few.

 This is one of the real headaches in software development-compatability in all possible configurations, I've only tested four with this.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)

mQGiBElz9bERBADHbO/o4DHTv5tNDs0N/QCL2nXKbLDMwLJatti6QtEDOB98yNeW
1oKaJ4B9kWJQanMy4fZZLPBriYybxUudU5RCqKY64KK3Pnc9oAMuYk5PxVO+7hrx
8GIShwJtEFVBpS4K59Re3VTK6r6uBNgBfteST3jy/XvuvXQSWi9408lCswCgnnGK
KYYoOiI4G6k5WJaURzWn6vcD/2lW4sEUFnCfVSFuTdP0/CSJQq4XUJsys1thsm6W
320u7wt8VEvXUV8HfzmcqnYj9Tpi51XMCvqpi1vb2awxEE4PZ2AtKgWXkqfJHzl1
IyqtGHyf5JOQUQJGdkf571f61cJhtyWCmlTMu9TLd5NilwwPtxMTrQSzA+f1xlaH
+hneBAC1invLXDeypGmPr6buv1LYfaK3PMpwjAhxYvCKBsqjSk/KYiiliHyNIFnq
xZdhTBLS6BjVJ7lNUHbKHmICToDaxbuTQdIKbBjMCAzf3xLZCiRP3F3jPF66QDO/
iDTLzKkvjjNwIliI5xbUGhDQu3ym842NbmsrGBoE4b75S+5DzLQbTHVrZSA8bHVr
ZWt1aG5AaG90bWFpbC5jb20+iGAEExECACAFAklz9bECGyMGCwkIBwMCBBUCCAME
FgIDAQIeAQIXgAAKCRCrYZ03I1TDoo14AKCapTyOXADsXtR9oAjvSwAbF/zNIgCe
OQvVHgmQ266jsNq1alG38b4UHzu5AQ0ESXP1tBAEALhyO0p3hLYVywLkgUEImo1M
qthrNk6gIMdRKMULSHtyCQWz6trl8W/hqz8dLdlYAM7Mxv681PJHCC4PEo9bYIdk
K7QJT62A8mQCHOtmX7uvGgeZBH53mdUct0D7LUyDW/mOxUp/yVy49LUhqO4YcNiA
NdCk1/fzZq9Yc3XouZTTAAMFA/45PsuZ12ZZdZSCj0PH02ByN95qVzXYP7714eY2
IFcFImuFsGqf3vrkbKPAhmypHDdzFIBuAyP2VkMW3T/2JPNtY7VelD6B1mUEJGvd
rQCavsYox98QMAg34aD+UcqzDwwSPa+fDfy9JQIGQeUPhMGrzBc+ZGAvtq7xNMn9
6gqxnIhJBBgRAgAJBQJJc/W0AhsMAAoJEKthnTcjVMOiQBYAnjqEF54U0HUdJ3JE
oYo/l5t7j7RRAJ98TzjlIc1pGxlnWBE91IIUq4FzZA==
=mwCZ
-----END PGP PUBLIC KEY BLOCK-----

> Date: Fri, 10 Apr 2009 05:00:49 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 55159] Re: usplash prevents passwords from being not echoed on the console
>
> Luke : Thanks for your great work. Unfortunately I get a different
> result here. I overwrited my /lib/cryptsetup/cryptdisks.functions file
> by the one provided in your comment #30 and I'm still able to see my
> passphrase echoed in plain text on console if I switch to console before
> finishing typing my passphrase using the initial steps in the bug
> description.
>
> I tested this with a luks partition which is mounted in "/media" (not a
> root partition) and therefore which is unlocked by cryptsetup during
> init.d and not initramfs.
>
> Can you see something that could be missing in your current fix so it
> can apply to the configuration I described?
>
> --
> usplash prevents passwords from being not echoed on the console
> https://bugs.launchpad.net/bugs/55159
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Quick access to your favorite MSN content and Windows Live with Internet Explorer 8.
http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MSN55C0701A

I'm sorry you're right, gedit apparently didn't save! Your cryptdisks.functions now works as expected and fixes the security issue (no output on the console). The only problem I got is what you already described, nothing happens when you type or when you typed a wrong passphrase. So far, very positive!

Kees Cook or Reinhard Tartler : Can you review Luke work and see if this can be considered for a update?

  Make sure Kees Cook and/or Reinhard Tartler get this latest update:

  NEW VERSION OF cryptdisks.functions gives full interactive prompting just like askpass does, but without echoing the password to the console. I have tested this with and without usplash, with different settings of "tries=" in /etc/crypttab, and can confirm it works in Jaunty on Intel atom and Athlon 64 single core.

   In the new version when using a LUKS partition, a do-while loop repeats as many times as "tries=" calls for , calling cryptsetup with tries=1. If the right passphrase is entered, cryptsetup returns 0, a prompt tells the user the encrypted device has been set up, and the loop breaks. With a bad passphrase, the user is prompted again and the loop repeats until either the right passphrase is entered or the limit in "tries=" has been reached.

  No change in behavior on console, no change from my last upgrade in behavior with a non-LUKS mapping. There is no way to have a bad passphrase re-call cryptsetup on a regular mapping within this script. This would require having cryptsetup and mount in the same script, for a substantial change in /etc/rcS.d . The workaround, of course, is to use LUKS in the first place, and it's far more secure by default.

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

Luke <email address hidden> writes:

> 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

look in the cryptsetup, it should be in the debian/ directory. It is a
program contributed by the debian packager.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

  I could not find a debian directory in either the cryptsetup 1.0.6.orig.tar.gz source package, nor in the cryptsetup 1.0.6-7ubuntu7_i386.deb Debian package, which does contain the 4 byte "debian-binary" file. The only other things named Debain I found were things like the news.debian.gz tarball and similar things in /usr/share/doc

 It is the source code for askpass.c that I need to find.

_________________________________________________________________
Get free photo software from Windows Live
http://www.windowslive.com/online/photos?ocid=PID23393::T:WLMTAGL:ON:WL:en-US:SI_PH_software:082009

Luke, use apt-get source cryptsetup to download the source including the debian patches. Then you’ll find debian/askpass.c in the cryptsetup directory.

Also the website http://packages.ubuntu.com/jaunty/cryptsetup lists the diff-file containing the askpass.c.

Found it! That Debian directory is would have saved me hours when I was first experimenting with getting encrypted resume,(from encrypted swap), home, /tmp,and /var/tmp with unencrypted binaries(for performance).

I can now see if I can find a way to make askpass never echo the passphrase back to console, assuming I can find the bug in the source code.

> Date: Tue, 4 Aug 2009 12:56:58 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 55159] Re: usplash prevents passwords from being not echoed on the console
>
> Luke, use apt-get source cryptsetup to download the source including the
> debian patches. Then you’ll find debian/askpass.c in the cryptsetup
> directory.
>
> Also the website http://packages.ubuntu.com/jaunty/cryptsetup lists the
> diff-file containing the askpass.c.
>
> --
> usplash prevents passwords from being not echoed on the console
> https://bugs.launchpad.net/bugs/55159
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/explore?ocid=PID23384::T:WLMTAGL:ON:WL:en-US:NF_BR_sync:082009

  Hwere's what I've found so far looking at the askpass source code:

Askpass writes to stdout, asnd this is piped into cryptsetup in the scripts cryptroot and cryptdisks.functions

When the cryptroot script in the initramfs calls askpass, there is no underlying terminal to take the output from stdout, it goes straight to cryptsetup

When the cryptdisks.functions script calls askpass with the root partition mounted and a console underlying the splash screen, the pipe from askpass to cryptsetup is acting strangely.

 The variable "pass" which askpass wrote to stdout, and which the cryptdisks.functions script pipes into cryptsetup, is then going BOTH into cryptsetup and to the console! In other words, the data to stdout is getting sent to the console,yet still "caught" and sent to cryptsetup.

A pipe or | in a script is not supposed do this-I've not seen this on any other program. I wonder if this has to do with the console itself not being fully initialized in some way when running beneath usplash?

If so, the bug is in the console itself.

I tried to get askpass to return the passphrase as it's exit value, but this did not work. The code compiled fine, but when the script was rewritten to use the $? variable as the key it did not work, at least in my first attempt. I have only limited experience writing anything in C , most of my experience is in shell scripting.

Anyway, using the exit value tp move the passphrase would screw up the use of the exit value for debugging. Either the console needs to be fixed, a better way found to move the passphrase from askpass to cryptsetup, or askpass would need to be rewritten as anothe shell script that could import and export variables. This would possibly slow down boot times.

I've seen other bugs in consoles under usplash before-in particular, when running ubuntu hardy and doing my early experiments with encrypted /home, swap, and /tmp partitions I sometimes encountered corrupted keyboards on this console.

If the console is fixed right, this whole cryptsetup bug should go away without having to change anything in cryptsetup, the askpass binary included.

_________________________________________________________________
Express your personality in color! Preview and select themes for Hotmail®.
http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_express:082009

I can confirm this bug with Jaunty and Karmic-Beta...

(Also filed a bug report: https://bugs.launchpad.net/ubuntu/+bug/454075 - might be of interest)

still in Karmic, unbelievable...

Same here with kubuntu...

The usplash package has been superseded by plymouth and has been removed from the Ubuntu archive. Closing all related bugs.