| 2009-01-04 19:10:13 |
Jonathan Ernst |
bug |
|
|
added bug |
| 2009-01-04 19:10:35 |
Jonathan Ernst |
description |
How to reproduce :
1) setup a private directory
2)
sudo -s
cd /
mkdir source
mkdir target
cp ~user/.Private/example.pdf source
file /source/example.pdf
/source/example.pdf: data
mount -t ecryptfs source target
Passphrase: type anything that is not your passphrase or passwords
Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:
Select key bytes:
1) 16
2) 32
3) 24
Selection [16]:
Enable plaintext passthrough (y/n) [n]: n
Attempting to mount with the following options:
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=4c748f746abcc24e
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.
Would you like to proceed with the mount (yes/no)? yes
Would you like to append sig [4c748f746abcc24e] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs
file /source/example.pdf
/source/example.pdf: PDF document, version 1.4
Now I know that the files are really encrypted (using a wrong passphrase on files copied to any computer makes the file unreadable), but I don't understand how root on my system can mount my files without the correct passphrase... is the passphrase stored somewhere? This is really strange and doesn't give me too much confidence in this technology. Let's hope I overlooked something. |
How to reproduce :
1) setup a private directory
2)
sudo -s
cd /
mkdir source
mkdir target
cp ~user/.Private/example.pdf source
file /source/example.pdf
/source/example.pdf: data
mount -t ecryptfs source target
Passphrase: type anything that is not your passphrase or passwords
Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:
Select key bytes:
1) 16
2) 32
3) 24
Selection [16]:
Enable plaintext passthrough (y/n) [n]: n
Attempting to mount with the following options:
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=4c748f746abcc24e
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.
Would you like to proceed with the mount (yes/no)? yes
Would you like to append sig [4c748f746abcc24e] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs
file /source/example.pdf
/source/example.pdf: PDF document, version 1.4
Now I know that the files are really encrypted (using a wrong passphrase on files copied to another computer makes the file unreadable), but I don't understand how root on my system can mount my files without the correct passphrase... is the passphrase stored somewhere? This is really strange and doesn't give me too much confidence in this technology. Let's hope I overlooked something. |
|
| 2009-01-05 03:48:45 |
Marc Deslauriers |
bug |
|
|
added subscriber Dustin Kirkland |
| 2009-01-05 03:54:13 |
Dustin Kirkland |
ecryptfs-utils: status |
New |
Invalid |
|
| 2009-01-05 03:54:13 |
Dustin Kirkland |
ecryptfs-utils: statusexplanation |
|
|
|
| 2009-01-26 17:27:52 |
Dustin Kirkland |
ecryptfs-utils: status |
Invalid |
In Progress |
|
| 2009-01-26 17:27:52 |
Dustin Kirkland |
ecryptfs-utils: statusexplanation |
|
Actually, I have a reasonable solution to this problem...
I'm going to add the keyctl keyring clearing to the ecryptfs-umount-private shell script wrapper.
The recommended mechanism for unmounting your private data AND clearing your keyring of the relevant keys will be to use the helper:
$ ecryptfs-umount-private
Working on this at the moment...
:-Dustin |
|
| 2009-01-26 17:28:19 |
Dustin Kirkland |
bug |
|
|
assigned to ecryptfs |
| 2009-01-26 17:40:26 |
Dustin Kirkland |
ecryptfs: status |
New |
In Progress |
|
| 2009-01-26 17:40:26 |
Dustin Kirkland |
ecryptfs: assignee |
|
kirkland |
|
| 2009-01-26 17:40:26 |
Dustin Kirkland |
ecryptfs: importance |
Undecided |
Medium |
|
| 2009-01-26 17:40:26 |
Dustin Kirkland |
ecryptfs: statusexplanation |
|
|
|
| 2009-01-26 18:56:02 |
Dustin Kirkland |
ecryptfs: status |
In Progress |
Triaged |
|
| 2009-01-26 18:56:02 |
Dustin Kirkland |
ecryptfs: statusexplanation |
|
I have committed a partial fix, will be in the -69 release.
See:
* http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=commit;h=1abdd21606f764382f2abc8a73abda091ace76fd
This will clear the keyring of the relevant keys in the encrypted home/encrypted private case (ie, if you're using our helpers).
Otherwise, you need to clear your keyring with "keyctl clear @u", or prune out particular key(s) with "keyctl unlink $FOO @u".
Tyler has mentioned a possibility of solving this with an umount.ecryptfs helper, as an option. As such, I'm going to leave this upstream bug open, and assign it to him.
:-Dustin |
|
| 2009-01-26 18:56:53 |
Dustin Kirkland |
ecryptfs: assignee |
kirkland |
tyhicks |
|
| 2009-01-26 18:56:53 |
Dustin Kirkland |
ecryptfs: statusexplanation |
I have committed a partial fix, will be in the -69 release.
See:
* http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=commit;h=1abdd21606f764382f2abc8a73abda091ace76fd
This will clear the keyring of the relevant keys in the encrypted home/encrypted private case (ie, if you're using our helpers).
Otherwise, you need to clear your keyring with "keyctl clear @u", or prune out particular key(s) with "keyctl unlink $FOO @u".
Tyler has mentioned a possibility of solving this with an umount.ecryptfs helper, as an option. As such, I'm going to leave this upstream bug open, and assign it to him.
:-Dustin |
|
|
| 2009-01-26 18:57:24 |
Dustin Kirkland |
title |
ecryptfs can be mounted with any passphrase |
umount of ecryptfs does not automatically clear the keyring (was: ecryptfs can be mounted with any passphrase) |
|
| 2009-01-26 19:02:09 |
Dustin Kirkland |
bug |
|
|
added subscriber Tyler Hicks |
| 2009-01-26 19:50:09 |
Launchpad Janitor |
ecryptfs-utils: status |
In Progress |
Fix Released |
|
| 2009-01-27 15:19:54 |
Dustin Kirkland |
bug |
|
|
added subscriber Michal Hlavinka |
| 2009-01-27 15:30:43 |
Dustin Kirkland |
bug |
|
|
assigned to ecryptfs-utils (Fedora) |
| 2009-01-29 13:48:22 |
Bug Watch Updater |
ecryptfs-utils: status |
Unknown |
Confirmed |
|
| 2009-02-06 08:41:31 |
Tyler Hicks |
bug |
|
|
added attachment '0001-Automatically-unlink-fekek-and-fnek-at-unmount-with.patch' ([PATCH] Automatically unlink fekek and fnek at unmount with mount helpers) |
| 2009-02-09 00:29:29 |
Dustin Kirkland |
ecryptfs: status |
Triaged |
Fix Committed |
|
| 2009-02-14 01:41:04 |
Dustin Kirkland |
ecryptfs: status |
Fix Committed |
Fix Released |
|
| 2009-02-14 01:41:04 |
Dustin Kirkland |
ecryptfs: statusexplanation |
|
Fixed in ecryptfs-utils-70.
:-Dustin |
|
| 2009-02-16 21:46:57 |
Bug Watch Updater |
ecryptfs-utils: status |
Confirmed |
Fix Committed |
|
| 2009-03-10 04:52:36 |
Bug Watch Updater |
ecryptfs-utils: status |
Fix Committed |
Fix Released |
|
| 2009-03-24 19:52:58 |
Tyler Hicks |
ecryptfs: status |
Fix Released |
In Progress |
|
| 2009-03-24 19:52:58 |
Tyler Hicks |
ecryptfs: statusexplanation |
Fixed in ecryptfs-utils-70.
:-Dustin |
Reopening this bug. Dustin and Michal are both reporting that the unlinking doesn't work from PAM.
We could put some code in umount.ecryptfs_private to do the unlinking, but since that is a setuid binary in most/all distros, lets keep it simple.
We shouldn't have umount.ecryptfs_private execute umount.ecryptfs because that isn't keeping it simple *and* umount.ecryptfs will be executed as root, making it difficult/impossible to unlink the user's keys.
This functionality should go into the kernel. |
|
| 2009-04-24 20:02:45 |
Dustin Kirkland |
ecryptfs: status |
In Progress |
Incomplete |
|
| 2009-05-04 19:47:55 |
Dustin Kirkland |
ecryptfs: status |
Incomplete |
Triaged |
|
| 2009-05-04 19:47:55 |
Dustin Kirkland |
ecryptfs: assignee |
Tyler Hicks (tyhicks) |
Dustin Kirkland (kirkland) |
|
| 2009-12-09 11:48:12 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/ecryptfs-utils |
|
| 2010-01-22 03:48:59 |
Dustin Kirkland |
ecryptfs: status |
Triaged |
In Progress |
|
| 2010-02-17 16:54:42 |
Dustin Kirkland |
attachment added |
|
pam.diff http://launchpadlibrarian.net/39308219/pam.diff |
|
| 2010-02-17 16:55:12 |
Dustin Kirkland |
attachment added |
|
ecryptfs.diff http://launchpadlibrarian.net/39308227/ecryptfs.diff |
|
| 2010-02-17 16:55:30 |
Dustin Kirkland |
ecryptfs: status |
In Progress |
Triaged |
|
| 2010-02-17 16:55:50 |
Dustin Kirkland |
summary |
umount of ecryptfs does not automatically clear the keyring (was: ecryptfs can be mounted with any passphrase) |
umount of ecryptfs does not automatically clear the keyring (was: ecryptfs can be mounted by root later) |
|
| 2010-02-17 16:56:07 |
Dustin Kirkland |
summary |
umount of ecryptfs does not automatically clear the keyring (was: ecryptfs can be mounted by root later) |
umount of ecryptfs does not automatically clear the keyring (can be mounted by root later) |
|
| 2010-02-17 19:29:14 |
Dustin Kirkland |
visibility |
private |
public |
|
| 2010-02-17 19:29:14 |
Dustin Kirkland |
security vulnerability |
yes |
no |
|
| 2010-05-06 22:15:26 |
Marc Deslauriers |
ecryptfs-utils (Ubuntu): status |
Fix Released |
Confirmed |
|
| 2010-05-06 22:15:37 |
Marc Deslauriers |
nominated for series |
|
Ubuntu Jaunty |
|
| 2010-05-06 22:15:37 |
Marc Deslauriers |
bug task added |
|
ecryptfs-utils (Ubuntu Jaunty) |
|
| 2010-05-06 22:15:37 |
Marc Deslauriers |
nominated for series |
|
Ubuntu Karmic |
|
| 2010-05-06 22:15:37 |
Marc Deslauriers |
bug task added |
|
ecryptfs-utils (Ubuntu Karmic) |
|
| 2010-05-06 22:15:37 |
Marc Deslauriers |
nominated for series |
|
Ubuntu Maverick |
|
| 2010-05-06 22:15:37 |
Marc Deslauriers |
bug task added |
|
ecryptfs-utils (Ubuntu Maverick) |
|
| 2010-05-06 22:15:37 |
Marc Deslauriers |
nominated for series |
|
Ubuntu Lucid |
|
| 2010-05-06 22:15:37 |
Marc Deslauriers |
bug task added |
|
ecryptfs-utils (Ubuntu Lucid) |
|
| 2010-05-06 22:16:02 |
Marc Deslauriers |
ecryptfs-utils (Ubuntu Lucid): status |
New |
Confirmed |
|
| 2010-05-06 22:16:07 |
Marc Deslauriers |
ecryptfs-utils (Ubuntu Karmic): status |
New |
Confirmed |
|
| 2010-05-06 22:16:12 |
Marc Deslauriers |
ecryptfs-utils (Ubuntu Jaunty): importance |
Undecided |
Medium |
|
| 2010-05-06 22:16:15 |
Marc Deslauriers |
ecryptfs-utils (Ubuntu Jaunty): status |
New |
Confirmed |
|
| 2010-05-06 22:16:19 |
Marc Deslauriers |
ecryptfs-utils (Ubuntu Lucid): importance |
Undecided |
Medium |
|
| 2010-05-06 22:16:24 |
Marc Deslauriers |
ecryptfs-utils (Ubuntu Maverick): importance |
Undecided |
Medium |
|
| 2010-05-06 22:16:47 |
Marc Deslauriers |
ecryptfs-utils (Ubuntu Karmic): importance |
Undecided |
Medium |
|
| 2010-05-06 22:17:54 |
Marc Deslauriers |
security vulnerability |
no |
yes |
|
| 2010-07-26 18:22:02 |
papukaija |
tags |
|
jaunty karmic lucid maverick patch |
|
| 2010-07-26 18:23:04 |
papukaija |
bug |
|
|
added subscriber papukaija |
| 2010-08-10 02:44:20 |
Romualdo Caruso |
bug |
|
|
added subscriber Aldo Caruso |
| 2010-08-10 12:40:20 |
Mikko Rantalainen |
bug |
|
|
added subscriber Mikko Rantalainen |
| 2011-02-01 00:50:44 |
Dustin Kirkland |
ecryptfs: status |
Triaged |
In Progress |
|
| 2011-02-01 00:51:01 |
Dustin Kirkland |
nominated for series |
|
Ubuntu Natty |
|
| 2011-02-01 00:51:01 |
Dustin Kirkland |
bug task added |
|
ecryptfs-utils (Ubuntu Natty) |
|
| 2011-02-01 00:51:18 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Natty): status |
Confirmed |
In Progress |
|
| 2011-02-01 00:51:21 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Natty): assignee |
|
Dustin Kirkland (kirkland) |
|
| 2011-02-01 00:54:36 |
Launchpad Janitor |
branch linked |
|
lp:ecryptfs |
|
| 2011-02-01 00:56:49 |
Dustin Kirkland |
ecryptfs: status |
In Progress |
Fix Committed |
|
| 2011-02-01 00:56:55 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Natty): status |
In Progress |
Fix Committed |
|
| 2011-02-01 00:58:15 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Jaunty): status |
Confirmed |
Won't Fix |
|
| 2011-02-01 00:58:23 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Karmic): status |
Confirmed |
Triaged |
|
| 2011-02-01 00:58:27 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Maverick): status |
Confirmed |
Triaged |
|
| 2011-02-01 00:58:35 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Lucid): status |
Confirmed |
Triaged |
|
| 2011-02-01 01:39:50 |
Dustin Kirkland |
ecryptfs: status |
Fix Committed |
Fix Released |
|
| 2011-02-01 01:40:12 |
Launchpad Janitor |
ecryptfs-utils (Ubuntu Natty): status |
Fix Committed |
Fix Released |
|
| 2011-02-01 02:44:40 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/ecryptfs-utils |
|
| 2011-02-11 23:27:16 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Karmic): status |
Triaged |
In Progress |
|
| 2011-02-11 23:27:16 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Karmic): assignee |
|
Dustin Kirkland (kirkland) |
|
| 2011-02-11 23:27:41 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Lucid): status |
Triaged |
In Progress |
|
| 2011-02-11 23:27:41 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Lucid): assignee |
|
Dustin Kirkland (kirkland) |
|
| 2011-02-11 23:28:03 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Maverick): status |
Triaged |
In Progress |
|
| 2011-02-11 23:28:03 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Maverick): assignee |
|
Dustin Kirkland (kirkland) |
|
| 2011-02-11 23:34:37 |
Dustin Kirkland |
description |
How to reproduce :
1) setup a private directory
2)
sudo -s
cd /
mkdir source
mkdir target
cp ~user/.Private/example.pdf source
file /source/example.pdf
/source/example.pdf: data
mount -t ecryptfs source target
Passphrase: type anything that is not your passphrase or passwords
Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:
Select key bytes:
1) 16
2) 32
3) 24
Selection [16]:
Enable plaintext passthrough (y/n) [n]: n
Attempting to mount with the following options:
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=4c748f746abcc24e
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.
Would you like to proceed with the mount (yes/no)? yes
Would you like to append sig [4c748f746abcc24e] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs
file /source/example.pdf
/source/example.pdf: PDF document, version 1.4
Now I know that the files are really encrypted (using a wrong passphrase on files copied to another computer makes the file unreadable), but I don't understand how root on my system can mount my files without the correct passphrase... is the passphrase stored somewhere? This is really strange and doesn't give me too much confidence in this technology. Let's hope I overlooked something. |
How to reproduce :
1) setup a private directory
2)
sudo -s
cd /
mkdir source
mkdir target
cp ~user/.Private/example.pdf source
file /source/example.pdf
/source/example.pdf: data
mount -t ecryptfs source target
Passphrase: type anything that is not your passphrase or passwords
Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:
Select key bytes:
1) 16
2) 32
3) 24
Selection [16]:
Enable plaintext passthrough (y/n) [n]: n
Attempting to mount with the following options:
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=4c748f746abcc24e
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.
Would you like to proceed with the mount (yes/no)? yes
Would you like to append sig [4c748f746abcc24e] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs
file /source/example.pdf
/source/example.pdf: PDF document, version 1.4
Now I know that the files are really encrypted (using a wrong passphrase on files copied to another computer makes the file unreadable), but I don't understand how root on my system can mount my files without the correct passphrase... is the passphrase stored somewhere? This is really strange and doesn't give me too much confidence in this technology. Let's hope I overlooked something.
============
SRU Justification:
Impact: This bug affects users of Ubuntu's encrypted home/private directory feature if they are concerned about a malicious or snooping root user on the system.
Minimal patch: The minimal patch can be found in upstream commit r520:
* http://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/520
Reproduce instructions: Follow the excellent instructions in this bug description.
Regression potential: Minimal. The key removal code is the last thing that happens before the umount is attempted. If for some reason the new key-unlinking code failed (it should not; errors are ignored; keys are removed on a best-effort basis), then the umount might not happen. As I said, this should be a near impossible situation. I think this update should be very safe. It's been in Natty now for a couple of weeks.
============ |
|
| 2011-02-11 23:34:51 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Karmic): milestone |
|
karmic-updates |
|
| 2011-02-11 23:35:14 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Lucid): milestone |
|
lucid-updates |
|
| 2011-02-11 23:36:51 |
Dustin Kirkland |
ecryptfs-utils (Ubuntu Maverick): milestone |
|
maverick-updates |
|
| 2011-02-11 23:37:21 |
Dustin Kirkland |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2011-02-15 09:26:00 |
Martin Pitt |
ecryptfs-utils (Ubuntu Lucid): status |
In Progress |
Fix Committed |
|
| 2011-02-15 09:26:09 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2011-02-15 09:26:14 |
Martin Pitt |
tags |
jaunty karmic lucid maverick patch |
jaunty karmic lucid maverick patch verification-needed |
|
| 2011-02-15 10:35:45 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/lucid-proposed/ecryptfs-utils |
|
| 2011-02-23 21:03:08 |
Martin Pitt |
ecryptfs-utils (Ubuntu Maverick): status |
In Progress |
Fix Committed |
|
| 2011-02-23 21:35:17 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/maverick-proposed/ecryptfs-utils |
|
| 2011-03-08 09:21:35 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/karmic-proposed/ecryptfs-utils |
|
| 2011-04-18 15:58:17 |
Martin Pitt |
tags |
jaunty karmic lucid maverick patch verification-needed |
jaunty karmic lucid maverick patch verification-done |
|
| 2011-04-18 15:58:36 |
Martin Pitt |
tags |
jaunty karmic lucid maverick patch verification-done |
jaunty karmic lucid maverick patch verification-done verification-done-lucid verification-needed |
|
| 2011-04-19 06:56:55 |
Martin Pitt |
ecryptfs-utils (Ubuntu Karmic): status |
In Progress |
Fix Committed |
|
| 2011-04-19 06:57:25 |
Launchpad Janitor |
ecryptfs-utils (Ubuntu Lucid): status |
Fix Committed |
Fix Released |
|
| 2011-04-19 06:57:52 |
Martin Pitt |
tags |
jaunty karmic lucid maverick patch verification-done verification-done-lucid verification-needed |
jaunty karmic lucid maverick patch verification-done-lucid verification-needed |
|
| 2011-05-03 05:34:13 |
Martin Pitt |
ecryptfs-utils (Ubuntu Karmic): status |
Fix Committed |
Won't Fix |
|
| 2011-07-28 19:57:49 |
C de-Avillez |
tags |
jaunty karmic lucid maverick patch verification-done-lucid verification-needed |
jaunty karmic lucid maverick patch verification-done-lucid verification-done-maverick verification-needed |
|
| 2011-07-31 05:16:43 |
Marc Deslauriers |
tags |
jaunty karmic lucid maverick patch verification-done-lucid verification-done-maverick verification-needed |
jaunty karmic lucid maverick patch verification-done verification-done-lucid verification-done-maverick |
|
| 2011-08-01 00:31:53 |
Launchpad Janitor |
ecryptfs-utils (Ubuntu Maverick): status |
Fix Committed |
Fix Released |
|
| 2014-10-20 16:43:53 |
papukaija |
removed subscriber papukaija |
|
|
|
| 2017-10-27 00:08:30 |
Bug Watch Updater |
ecryptfs-utils (Fedora): importance |
Unknown |
High |
|
