usplash prevents passwords from being not echoed on the console
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cryptsetup (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
usplash (Ubuntu) |
Invalid
|
Medium
|
Unassigned | ||
Feisty |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
/etc/init.
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
Jan (jan23) wrote : | #1 |
Jan (jan23) wrote : | #2 |
Why has this bug low urgency? I would classify it high or critical!
Changed in usplash: | |
status: | Unconfirmed → Confirmed |
Daniel Hahler (blueyed) wrote : | #3 |
This appears to be fixed in Gutsy (usplash 0.5.2): you get a password prompt through usplash
Daniel Hahler (blueyed) wrote : | #4 |
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.
Changed in usplash: | |
status: | New → Confirmed |
status: | Confirmed → Fix Released |
hunger (hunger) wrote : | #5 |
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).
Saivann Carignan (oxmosys) wrote : | #6 |
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.
Changed in usplash: | |
importance: | Undecided → Medium |
status: | Fix Released → New |
Saivann Carignan (oxmosys) wrote : | #7 |
Since bug 139363 has been fixed, this security issue can now be reproduced in intrepid.
Changed in usplash: | |
importance: | Medium → High |
status: | New → Confirmed |
description: | updated |
description: | updated |
Saivann Carignan (oxmosys) wrote : | #8 |
- cryptsetup_1.0.6-6ubuntu2.debdiff Edit (1.0 KiB, text/plain)
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.
Reinhard Tartler (siretart) wrote : Re: [Bug 55159] Re: usplash prevents passwords from being not echoed on the console | #9 |
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
Saivann Carignan (oxmosys) wrote : | #10 |
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?
Reinhard Tartler (siretart) wrote : | #11 |
Well, sure, since AFAIU the code, /lib/cryptsetup
Saivann Carignan (oxmosys) wrote : | #12 |
Exactly! So why it works in the initramfs hook and not in the init script? That's my main interrogation.
Reinhard Tartler (siretart) wrote : | #13 |
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
Saivann Carignan (oxmosys) wrote : | #14 |
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!
Tonic Artos (tonic) wrote : | #15 |
askpass.c echoes back to the commandline when it exits. I am working on this to fix it.
---
tonic@Io:
Test: ghghg
tonic@Io:
it should be
tonic@Io:
Test:
tonic@Io:
Tonic
Tonic Artos (tonic) wrote : | #16 |
no wait... I'm a noob nm
Tonic Artos (tonic) wrote : | #17 |
tonic@Io:
Test:
tonic@Io:
It is doing exactly as it should be.... :(
Reinhard Tartler (siretart) wrote : | #18 |
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.
Changed in cryptsetup: | |
status: | New → Invalid |
Rumpeltux (rumpeltux) wrote : | #19 |
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.
LumpyCustard (orangelumpycustard) wrote : | #20 |
Please close for Feisty as Won't Fix? This goes for all the other Feisty bugs.
Changed in usplash: | |
status: | Confirmed → Won't Fix |
Michael Flaig (mflaig) wrote : | #21 |
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.
Kees Cook (kees) wrote : | #22 |
I cannot reproduce this issue. What are the contents of your /etc/crypttab?
Changed in usplash: | |
importance: | High → Medium |
status: | Confirmed → Incomplete |
Saivann Carignan (oxmosys) wrote : | #23 |
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.
Saivann Carignan (oxmosys) wrote : | #24 |
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.
Michael Flaig (mflaig) wrote : | #25 |
@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/
cswap /dev/mapper/
Michael Flaig (mflaig) wrote : | #26 |
Setting to confirmed. This bug affects lots of people.
Changed in usplash: | |
status: | Incomplete → Confirmed |
kernelOfTruth (dalinuxlova) wrote : | #27 |
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 !
kernelOfTruth (dalinuxlova) wrote : | #28 |
ah - sorry, forget to post system-information:
system is:
Jaunty (testing), 9.04 post Alpha6-state, amd64 on an Dell m1330
Luke (lukekuhn) wrote : | #29 |
- Alternate /lib/cryptsetup/cryptdisks.functions Edit (12.8 KiB, text/plain)
FIX FOR BOTH HARDY AND JAUNTY:
Some time back, I modified /lib/cnryptsetu
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_
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.
#######
#
# This file is for inclusion with
# . /lib/cryptsetup
# and should not be executed directly.
PATH="/sbin:/bin"
TABFILE=
CRYPTDISKS_
#set -x
# Sanity checks
[ -x /sbin/cryptsetup ] || exit 0
[ -f "$TABFILE" ] || exit 0
. /lib/lsb/
if [ -r /etc/default/
. /etc/default/
fi
MOUNT="
case "$CRYPTDISKS_
[Nn]*)
exit 0
;;
esac
# Always output to console
stdin=`readlink /proc/self/fd/0`
if [ "${stdin#
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=
fi
if [ -x "$VALUE" ]; then
CHECK="$VALUE"
elif [ -x "/lib/cryptsetu
CHECK=
else
log_warning_msg "check $VALUE is not an executable script, skipping"
return 1
fi
;;
checkargs)
...
Luke (lukekuhn) wrote : | #30 |
- Broader patch for secure Usplash passphrase entry for both LUKS and non-LUKS mappings Edit (13.3 KiB, text/plain)
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.
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.
Luke (lukekuhn) wrote : | #31 |
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(
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.
Saivann Carignan (oxmosys) wrote : | #32 |
Luke : Thanks for your great work. Unfortunately I get a different result here. I overwrited my /lib/cryptsetup
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?
Luke (lukekuhn) wrote : RE: [Bug 55159] Re: usplash prevents passwords from being not echoed on the console | #33 |
Odd-I've tested this again and again on my own system. Reopen cryptdisks.
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.
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.
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)
mQGiBElz9bERBAD
1oKaJ4B9kWJQanM
8GIShwJtEFVBpS4
KYYoOiI4G6k5WJa
320u7wt8VEvXUV8
IyqtGHyf5JOQUQJ
+hneBAC1invLXDe
xZdhTBLS6BjVJ7l
iDTLzKkvjjNwIli
ZWt1aG5AaG90bWF
FgIDAQIeAQIXgAA
OQvVHgmQ266jsNq
qthrNk6gIMdRKMU
K7QJT62A8mQCHOt
NdCk1/fzZq9Yc3X
IFcFImuFsGqf3vr
rQCavsYox98QMAg
6gqxnIhJBBgRAgA
oYo/l5t7j7RRAJ9
=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
> by the one provided in your comment #30 and I'm still able to see my
> passphrase echoed in plain text on console ...
Luke (lukekuhn) wrote : | #34 |
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-
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)
mQGiBElz9bERBAD
1oKaJ4B9kWJQanM
8GIShwJtEFVBpS4
KYYoOiI4G6k5WJa
320u7wt8VEvXUV8
IyqtGHyf5JOQUQJ
+hneBAC1invLXDe
xZdhTBLS6BjVJ7l
iDTLzKkvjjNwIli
ZWt1aG5AaG90bWF
FgIDAQIeAQIXgAA
OQvVHgmQ266jsNq
qthrNk6gIMdRKMU
K7QJT62A8mQCHOt
NdCk1/fzZq9Yc3X
IFcFImuFsGqf3vr
rQCavsYox98QMAg
6gqxnIhJBBgRAgA
oYo/l5t7j7RRAJ9
=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
> 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:/
> 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://
Saivann Carignan (oxmosys) wrote : | #35 |
I'm sorry you're right, gedit apparently didn't save! Your cryptdisks.
Kees Cook or Reinhard Tartler : Can you review Luke work and see if this can be considered for a update?
Luke (lukekuhn) wrote : | #36 |
- NEW version of cryptdisks.functions :Fullly interactive yet secure Edit (14.1 KiB, text/plain)
Make sure Kees Cook and/or Reinhard Tartler get this latest update:
NEW VERSION OF cryptdisks.
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.
Luke (lukekuhn) wrote : | #37 |
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
Reinhard Tartler (siretart) wrote : Re: [Bug 55159] Re: usplash prevents passwords from being not echoed on the console | #38 |
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
Luke (lukekuhn) wrote : RE: [Bug 55159] Re: usplash prevents passwords from being not echoed on the console | #39 |
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_
It is the source code for askpass.c that I need to find.
_______
Get free photo software from Windows Live
http://
Rumpeltux (rumpeltux) wrote : | #40 |
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://
Luke (lukekuhn) wrote : RE: [Bug 55159] Re: usplash prevents passwords from being not echoed on the console | #41 |
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://
> diff-file containing the askpass.c.
>
> --
> usplash prevents passwords from being not echoed on the console
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
_______
Windows Live™: Keep your life in sync.
http://
Luke (lukekuhn) wrote : RE: [Bug 55159] Re: usplash prevents passwords from being not echoed on the console | #42 |
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.
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.
The variable "pass" which askpass wrote to stdout, and which the cryptdisks.
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://
Enno Lohmeier (e-lohmeier-deactivatedaccount) wrote : | #43 |
I can confirm this bug with Jaunty and Karmic-Beta...
(Also filed a bug report: https:/
Michael Reinsch (mr-uue) wrote : | #44 |
still in Karmic, unbelievable...
Alex10336 (ap10336) wrote : | #45 |
Same here with kubuntu...
Phillip Susi (psusi) wrote : | #46 |
The usplash package has been superseded by plymouth and has been removed from the Ubuntu archive. Closing all related bugs.
Changed in usplash (Ubuntu): | |
status: | Confirmed → Invalid |
I can confirm this bug with Edgy Beta.