On Wednesday 04 November 2020 08:34:00 am Slávek Banko via tde-users wrote:

On Wednesday 04 of November 2020 13:06:32 Janek Stolarek wrote:

...

Somehow I imagined/hoped that R14.0.9 will be followed by R14.1.0. What is the roadmap for the R14.1.0 release? I am eagerly awaiting support for decrypting encrypted external drives, which I believe Michele is working on as part of R14.1.0.

Yes, support for unlocking / locking encrypted disks is one of the things that will be in R14.1.0. If you want to test it, you can consider using the PTB repository => Preliminary Testing Builds, which is based on the master branch.

I've been using LUKS for a long time on several different distributions, all with TDE installed. So this conversation has made me curious how TDE having ‘support for unlocking / locking encrypted disks’ is different than what is currently in use?

Current usage: root keyfile {optional for non-root drives, must use passkey on root drive*} /etc/crypttab /etc/fstab

And AFAIK, that works for any drive (USB or otherwise) ‘see-able’ by the system.

How’s the TDE process going to look? Will it interfere with current usage of LUKS? (Seriously don’t want all my drives to just ‘stop working!’)

Thanks, Michael

* That’s not technically true, there are some hybrid USB holds the passkey methodologies. (Granted you’d probably want to store the USB in a safe. And how paranoid do you have to be to not let an employee be able to unlock their system by themselves....)

On Wednesday 04 November 2020 01:29:46 pm Janek Stolarek wrote:

...

I've been using LUKS for a long time on several different distributions, all with TDE installed. So this conversation has made me curious how TDE having ‘support for unlocking / locking encrypted disks’ is different than what is currently in use?

The way TDE 14.0.9 currently works (on my machine at least) is that when I plug in an encrypted external USB drive, Konqueror will ask for a password to unlock it, but upon entering the password it will report an error. So what I do is use a script that unlocks the LUKS device and mounts it*, at which point Konqueror again asks for a password to unlock the device except now that the device has been unlocked it mounts it correctly. I now wonder whether you know a way to bypass the need of unlocking/mounting the drive using a script?

Janek

*) Now that I wrote it I'm wondering whether the mounting step is necessary.

Hi Janek,

It took me a huge amount of reading to figure 2nd drive LUKS out (refs below). In a nutshell you just need to know the UUID and the passphrase and you can get your system to basically mount and un-mount LUKS the same as it does any normal drive.

I only have my pidgen notes, so translate with the Refs :( I’ve added companion commands in several places to show the name match-ups, so skip anything you’ve already done. Do NOT copy/paste! It’s so easy to wipe the wrong drive with all the sda, sdb, sdc’s... And I found at least two of my own copy/pastes that had sdb instead of sda, so uhg...

Note: I use sda mapping to lesda throughout for the below examples. (My boot drive is nvme0n1 not the usual sda)

Note: I don’t use partitions when LUKSing an entire drive (no point, wastes space).

!Note to everyone! Seriously, if you haven’t read up on and understand LUKS, you will fubar your system by blindly following the below.

Assumptions: - rootfs is LUKS - swapfs is LUKS

First: - Move Swap's keyfile to a safer place! - I place all keyfiles in /root/.luks/

Then:

{snip, see attached text file, email wrapping was eating the commands}

# # #

I think that’s about it.

Best, Michael

Commands: ## cryptsetup luksFormat <target device> ## cryptsetup luksDump <target device> ## cryptsetup luksOpen <target device> c1 ## mkfs.ext4 /dev/mapper/vg_backup-backup ## {mount} ## cryptsetup luksAddKey /dev/sdb1 -S 5

Refs: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions 2.1 LUKS Container Setup mini-HOWTO 2.19 How can I wipe a device with crypto-grade randomness?

https://lobotuerto.com/blog/how-to-setup-full-disk-encryption-on-a-secondary... https://www.erianna.com/adding-an-secondary-encrypted-drive-with-lvm-to-ubun... https://askubuntu.com/questions/918021/encrypted-custom-install https://eve.gd/2012/11/02/luks-encrypting-multiple-partitions-on-debianubunt...

On 2020/11/05 03:29 AM, Janek Stolarek wrote:

...

I've been using LUKS for a long time on several different distributions, all with TDE installed. So this conversation has made me curious how TDE having ‘support for unlocking / locking encrypted disks’ is different than what is currently in use?

The way TDE 14.0.9 currently works (on my machine at least) is that when I plug in an encrypted external USB drive, Konqueror will ask for a password to unlock it, but upon entering the password it will report an error. So what I do is use a script that unlocks the LUKS device and mounts it*, at which point Konqueror again asks for a password to unlock the device except now that the device has been unlocked it mounts it correctly. I now wonder whether you know a way to bypass the need of unlocking/mounting the drive using a script?

Hi everyone, I reply here to both Michael and Janek.

You can use LUKS disks in many ways. 1) you can unlock, mount, unmount and lock from CLI. This obviously works already in TDE R14.0.x (in fact it has nothing to do with TDE) 2) AFAIK, you can get use /etc/crypt, /etc/fstab and a password file to get the disk to auto unlock and then mount. This also works in R14.0.x

What does not work in R14.0.x is that if you have a LUKS disks and you don't use the above methods, then you can't use the disk. Konqueror will ask for a password but it will fail unlocking the disk. In R14.1.0 you will be able to click on a LUKS disk, enter a password and unlock the disk. Similarly you can lock it back. So if you plug in the occasional USB LUKS drive or if you want to manually unlock the disk (extra safety, you must type the password each time, no stored password file), then you can do it from Konqueror/KDesktop/KDCOP. There are more changes under the hood, but this is the core feature. Small note: in R14.1.0 an unlocked LUKS disk is a separate entity from its mountable disk. Meaning if you have a /dev/sdb1 LUKS disk, this will be lockable/unlockable, but not mountable. When unlocked, there will be a separate device (/dev/dm-0 in most cases) which is the actual mountable/unmountable drive. It may seems cumbersome, but this is how the OS handles the drives behind the scenes anyway. Moreover you may have more complex structures with LVM or RAID and for those cases it is necessary to handle the encrypted disk separately from its "children" disks.

For those interested, you can try PTB inside a VM :-) Hope this helps.

Cheers Michele

• add pinentry-tqt

from https://bugs.trinitydesktop.org/show_bug.cgi?id=2830#c7

unfortunately the git repo is not available anymore:

git clone git://git.incenp.org/pinentry.git pinentry-tqt Cloning into 'pinentry-tqt'... fatal: unable to connect to git.incenp.org: git.incenp.org[0: 51.254.143.22]: errno=Connection timed out git.incenp.org[1: 2001:41d0:302:2000::43d4]: errno=Network is unreachable