Version: (using KDE KDE 3.4.90) Installed from: Gentoo Packages OS: Linux (LUKS and some other things are briefly explained at the end. To make it short: KDE needs support for encrypted media. I don't know if I filed this wish for the correct product.) It would be great if KDE had complete HAL/LUKS integration. By this I mean that HAL notifies KDE over d-bus that a LUKS medium has been attached, upon which KDE asks the user for the passphrase and proceeds to mounting the volume. In other words, plugging in and accessing a LUKS-encrypted medium should be as straightforward as a for a normal non-encrypted medium. Some people, notably Michael Petullo, are working on LUKS support for HAL and Gnome. An outline of these efforts can be found at [1]. I'd like to stress that at first it would be more than sufficient to simply have support for passphrase input. (See also [2] for further LUKS-related ideas.) Now, for those who have never heard of LUKS... LUKS (Linux Unified Key Setup) [3] is a specification of how to store encryption keys in the first sector of a partition. These keys can be accessed using a passphrase. Subsequently a dm-crypt [4] mapping is created. This virtual block device can then be mounted like any other block device. I'd also like to add that I'm using a dm-encrypted home partition for nearly a year now, without any problems. luks is just a standardized way to set things up. I've now used luks for a few weeks on my external USB Hard Disk. It works perfectly, too. The only drawback to both is missing support in current desktop environments. [1] http://www.flyn.org/easycrypto/easycrypto.html [2] http://www.flyn.org/projects/luks-tools/ [3] http://luks.endorphin.org/about [4] http://www.saout.de/misc/dm-crypt/
*** Bug 94357 has been marked as a duplicate of this bug. ***
One additional consideration should be local encrypted filesystems which are *not* removable. Perhaps a partition, more likely a loopback filesystem image (in the form of a file on the HD). That was part of the point of 94357. Thanks!
I second comment 2 - that's what my report #109531 (marked as dupe) was about.
On Friday 30 September 2005 21:08, matt@eisgr.com wrote: > One additional consideration should be local encrypted filesystems which > are *not* removable. Perhaps a partition, more likely a loopback > filesystem image (in the form of a file on the HD). As the original reporter of this bug I'd also like to stress that this isn't meant to exclude support for local disks. In fact, I just realized that my report was too much centered on the HAL aspect. The important thing is LUKS support: it can also be used for local partitions and loopback images. Cryptoloop is deprecated in favour of dm-crypt (which offers a superset of cryptoloop's functionality). And luks is just a nicer interface to the lower level dm-crypt interface. I'd guess that in the relatively near future luks will replace the old encryption methods. But of course, KDE's support should not be limited to removable devices.
Exactly, that was my point and why I closed the old one as duplicate.
*** This bug has been confirmed by popular vote. ***
*** Bug 123293 has been marked as a duplicate of this bug. ***
*** Bug 121020 has been marked as a duplicate of this bug. ***
To add information which were in "my" duplicate of this bug: Gnome has a pretty nice implementation of Luks support for at least removable media: http://blog.fubar.dk/?p=64 http://www.redhat.com/magazine/012oct05/features/hal/ The second link is a nice documentation of the needed hal code. Besides: The perfect result would be Luks support which can be activated at the KDE login manager: I would like to have a luks encrypted home directory, and it would be nice to login and encrypt my partition just with one single passwort, that means: almost invisible for me.
Imho, mounting your home directory on login is not KDE's business. There's a PAM module that can do this (for any kind of login, not just KDE). http://pam-mount.sourceforge.net/
Anyway, pam_mount does not solve the problem of removable devices...
This feature is a must have, specially for removable media.
This feature would be really great. Why does Gnome have such a system but not KDE? The d-bus and HAL layers already receive messages if an LUKS encrypted USB stick is inserted. But apparently no application for key-input is implemented, yet. A work-around is to start the gnome-volume-manager out of your KDE session. That's not nice, but at least it works and you can use a graphical interface to login into the USB stick.
From http://en.opensuse.org/Factory/News: - usage of LUKS by default for crypto partitions in YaST. Both GNOME and KDE handle removable LUKS media now. So it should simply be a matter of reviewing the patches and merge, shouldn't it?
What is the status of that feature request? If anyone is interested, I was able to get code from SuSE working in Archlinux :) Here are sources with description how to do that: http://strony.aster.pl/tanis/kde_luks
I successfully compiled and used Jakub's code with KDE 3.5.7 on Fedora 7.
Nice, any chance that we will see this one upstream?
*** Bug 148374 has been marked as a duplicate of this bug. ***
I've used the code from #15 successfully on Fedora 7 also - had to install the dbus-devel, dbus-qt-devel and hal-devel packages first. Is there anyone reading this with the know-how to review the code and get it into KDE?
Two years of bug report, I think someone should mark kde media support as unmaintained :-)
Agreed :-( It's a pity it's not included, especially as it appears that it's already possible for it to work.
If all such patches get included immediately to upstream code, what will the difference be in between a mostly "pristine" upstream based distro (Debian) and an almost forked distro (SUSE/Red Hat) ? :-) But I might be wrong. Nothing apart from their policy stops the distros to pull the patches and include it in their distributions.
Reply to #22: I also opened a bug in Fedora to have this patch added to Fedora, but the Fedora maintainer seems to be AWOL on this issue too. :-( Reply to #20: I think Kevin has done a huge amount of work on KDE hardware support in the last two years for which we should all thank him and that you are mistaken. It's a shame we can't find someone who's a contributor who's motivated to add this patch though! This bug is #60 on the list of most requested features, but in the vast majority of cases those requested features don't have working, tested patches unlike this one. Has anyone tried the patch against KDE 3.5.8 now that that's out? Does it work?
Yes, I'm running it with 3.5.8 on Debian
Unfortunately, I would say that this patch is of poor quality - more like 'proof of concept', not a real thing that can be added as it is. I think, that the right approach would be to add more sophisticated solution to media manager - so it would be aware of the status of each volume - is it encrypted/decrypted, and could also change that status. But it probably is too much work for KDE 3.5, and probably should be done in 4. I just started working on a small external app/panel applet, that would offer the same behavior without the need to patch KDE.
Created attachment 22191 [details] LUKS suppport via kio media slave This is a patch I developed a month or two ago to add LUKS support to the kio media slave. The archive contains a diff (to be applied against kdebase) and a set of new icons. It enables state tracking (encrypted,unmounted / decrypted,unmounted / decrypted,mounted), adds a icon to each of the states and enables state manipulation ("encrypt" -> luksClose) via UI. The major drawback is that it adds three mime-types (and corresponding icons) to each media type, but this is caused by the architecture of the media slave. It was submitted to kde-devel but it seems this approach is a bit too complex and there is no 3.5.9 planned yet, so I didn't finish it yet... It works for me for USB pen drives and encrypted hdd partitions. Other media types are not supported. I post it here just in case anyone is interested...
Created attachment 23231 [details] LUKS support via kio media slave (updated 23/01/08) Updated the old patch (especially icons) to support now all types of removable media and fixed some minor bugs. Tested with encrypted USB HDD's, pen drives and MMC cards.
Still not working for me, shows password-field and dbus doesnt return any error, and dolphin shows as mounted, but when i click that place, it jumps back to Home (or current place)
Created attachment 23339 [details] LUKS support via kio media slave (updated 28/01/08) Some more bugfixes (wrong icon in kicker media applet, some dbus race conditions). @ZcMander: Any error messages? Is the drive shown as decrypted (open lock)? I don't use dolphin but it should work like in konqueror. For me it works without problems on Kubuntu 7.10.
Hello, I would just like to say that the first patch is included in the Kubuntu kdebase package: https://lists.ubuntu.com/archives/hardy-changes/2007-November/002319.html I am now working on including the lastest patch. Thanks Jonathan https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/128863
I'm trying to get the patch from additional comment #29 from Jan Klötzke 2008-01-28 23:29 running but I'm getting dialog.h:37:27: Fehler: decryptdialog.h: No such file or directory when compiling in kdebase-3.5.8/kioslave/media/mounthelper Where do I get decryptdialog.h from?
You have to run "make -f Makefile.cvs" first to run automake and friends. Then the build should work.
> ------- Hello, I would just like to say that the first patch is included in > the Kubuntu kdebase package: I can confirm that it works in Hardy, I get asked for a password, then whether I want to mount the device, maybe the second step could be automated?
If anyone is interested in a solution that doesn't involve patching KDE, I have created small utility which does all that (and some more) - for me it does everything I need. Have a look at http://strony.aster.pl/tanis/kde_luks/ (screenshots included ;) )
Jan Klötzke, can you modify your patch to support KDE 3.5.9? Thanks
Just to note that obviously the switch to KDE 4 changes things here. AFAIK it has no built-in LUKS support, and obviously this patch will not apply, so someone would need to write a new patch for KDE 4.
(In reply to comment #36) > Just to note that obviously the switch to KDE 4 changes things here. AFAIK it > has no built-in LUKS support, and obviously this patch will not apply, so > someone would need to write a new patch for KDE 4. > No. KDE 4, by default, has support for Encrypted LUKS devices. KDE 4 can detect LUKS Encrypted partitions and list them in Dolphin. There is one problem though. In KDE 4, for non-partitioned LUKS Encrypted Devices, KDE4 or hald is not able to detect the filesystem label on top of the encrypted device and thus doesn't automount it.
Ah, OK, that's good. I saw an Ubuntu bug report which suggested this was not the case.
(In reply to comment #37) > (In reply to comment #36) > > Just to note that obviously the switch to KDE 4 changes things here. AFAIK it > > has no built-in LUKS support, and obviously this patch will not apply, so > > someone would need to write a new patch for KDE 4. > > > > No. KDE 4, by default, has support for Encrypted LUKS devices. KDE 4 can detect > LUKS Encrypted partitions and list them in Dolphin. > > There is one problem though. In KDE 4, for non-partitioned LUKS Encrypted > Devices, KDE4 or hald is not able to detect the filesystem label on top of the > encrypted device and thus doesn't automount it. > Why doesn't KDE4 then detect that it's a luks filesystem(like it did), prompt user for unlock and then the label would be available/readable and mountable?
(In reply to comment #39) > Why doesn't KDE4 then detect that it's a luks filesystem(like it did), prompt > user for unlock and then the label would be available/readable and mountable? > This is not a bug specific to KDE. KDE just depends on the underneath infrastructure (hal/dbus) for information. In fact, the problem seems to be with HAL. My initial suspicion was that udev might not be generating the device entry/label correctly, but that doesn't seem to be the reason. Here, In Problematic case: Nov 11 23:10:38 learner udevd-event[5814]: udev_node_update_symlinks: update symlink 'disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e' of '/block/dm-2' Nov 11 23:10:38 learner udevd-event[5814]: udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-uuid\x2fbc1026e2-1393-49e7-a6f6-72c01e93b47e' Nov 11 23:10:38 learner udevd-event[5814]: update_link: found 1 devices with name 'disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e' Nov 11 23:10:38 learner udevd-event[5814]: update_link: found '/block/dm-2' for 'disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e' Nov 11 23:10:38 learner udevd-event[5814]: update_link: compare (our own) priority of '/block/dm-2' -100 >= 0 Nov 11 23:10:38 learner udevd-event[5814]: update_link: 'disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e' with target 'dm-2' has the highest priority -100, create it Nov 11 23:10:38 learner udevd-event[5814]: node_symlink: found existing symlink '/dev/disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e' Nov 11 23:10:38 learner udevd-event[5814]: node_symlink: preserve already existing symlink '/dev/disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e' to '../../dm-2' Nov 11 23:10:38 learner udevd-event[5814]: udev_node_update_symlinks: update symlink 'disk/by-label/USB_SEAGATE' of '/block/dm-2' Nov 11 23:10:38 learner udevd-event[5814]: udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-label\x2fUSB_SEAGATE' Nov 11 23:10:38 learner udevd-event[5814]: update_link: found 1 devices with name 'disk/by-label/USB_SEAGATE' Nov 11 23:10:38 learner udevd-event[5814]: update_link: found '/block/dm-2' for 'disk/by-label/USB_SEAGATE' Nov 11 23:10:38 learner udevd-event[5814]: update_link: compare (our own) priority of '/block/dm-2' -100 >= 0 Nov 11 23:10:38 learner udevd-event[5814]: update_link: 'disk/by-label/USB_SEAGATE' with target 'dm-2' has the highest priority -100, create it Nov 11 23:10:38 learner udevd-event[5814]: node_symlink: found existing symlink '/dev/disk/by-label/USB_SEAGATE' Nov 11 23:10:38 learner udevd-event[5814]: node_symlink: preserve already existing symlink '/dev/disk/by-label/USB_SEAGATE' to '../../dm-2' Nov 11 23:10:38 learner udevd-event[5814]: pass_env_to_socket: passed 751 bytes to socket '/org/freedesktop/hal/udev_event', Nov 11 23:10:38 learner udevd-event[5814]: pass_env_to_socket: passed -1 bytes to socket '@/org/kernel/udev/monitor', Nov 11 23:10:38 learner udevd-event[5814]: udev_event_run: seq 1435 finished with 0 Nov 11 23:10:38 learner udevd[1240]: udev_done: seq 1435, pid [5814] exit with 0, 0 seconds old udev did its job. it exited cleanly. Now the non-problematic case: Nov 11 23:15:54 learner udevd-event[6064]: udev_node_update_symlinks: update symlink 'disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e' of '/block/dm-3' Nov 11 23:15:54 learner udevd-event[6064]: udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-uuid\x2fb1d29a26-9d95-4aa4-8d9d-9498a874312e' Nov 11 23:15:54 learner udevd-event[6064]: update_link: found 1 devices with name 'disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e' Nov 11 23:15:54 learner udevd-event[6064]: update_link: found '/block/dm-3' for 'disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e' Nov 11 23:15:54 learner udevd-event[6064]: update_link: compare (our own) priority of '/block/dm-3' -100 >= 0 Nov 11 23:15:54 learner udevd-event[6064]: update_link: 'disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e' with target 'dm-3' has the highest priority -100, create it Nov 11 23:15:54 learner udevd-event[6064]: node_symlink: found existing symlink '/dev/disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e' Nov 11 23:15:54 learner udevd-event[6064]: node_symlink: preserve already existing symlink '/dev/disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e' to '../../dm-3' Nov 11 23:15:54 learner udevd-event[6064]: udev_node_update_symlinks: update symlink 'disk/by-label/USBDISK' of '/block/dm-3' Nov 11 23:15:54 learner udevd-event[6064]: udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-label\x2fUSBDISK' Nov 11 23:15:54 learner udevd-event[6064]: update_link: found 1 devices with name 'disk/by-label/USBDISK' Nov 11 23:15:54 learner udevd-event[6064]: update_link: found '/block/dm-3' for 'disk/by-label/USBDISK' Nov 11 23:15:54 learner udevd-event[6064]: update_link: compare (our own) priority of '/block/dm-3' -100 >= 0 Nov 11 23:15:54 learner udevd-event[6064]: update_link: 'disk/by-label/USBDISK' with target 'dm-3' has the highest priority -100, create it Nov 11 23:15:54 learner udevd-event[6064]: node_symlink: found existing symlink '/dev/disk/by-label/USBDISK' Nov 11 23:15:54 learner udevd-event[6064]: node_symlink: preserve already existing symlink '/dev/disk/by-label/USBDISK' to '../../dm-3' Nov 11 23:15:54 learner udevd-event[6064]: pass_env_to_socket: passed 735 bytes to socket '/org/freedesktop/hal/udev_event', Nov 11 23:15:54 learner udevd-event[6064]: pass_env_to_socket: passed -1 bytes to socket '@/org/kernel/udev/monitor', Nov 11 23:15:54 learner udevd-event[6064]: udev_event_run: seq 1459 finished with 0 Nov 11 23:15:54 learner udevd[1240]: udev_done: seq 1459, pid [6064] exit with 0, 0 seconds old Nov 11 23:15:54 learner NetworkManager: <debug> [1226425554.923853] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/volume_uuid_b1d29a26_9d95_4aa4_8d9d_9498a874312e'). Here too udev did its job. But here also the device got added to hal. KDE4 must be relying on hal for device discovery/state. So this seems to be a bug with HAL not adding partition-less crypt devices into its database. PS: Does anyone know what NetworkManager has to do with in the logs ?
In a google search, for "hal luks disk encryption", I've seen some related articles, altough, since I'm not familiar enough with hal, I can not assure if it has support or not. I'm just adding myself to CC, and vote, since now I use encrypted usb drives, I would like to see support for them in my desktop. Best regards!
KDE4 can mount LUKS devices but it is not complete yet. At first the StorageVolume manager doesn't show the encrypted devices which makes no sense if KDE4 can mount them imho. The second one is that Dolphin doesn't show any information about the encrypted devices. Gnome e.g. shows the size which is great since I have an USB hard disk with two encrypted devices (root and home). The third and most important drawback is that passwords can't be saved in Kwallet like Gnome does. If I attach a usb hard disk with a LUKS partition which password was saved under Gnome it is auto mounted like any other USB devices which makes working with LUKS very easy.
(In reply to comment #42) > KDE4 can mount LUKS devices but it is not complete yet. > At first the StorageVolume manager doesn't show the encrypted devices which > makes no sense if KDE4 can mount them imho. I'm not sure what you mean by StorageVolume Manager here. When an encrypted device is plgged in, it does get listed in Dolphin. And there you can open the encrypted volume and then you get the real decrypted device. But yes, there is no device notification for an ecrypted volume plugged in. > The second one is that Dolphin doesn't show any information about the encrypted > devices. Gnome e.g. shows the size which is great since I have an USB hard disk > with two encrypted devices (root and home). I'm not sure if info from an encrypted device can be extracted before it is decrypted. In dolphin, once the device is opened, the virtual decrypted device does have its size info listed. > The third and most important drawback is that passwords can't be saved in > Kwallet like Gnome does. If I attach a usb hard disk with a LUKS partition > which password was saved under Gnome it is auto mounted like any other USB > devices which makes working with LUKS very easy. > Yes, I think this applies.
>I'm not sure what you mean by StorageVolume Manager here. The KDE4 plugin which pops up from systray and shows the plugged in devices. >I'm not sure if info from an encrypted device can be extracted before it is >decrypted. The size of the partition should be no problem. More isn't needed. If you don't know any information about the devices you often have to mount both of them when you only need one. Btw. Nautilus shows always the size of an unmounted partition if it has no name. I guess this feature isn't implemented in Dolphin too. The only change between unnamed and LUKS partitions is the encrypted addition. Similar to this image: http://people.ubuntu.com/~jamesw/private-nautilus.png But of course the most important is the last one, the password saving.
OK, this one should have been closed long ago, it's spreading in too many directions. I'm closing it as the main issue: reading LUKS devices got fixed long ago in the KDE4 serie. Now if you have specific features missing for encrypted volumes in KDE4 please report them as *separate* entries and mark them as bugs or wish as appropriate.
I have created a new wishlist report for the password saving: https://bugs.kde.org/show_bug.cgi?id=186783