We should act before the imminent destruction of the concepts of device ownership
I’m sadly starting to see a trend. Most phone bootloaders are locked nowadays. It’s not one specific manufacturer, it’s basically everyone.
If the OEM gives you the option to unlock them, it either voids the warranty or comes with severe punishment.
When you want to root your phone to get the liberty you lost to the “security features”, you basically break any apps that check for play integrity or other methods to detect root (even tho you can bypass that, it’s against TOS). I've mostly seen this on banking apps, but they are not the only ones. Not to mention that to even have the play integrity API, you have to have Google services installed and running. So you can't even de-Google your phone and keep the features.
This problem has been rampant on phones, it’s definitely not new, but it's basically the first thing that blocks the development of Linux for general phones.
Not to mention that no constructors follow a common thing like UEFI, they just all have their own thing. Which is a real pain for any kind of OS development.
Those aren’t the only issues tho, there's also all the proprietary blobs stuff. Without a way to either replicate them without reverse engineering, or open sourcing versions of the drivers, we will be stuck in this situation. Look at postmarketOS, they struggle a lot with this. This makes adding a device to their supported list a really hard thing to do, while costing a lot of time and money.
I think this will happen soon to laptops and desktops too. With the rise of ARM, I believe locking the bios and bootloader of those systems is not out of the question. Apple already kind of started with IBoot. It’s not fully locked, but definitely less open than what was used before in Intel macs.
And it’s not that ARM devices don't support UEFI, they absolutely do. Most Windows ARM systems use them right now. Arm’s SystemReady program allows them to boot just like x86 PCs do.
Then why the lockdown?
They will definitely say it’s for security, but Windows PCs, arm or not, have proven that you can have security while giving the user the choice to disable that security. UEFI and Secure Boot work just fine on ARM too, so it's not even a compatible issue. Secure defaults can be set as default, there is no problem with that. There is a really clear problem when those same defaults can’t be changed tho.
Now they'll probably argue that they didn't choose to do so, and that’s required by regulations.
I believe this is either misinformation, a stretch or a straight-up lie.
Radio and DRM firmware can stay on an isolated part of the device on their own. They don't need to prevent the entire OS boot process. The radio part already runs on an isolated part of the system on its own processor with signed firmware that complies with the FCC/RED requirements. The same thing goes for the DRM issue. User keys can allow for banking apps and all the other apps to verify the system without having to rely on OEM only control.
We need to act, not just complain
# What we should ask for:
We need to ask for owner-managed Secure Boot on every single type of general purpose computer. This goes for phones, smartwatches, computers… you get the point.
Either allow the user to disable secure boot or allow the user to manage their own keys, with proper documentation on how to do so.
We should also try to separate the concerns:
The radio and DRM stuff can be kept under signed, secure version on isolated systems to meet regulations.
This should NOT require a full system lockdown or OEM to have the full control over what you boot on YOUR device.
Provide documentation on how to interface with the hardware like GPS, Camera, GPUs and all to allow for third party OSes to develop properly without having to reverse engineer every single driver. This also means being able to develop proper alternatives to those NDA-only drivers.
We should have proper control over our device security:
Devices should be able to support TPM or DICE in a
I’m sadly starting to see a trend. Most phone bootloaders are locked nowadays. It’s not one specific manufacturer, it’s basically everyone.
If the OEM gives you the option to unlock them, it either voids the warranty or comes with severe punishment.
When you want to root your phone to get the liberty you lost to the “security features”, you basically break any apps that check for play integrity or other methods to detect root (even tho you can bypass that, it’s against TOS). I've mostly seen this on banking apps, but they are not the only ones. Not to mention that to even have the play integrity API, you have to have Google services installed and running. So you can't even de-Google your phone and keep the features.
This problem has been rampant on phones, it’s definitely not new, but it's basically the first thing that blocks the development of Linux for general phones.
Not to mention that no constructors follow a common thing like UEFI, they just all have their own thing. Which is a real pain for any kind of OS development.
Those aren’t the only issues tho, there's also all the proprietary blobs stuff. Without a way to either replicate them without reverse engineering, or open sourcing versions of the drivers, we will be stuck in this situation. Look at postmarketOS, they struggle a lot with this. This makes adding a device to their supported list a really hard thing to do, while costing a lot of time and money.
I think this will happen soon to laptops and desktops too. With the rise of ARM, I believe locking the bios and bootloader of those systems is not out of the question. Apple already kind of started with IBoot. It’s not fully locked, but definitely less open than what was used before in Intel macs.
And it’s not that ARM devices don't support UEFI, they absolutely do. Most Windows ARM systems use them right now. Arm’s SystemReady program allows them to boot just like x86 PCs do.
Then why the lockdown?
They will definitely say it’s for security, but Windows PCs, arm or not, have proven that you can have security while giving the user the choice to disable that security. UEFI and Secure Boot work just fine on ARM too, so it's not even a compatible issue. Secure defaults can be set as default, there is no problem with that. There is a really clear problem when those same defaults can’t be changed tho.
Now they'll probably argue that they didn't choose to do so, and that’s required by regulations.
I believe this is either misinformation, a stretch or a straight-up lie.
Radio and DRM firmware can stay on an isolated part of the device on their own. They don't need to prevent the entire OS boot process. The radio part already runs on an isolated part of the system on its own processor with signed firmware that complies with the FCC/RED requirements. The same thing goes for the DRM issue. User keys can allow for banking apps and all the other apps to verify the system without having to rely on OEM only control.
We need to act, not just complain
# What we should ask for:
We need to ask for owner-managed Secure Boot on every single type of general purpose computer. This goes for phones, smartwatches, computers… you get the point.
Either allow the user to disable secure boot or allow the user to manage their own keys, with proper documentation on how to do so.
We should also try to separate the concerns:
The radio and DRM stuff can be kept under signed, secure version on isolated systems to meet regulations.
This should NOT require a full system lockdown or OEM to have the full control over what you boot on YOUR device.
Provide documentation on how to interface with the hardware like GPS, Camera, GPUs and all to allow for third party OSes to develop properly without having to reverse engineer every single driver. This also means being able to develop proper alternatives to those NDA-only drivers.
We should have proper control over our device security:
Devices should be able to support TPM or DICE in a
We should act before the imminent destruction of the concepts of device ownership
I’m sadly starting to see a trend. Most phone bootloaders are locked nowadays. It’s not one specific manufacturer, it’s basically everyone.
If the OEM gives you the option to unlock them, it either voids the warranty or comes with severe punishment.
When you want to root your phone to get the liberty you lost to the “security features”, you basically break any apps that check for play integrity or other methods to detect root (even tho you can bypass that, it’s against TOS). I've mostly seen this on banking apps, but they are not the only ones. Not to mention that to even have the play integrity API, you have to have Google services installed and running. So you can't even de-Google your phone and keep the features.
This problem has been rampant on phones, it’s definitely not new, but it's basically the first thing that blocks the development of Linux for general phones.
Not to mention that no constructors follow a common thing like UEFI, they just all have their own thing. Which is a real pain for any kind of OS development.
Those aren’t the only issues tho, there's also all the proprietary blobs stuff. Without a way to either replicate them without reverse engineering, or open sourcing versions of the drivers, we will be stuck in this situation. Look at postmarketOS, they struggle a lot with this. This makes adding a device to their supported list a really hard thing to do, while costing a lot of time and money.
I think this will happen soon to laptops and desktops too. With the rise of ARM, I believe locking the bios and bootloader of those systems is not out of the question. Apple already kind of started with IBoot. It’s not fully locked, but definitely less open than what was used before in Intel macs.
And it’s not that ARM devices don't support UEFI, they absolutely do. Most Windows ARM systems use them right now. Arm’s SystemReady program allows them to boot just like x86 PCs do.
**Then why the lockdown?**
They will definitely say it’s for security, but Windows PCs, arm or not, have proven that you can have security while giving the user the choice to disable that security. UEFI and Secure Boot work just fine on ARM too, so it's not even a compatible issue. Secure defaults can be set as default, there is no problem with that. There is a really clear problem when those same defaults can’t be changed tho.
Now they'll probably argue that they didn't choose to do so, and that’s required by regulations.
I believe this is either misinformation, a stretch or a straight-up lie.
Radio and DRM firmware can stay on an isolated part of the device on their own. They don't need to prevent the entire OS boot process. The radio part already runs on an isolated part of the system on its own processor with signed firmware that complies with the FCC/RED requirements. The same thing goes for the DRM issue. User keys can allow for banking apps and all the other apps to verify the system without having to rely on OEM only control.
**We need to act, not just complain**
# What we should ask for:
* We need to ask for owner-managed Secure Boot on every single type of general purpose computer. This goes for phones, smartwatches, computers… you get the point.
* Either allow the user to disable secure boot or allow the user to manage their own keys, with proper documentation on how to do so.
We should also try to separate the concerns:
* The radio and DRM stuff can be kept under signed, secure version on isolated systems to meet regulations.
* This should NOT require a full system lockdown or OEM to have the full control over what you boot on YOUR device.
* Provide documentation on how to interface with the hardware like GPS, Camera, GPUs and all to allow for third party OSes to develop properly without having to reverse engineer every single driver. This also means being able to develop proper alternatives to those NDA-only drivers.
We should have proper control over our device security:
* Devices should be able to support TPM or DICE in a
I’m sadly starting to see a trend. Most phone bootloaders are locked nowadays. It’s not one specific manufacturer, it’s basically everyone.
If the OEM gives you the option to unlock them, it either voids the warranty or comes with severe punishment.
When you want to root your phone to get the liberty you lost to the “security features”, you basically break any apps that check for play integrity or other methods to detect root (even tho you can bypass that, it’s against TOS). I've mostly seen this on banking apps, but they are not the only ones. Not to mention that to even have the play integrity API, you have to have Google services installed and running. So you can't even de-Google your phone and keep the features.
This problem has been rampant on phones, it’s definitely not new, but it's basically the first thing that blocks the development of Linux for general phones.
Not to mention that no constructors follow a common thing like UEFI, they just all have their own thing. Which is a real pain for any kind of OS development.
Those aren’t the only issues tho, there's also all the proprietary blobs stuff. Without a way to either replicate them without reverse engineering, or open sourcing versions of the drivers, we will be stuck in this situation. Look at postmarketOS, they struggle a lot with this. This makes adding a device to their supported list a really hard thing to do, while costing a lot of time and money.
I think this will happen soon to laptops and desktops too. With the rise of ARM, I believe locking the bios and bootloader of those systems is not out of the question. Apple already kind of started with IBoot. It’s not fully locked, but definitely less open than what was used before in Intel macs.
And it’s not that ARM devices don't support UEFI, they absolutely do. Most Windows ARM systems use them right now. Arm’s SystemReady program allows them to boot just like x86 PCs do.
**Then why the lockdown?**
They will definitely say it’s for security, but Windows PCs, arm or not, have proven that you can have security while giving the user the choice to disable that security. UEFI and Secure Boot work just fine on ARM too, so it's not even a compatible issue. Secure defaults can be set as default, there is no problem with that. There is a really clear problem when those same defaults can’t be changed tho.
Now they'll probably argue that they didn't choose to do so, and that’s required by regulations.
I believe this is either misinformation, a stretch or a straight-up lie.
Radio and DRM firmware can stay on an isolated part of the device on their own. They don't need to prevent the entire OS boot process. The radio part already runs on an isolated part of the system on its own processor with signed firmware that complies with the FCC/RED requirements. The same thing goes for the DRM issue. User keys can allow for banking apps and all the other apps to verify the system without having to rely on OEM only control.
**We need to act, not just complain**
# What we should ask for:
* We need to ask for owner-managed Secure Boot on every single type of general purpose computer. This goes for phones, smartwatches, computers… you get the point.
* Either allow the user to disable secure boot or allow the user to manage their own keys, with proper documentation on how to do so.
We should also try to separate the concerns:
* The radio and DRM stuff can be kept under signed, secure version on isolated systems to meet regulations.
* This should NOT require a full system lockdown or OEM to have the full control over what you boot on YOUR device.
* Provide documentation on how to interface with the hardware like GPS, Camera, GPUs and all to allow for third party OSes to develop properly without having to reverse engineer every single driver. This also means being able to develop proper alternatives to those NDA-only drivers.
We should have proper control over our device security:
* Devices should be able to support TPM or DICE in a
way that allows baking apps, enterprise and DRM to work with third party OSes.
* They should also work with User provided keys.
We need to address the EOL and right to repair situation.
* When OEM updates end, we NEED to have a proper way to continue using the device with third party software, such as postmarketOS. This means allowing the user to unlock or provide keys to continue using the device.
* This would reduce e-waste by extending the device’s life.
We also want to know how our devices work. OEMs should have proper, publicly accessible documentation on the entire boot process and unlock procedure.
**Why should we act now ?**
With ARM growing in popularity, I'm kinda afraid the open boot system we had until now on desktop will disappear too. If OEM lockdown becomes the norm on PCs too, it will be really hard, almost impossible, to reverse those changes. It’s basically our last chance to act.
**How should we act ?**
Well, the EU has some places we can reach and some projects that kinda match what we want. We can associate ourselves with the right to repair movement, and try to prevent the entire ecosystem from being locked down.
So you should contact your MEPs. Explain that all of this is needed for fair competition, sustainability and right to repair.
Also try to reference existing proof of things like this already existing. Reference Windows PCs on ARM with UEFI support, x86 PCS allowing Secure Boot management and all. If you have additional arguments, please give them to other people so we can really argue to our MEPs.
You should state that it should be a right and that it’s not really weakening security, as user keys can do the same thing as OEM keys.
If you are in the states, I don’t know what you can do. So if someone has an idea, please post it.
Btw, English isn’t my native language, so there are going to be mistakes in this text, or repetition due to my lack of vocabulary. This is also my second time posting this. The first time I used AI translation which some people didn’t like. So I translated it all myself, even if some parts are not exactly how I want them to be, you'll probably get the idea. But be aware that my last two grades in English were 6.5/10 and 5.5/10.
Also, I’m not a professional, those are my opinions and I basically gathered as much info as I could to not spread misinformation. I removed some part on IBoot due to people saying I wasn’t quite right in the last post. So if you see anything wrong, please correct me and ill edit the post.
Should we name this “Right to own” ? Idk I just thought of that.
https://redd.it/1or04gp
@r_linux
* They should also work with User provided keys.
We need to address the EOL and right to repair situation.
* When OEM updates end, we NEED to have a proper way to continue using the device with third party software, such as postmarketOS. This means allowing the user to unlock or provide keys to continue using the device.
* This would reduce e-waste by extending the device’s life.
We also want to know how our devices work. OEMs should have proper, publicly accessible documentation on the entire boot process and unlock procedure.
**Why should we act now ?**
With ARM growing in popularity, I'm kinda afraid the open boot system we had until now on desktop will disappear too. If OEM lockdown becomes the norm on PCs too, it will be really hard, almost impossible, to reverse those changes. It’s basically our last chance to act.
**How should we act ?**
Well, the EU has some places we can reach and some projects that kinda match what we want. We can associate ourselves with the right to repair movement, and try to prevent the entire ecosystem from being locked down.
So you should contact your MEPs. Explain that all of this is needed for fair competition, sustainability and right to repair.
Also try to reference existing proof of things like this already existing. Reference Windows PCs on ARM with UEFI support, x86 PCS allowing Secure Boot management and all. If you have additional arguments, please give them to other people so we can really argue to our MEPs.
You should state that it should be a right and that it’s not really weakening security, as user keys can do the same thing as OEM keys.
If you are in the states, I don’t know what you can do. So if someone has an idea, please post it.
Btw, English isn’t my native language, so there are going to be mistakes in this text, or repetition due to my lack of vocabulary. This is also my second time posting this. The first time I used AI translation which some people didn’t like. So I translated it all myself, even if some parts are not exactly how I want them to be, you'll probably get the idea. But be aware that my last two grades in English were 6.5/10 and 5.5/10.
Also, I’m not a professional, those are my opinions and I basically gathered as much info as I could to not spread misinformation. I removed some part on IBoot due to people saying I wasn’t quite right in the last post. So if you see anything wrong, please correct me and ill edit the post.
Should we name this “Right to own” ? Idk I just thought of that.
https://redd.it/1or04gp
@r_linux
Reddit
From the linux community on Reddit
Explore this post and more from the linux community
Why don't more people use Linux?
Dumb question, I'm sure, but I converted a few days ago and trying it out on my laptop to see how it goes. And it feels no different from windows, except its free, it has a lot of free software, and a giant corpo isn't trying to fuck my asshole every ten minutes.
Why don't companies use this? It's so simple and easy to install. It works just fine. And it's literally completely under your own control. Like, why is this some weird, hidden thing most people don't know about it?
Having finally taken the plunge, I feel like I'm in topsy turvy world a but.
Sure, my main PC is still windows 10 because, sadly, so much goes through the windows ecosystem so I do need access to it. But, that wouldn't be a problem if people wisened up to this option.
https://redd.it/1or97hk
@r_linux
Dumb question, I'm sure, but I converted a few days ago and trying it out on my laptop to see how it goes. And it feels no different from windows, except its free, it has a lot of free software, and a giant corpo isn't trying to fuck my asshole every ten minutes.
Why don't companies use this? It's so simple and easy to install. It works just fine. And it's literally completely under your own control. Like, why is this some weird, hidden thing most people don't know about it?
Having finally taken the plunge, I feel like I'm in topsy turvy world a but.
Sure, my main PC is still windows 10 because, sadly, so much goes through the windows ecosystem so I do need access to it. But, that wouldn't be a problem if people wisened up to this option.
https://redd.it/1or97hk
@r_linux
Reddit
From the linux community on Reddit
Explore this post and more from the linux community
Resize Images to a Target Size via Right-Click | I updated the legacy nautilus-image-converter
https://redd.it/1orjit9
@r_linux
https://redd.it/1orjit9
@r_linux
I’m still using Windows on my gaming PC but I’m getting very close to just switching to Linux
https://redd.it/1orl2cl
@r_linux
https://redd.it/1orl2cl
@r_linux
$830 Bug Bounty to Whoever Fixes the Lenovo Legion Pro 7 16IAX10H's Speakers on Linux
https://github.com/nadimkobeissi/16iax10h-linux-sound-saga
https://redd.it/1orn1f1
@r_linux
https://github.com/nadimkobeissi/16iax10h-linux-sound-saga
https://redd.it/1orn1f1
@r_linux
GitHub
GitHub - nadimkobeissi/16iax10h-linux-sound-saga: Actual, complete solution for Linux audio on the Lenovo Legion Pro 7i Gen 10…
Actual, complete solution for Linux audio on the Lenovo Legion Pro 7i Gen 10 (16IAX10H) - nadimkobeissi/16iax10h-linux-sound-saga
This Week in Plasma: Virtual desktops only on the primary screen
https://blogs.kde.org/2025/11/08/this-week-in-plasma-virtual-desktops-only-on-the-primary-screen/
https://redd.it/1orm8el
@r_linux
https://blogs.kde.org/2025/11/08/this-week-in-plasma-virtual-desktops-only-on-the-primary-screen/
https://redd.it/1orm8el
@r_linux
KDE Blogs
This Week in Plasma: Virtual desktops only on the primary screen
Welcome to a new issue of This Week in Plasma!
This week something that I know a lot of people have been wanting for a long time was implemented: the ability to limit virtual desktops to only the primary screen! Thanks very much to Kristen McWilliam for this…
This week something that I know a lot of people have been wanting for a long time was implemented: the ability to limit virtual desktops to only the primary screen! Thanks very much to Kristen McWilliam for this…
Reverse engineering UPS battery status USB HID protocol with Linux
https://popovicu.com/posts/how-to-reverse-engineer-usb-hid-on-linux/
https://redd.it/1orui67
@r_linux
https://popovicu.com/posts/how-to-reverse-engineer-usb-hid-on-linux/
https://redd.it/1orui67
@r_linux
Popovicu
How to reverse engineer USB HID on Linux
Discover how Linux exposes raw USB device data, even without a driver. This article details how to use /dev/hidraw and the HID report denoscriptor to reverse-engineer and read real-time data from a UPS.
Modern Linux Runs On Old Pentium 133Mhz (tiny core linux)
https://www.youtube.com/watch?v=-DiK5FDpBTg
https://redd.it/1orv1u7
@r_linux
https://www.youtube.com/watch?v=-DiK5FDpBTg
https://redd.it/1orv1u7
@r_linux
YouTube
Can a Pentium 1 Run MODERN Desktop Linux?
To learn for free on Brilliant, go to https://brilliant.org/ActionRetro/ . You’ll also get 20% off an annual premium subnoscription.
Tiny Core Linux is basically magic.
🍎 Tiny Core Linux: http://www.tinycorelinux.net/
👉 Edited by the incomparable @Diceroll…
Tiny Core Linux is basically magic.
🍎 Tiny Core Linux: http://www.tinycorelinux.net/
👉 Edited by the incomparable @Diceroll…
'Amelia' Installer for Arch Linux
Amelia is a fun Arch Linux installer with a TUI.
It covers the basics and a bit more, all in a single shell noscript.
Screenshot: here
It supports Ext4/Btrfs, Sd-boot/Grub, Swap Partition/Swapfile/Zram Swap, LUKS encryption, Secure Boot signing, Menu Auto-Navigation, Auto-Partitioning and other features.
Qemu/Kvm,Virtualbox,HyperV,VMware are also supported.
The noscript is meant to be executed from within a booted Archlinux installation media.
Cheers!
https://redd.it/1os2r6t
@r_linux
Amelia is a fun Arch Linux installer with a TUI.
It covers the basics and a bit more, all in a single shell noscript.
Screenshot: here
It supports Ext4/Btrfs, Sd-boot/Grub, Swap Partition/Swapfile/Zram Swap, LUKS encryption, Secure Boot signing, Menu Auto-Navigation, Auto-Partitioning and other features.
Qemu/Kvm,Virtualbox,HyperV,VMware are also supported.
The noscript is meant to be executed from within a booted Archlinux installation media.
Cheers!
https://redd.it/1os2r6t
@r_linux
GitLab
Prism7 / archery · GitLab
I built sbsh: a tool to make terminal environments reproducible and persistent
I wanted to share a small open-source tool I have been building and using every day called **sbsh**. It lets you define your terminal environments declaratively, something I have started calling **Terminal as Code**, so they are reproducible and persistent.
🔗 Repo: [github.com/eminwux/sbsh](https://github.com/eminwux/sbsh)
🎥 **Demo: u**sing a [bash-demo profile](https://github.com/eminwux/sbsh/blob/main/docs/profiles/bash-demo.yaml)
https://i.redd.it/2ajxmkfzx30g1.gif
Instead of starting a shell and manually setting up variables or aliases, you can describe your setup once and start it with a single command.
Each profile defines:
* Environment variables
* Working directory
* Lifecycle hooks
* Custom prompts
* Which shell or command to run
Run `sbsh -p bash-demo` to launch a fully configured session.
Sessions can be detached, reattached, listed, and logged, similar to `tmux`, but focused on reproducibility and environment setup.
You can also define profiles that run **Docker** or **Kubernetes** commands directly.
📁 Example profiles: [docs/profiles](https://github.com/eminwux/sbsh/tree/main/docs/profiles)
**I would love feedback from anyone who enjoys customizing their terminal or automating CLI workflows. Would this be useful in your daily setup?**
https://redd.it/1os28yw
@r_linux
I wanted to share a small open-source tool I have been building and using every day called **sbsh**. It lets you define your terminal environments declaratively, something I have started calling **Terminal as Code**, so they are reproducible and persistent.
🔗 Repo: [github.com/eminwux/sbsh](https://github.com/eminwux/sbsh)
🎥 **Demo: u**sing a [bash-demo profile](https://github.com/eminwux/sbsh/blob/main/docs/profiles/bash-demo.yaml)
https://i.redd.it/2ajxmkfzx30g1.gif
Instead of starting a shell and manually setting up variables or aliases, you can describe your setup once and start it with a single command.
Each profile defines:
* Environment variables
* Working directory
* Lifecycle hooks
* Custom prompts
* Which shell or command to run
Run `sbsh -p bash-demo` to launch a fully configured session.
Sessions can be detached, reattached, listed, and logged, similar to `tmux`, but focused on reproducibility and environment setup.
You can also define profiles that run **Docker** or **Kubernetes** commands directly.
📁 Example profiles: [docs/profiles](https://github.com/eminwux/sbsh/tree/main/docs/profiles)
**I would love feedback from anyone who enjoys customizing their terminal or automating CLI workflows. Would this be useful in your daily setup?**
https://redd.it/1os28yw
@r_linux
GitHub
GitHub - eminwux/sbsh: sbsh - tty supervisor
sbsh - tty supervisor. Contribute to eminwux/sbsh development by creating an account on GitHub.
AndroSH - Professional Multi-Distribution Linux Environments for Android
https://redd.it/1os7nep
@r_linux
https://redd.it/1os7nep
@r_linux
automatically unlock and mount external luks-encrypted partition using security token without requesting passphrase
I have a luks-encrypted partition on a usb flash drive. LUKS key slot 0 contains a passphrase/word. Key slot 1 references a security token (yubikey). When I plug in the flash drive, I want it to automatically unlock, map, and mount the partition using the security token without requesting the passphrase/word. But it always requests the passphrase/word.
This is my setup: A usb flash drive contains 4 partitions. It is not present at boot. The 4th partition is encrypted with LUKS. It contains a btrfs fs. (This is a learning experience. The drive does not contain important data.)
Key slot 0 contains a password. Priority is marked as normal. (Ultimately I intend to remove the password in slot 0, so the security token will be the only way to unlock.)
Key slot 1 references a FIDO2 token (yubikey). Priority is marked as preferred. It does not require a pin.
Key slot 2 will reference a backup token. Not yet installed.
/etc/crypttab contains:
CRYPTTAB(5) says: The /etc/crypttab file describes encrypted block devices that are set up during system boot. However, I know that it is also used when plugging in an external drive.
There is no entry in fstab. Distribution is fedora.
This is what I want to happen when I plug in the flash memory (token is already plugged in):
Using the token in slot 1, request a touch on the key, then automatically unlock the partition, map it with the name from crypttab, then mount it at /run/media/<me>/whatever. (Later I will insert a line in fstab to specify a mountpoint.)
This is what actually happens: It requests a passphrase/word.
If I enter the password specified in slot 1, then it unlocks the partition, maps it with the name from crypttab, then mounts it at /run/media/<me>/whatever. (The mapping and mounting are what I want, but I don't want it to request a password.)
If I cancel the password request, the open fails. I can then open it with cryptsetup open and mount it with mount. (Or mount -a after I insert an entry in fstab.)
Some things I have tried or thought about:
(-1) I need to intercept the "hot plug" and get it to issue a cryptsetup open and mount before it requests the password.
(0) I tried removing the password from slot 0. It still requests a passphrase/word (I must cancel the request), so it seems the "hot plug" software does not look at the LUKS data at this point.
(1) I tried an fstab entry, but no success. I tried an entry for /dev/sda4 (using its UUID), and specifying the type as crypto_LUKS, but a message said it was an unknown type, even though mount identified the partition as crypto_LUKS.
(2) Maybe a udev noscript could mount it. But I think it should be achievable without going down that path, just by getting the right options in the luks slots, crypttab, and maybe fstab.
(3) Maybe a systemd definition?
(4) Can dmsetup achieve anything?
(5) Can systemd-cryptsetup achieve anything? It can attach the device, but I think cryptsetup open does that. How to invoke the attach automatically?
This is a long post. Sorry you have so much to absorb. I'm not sure how much is relevant. Thank you for investing the time to read it.
I have a luks-encrypted partition on a usb flash drive. LUKS key slot 0 contains a passphrase/word. Key slot 1 references a security token (yubikey). When I plug in the flash drive, I want it to automatically unlock, map, and mount the partition using the security token without requesting the passphrase/word. But it always requests the passphrase/word.
This is my setup: A usb flash drive contains 4 partitions. It is not present at boot. The 4th partition is encrypted with LUKS. It contains a btrfs fs. (This is a learning experience. The drive does not contain important data.)
Key slot 0 contains a password. Priority is marked as normal. (Ultimately I intend to remove the password in slot 0, so the security token will be the only way to unlock.)
Key slot 1 references a FIDO2 token (yubikey). Priority is marked as preferred. It does not require a pin.
Key slot 2 will reference a backup token. Not yet installed.
/etc/crypttab contains:
verbatim-p4-luks-09 UUID=xxxxxxxx-...xxx - fido2-device=auto,key-slot=1CRYPTTAB(5) says: The /etc/crypttab file describes encrypted block devices that are set up during system boot. However, I know that it is also used when plugging in an external drive.
There is no entry in fstab. Distribution is fedora.
This is what I want to happen when I plug in the flash memory (token is already plugged in):
Using the token in slot 1, request a touch on the key, then automatically unlock the partition, map it with the name from crypttab, then mount it at /run/media/<me>/whatever. (Later I will insert a line in fstab to specify a mountpoint.)
This is what actually happens: It requests a passphrase/word.
If I enter the password specified in slot 1, then it unlocks the partition, maps it with the name from crypttab, then mounts it at /run/media/<me>/whatever. (The mapping and mounting are what I want, but I don't want it to request a password.)
sudo dmsetup lsNo devices foundPLUG IN DEVICE AND ENTER PASSWORDsudo dmsetup lsverbatim-p4-luks-09 (252:0)mount | grep verbatim/dev/mapper/verbatim-p4-luks-09 on /run/media/<me>/xxxxxxxx...xx type btrfs (rw,other options)If I cancel the password request, the open fails. I can then open it with cryptsetup open and mount it with mount. (Or mount -a after I insert an entry in fstab.)
sudo dmsetup lsNo devices foundPLUG IN DEVICE, CANCEL PW REQUEST. OPEN FAILSsudo cryptsetup open --type luks /dev/sda4 verbatim-p4-luks-09Asking FIDO2 token for authentication.👆 Please confirm presence on security token to unlock.TOUCH KEYsudo dmsetup lsverbatim-p4-luks-09 (252:0)sudo mount /dev/mapper/verbatim-p4-luks-09 /mntmount | grep verbatim/dev/mapper/verbatim-p4-luks-09 on /mnt type btrfs (rw,other options)Some things I have tried or thought about:
(-1) I need to intercept the "hot plug" and get it to issue a cryptsetup open and mount before it requests the password.
(0) I tried removing the password from slot 0. It still requests a passphrase/word (I must cancel the request), so it seems the "hot plug" software does not look at the LUKS data at this point.
(1) I tried an fstab entry, but no success. I tried an entry for /dev/sda4 (using its UUID), and specifying the type as crypto_LUKS, but a message said it was an unknown type, even though mount identified the partition as crypto_LUKS.
(2) Maybe a udev noscript could mount it. But I think it should be achievable without going down that path, just by getting the right options in the luks slots, crypttab, and maybe fstab.
(3) Maybe a systemd definition?
(4) Can dmsetup achieve anything?
(5) Can systemd-cryptsetup achieve anything? It can attach the device, but I think cryptsetup open does that. How to invoke the attach automatically?
This is a long post. Sorry you have so much to absorb. I'm not sure how much is relevant. Thank you for investing the time to read it.
Consolidated archive or torrent of many of the useful, stable, and popular versions of Debian or similar highly versatile distros?
Kind of a strange use case, but a friend and I are creating bug-out data cache hard drives for possible apocalyptic scenarios, and we're wondering if there's a way we can download or torrenr them all at once instead of needing to pick and choose them all.
I should clarify, we intend to use these on scavenged computers, including everything from consumer tech to embedded systems and computerized appliances like cash registers and order systems. So older 32 bit versions from the 90s and early 2000s are just as important.
We also intend on archiving Windows XP and 7 for our data caches.
https://redd.it/1osb1jv
@r_linux
Kind of a strange use case, but a friend and I are creating bug-out data cache hard drives for possible apocalyptic scenarios, and we're wondering if there's a way we can download or torrenr them all at once instead of needing to pick and choose them all.
I should clarify, we intend to use these on scavenged computers, including everything from consumer tech to embedded systems and computerized appliances like cash registers and order systems. So older 32 bit versions from the 90s and early 2000s are just as important.
We also intend on archiving Windows XP and 7 for our data caches.
https://redd.it/1osb1jv
@r_linux
Reddit
From the linux community on Reddit
Explore this post and more from the linux community