#fulldiskencryption — Public Fediverse posts

YellowKey: BitLocker Bypass or Backdoor

YellowKey, tracked as CVE-2026-45585, is a public BitLocker bypass that abuses WinRE/recovery-path behavior to expose a protected volume without the Windows password, recovery key, or AES cracking.

At the time of this post, the author’s GitHub and original YellowKey repo appear to be down.

Read more: https://forum.hashpwn.net/post/13339

#BitLocker #YellowKey #CVE202645585 #CyberSecurity #InfoSec #WindowsSecurity #TPM #FullDiskEncryption #hack #exploit #news #hashpwn

YellowKey: BitLocker Bypass or Backdoor

YellowKey, tracked as CVE-2026-45585, is a public BitLocker bypass that abuses WinRE/recovery-path behavior to expose a protected volume without the Windows password, recovery key, or AES cracking.

At the time of this post, the author’s GitHub and original YellowKey repo appear to be down.

Read more: https://forum.hashpwn.net/post/13339

#BitLocker #YellowKey #CVE202645585 #CyberSecurity #InfoSec #WindowsSecurity #TPM #FullDiskEncryption #hack #exploit #news #hashpwn

YellowKey: BitLocker Bypass or Backdoor

YellowKey, tracked as CVE-2026-45585, is a public BitLocker bypass that abuses WinRE/recovery-path behavior to expose a protected volume without the Windows password, recovery key, or AES cracking.

At the time of this post, the author’s GitHub and original YellowKey repo appear to be down.

Read more: https://forum.hashpwn.net/post/13339

#BitLocker #YellowKey #CVE202645585 #CyberSecurity #InfoSec #WindowsSecurity #TPM #FullDiskEncryption #hack #exploit #news #hashpwn

YellowKey: BitLocker Bypass or Backdoor

YellowKey, tracked as CVE-2026-45585, is a public BitLocker bypass that abuses WinRE/recovery-path behavior to expose a protected volume without the Windows password, recovery key, or AES cracking.

At the time of this post, the author’s GitHub and original YellowKey repo appear to be down.

Read more: https://forum.hashpwn.net/post/13339

#BitLocker #YellowKey #CVE202645585 #CyberSecurity #InfoSec #WindowsSecurity #TPM #FullDiskEncryption #hack #exploit #news #hashpwn

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

@kkarhan I was just pointed at this:

https://search.nixos.org/packages?channel=unstable&query=Shufflecake

https://dl.acm.org/doi/10.1145/3576915.3623126

#FDE #FullDiskEncryption #Deniability #PlausibleDeniability #Shufflecake

@kkarhan I was just pointed at this:

https://search.nixos.org/packages?channel=unstable&query=Shufflecake

https://dl.acm.org/doi/10.1145/3576915.3623126

#FDE #FullDiskEncryption #Deniability #PlausibleDeniability #Shufflecake

@kkarhan I was just pointed at this:

https://search.nixos.org/packages?channel=unstable&query=Shufflecake

https://dl.acm.org/doi/10.1145/3576915.3623126

#FDE #FullDiskEncryption #Deniability #PlausibleDeniability #Shufflecake

@kkarhan I was just pointed at this:

https://search.nixos.org/packages?channel=unstable&query=Shufflecake

https://dl.acm.org/doi/10.1145/3576915.3623126

#FDE #FullDiskEncryption #Deniability #PlausibleDeniability #Shufflecake

I got a "hankerin'" (as we say here) to try daily-driving #FreeBSD again, but I kind of want to wait until the desktop installer is ready.

@evgandr, how fast did you say you got FreeBSD to resume from S3, again?

I wouldn't mind trying #NetBSD again, but the instructions for #FDE (#FullDiskEncryption) looked quite daunting.

#POLL: Do you use Full-Disk Encryption, such as LUKS on #Linux or GELI on #FreeBSD?

#FullDiskEncryption #FDE #LUKS #GELI

How to install @linuxmint with #btrfs, #raid and #luks #fulldiskencryption. Spent over a week trying to figure this out...

https://gist.github.com/Leniwcowaty/4b2c239ca74629cad60d4718f79ff600

#linux #tips #tutorial #informative #content #technology #mint #debian #installation #distrohopping #security

Ubuntu 25.10 To Feature Experimental TPM-Backed Full Disk Encryption (FDE) #ubuntu25_10 #TPM #FDE #QuestingQuokka #Security #FullDiskEncryption #TrustedPlatformModule #Linux #Opensource
https://ostechnix.com/ubuntu-25-10-tpm-backed-full-disk-encryption-fde/

Ubuntu 25.10 To Feature Experimental TPM-Backed Full Disk Encryption (FDE) #ubuntu25_10 #TPM #FDE #QuestingQuokka #Security #FullDiskEncryption #TrustedPlatformModule #Linux #Opensource
https://ostechnix.com/ubuntu-25-10-tpm-backed-full-disk-encryption-fde/

Ubuntu 25.10 To Feature Experimental TPM-Backed Full Disk Encryption (FDE) #ubuntu25_10 #TPM #FDE #QuestingQuokka #Security #FullDiskEncryption #TrustedPlatformModule #Linux #Opensource
https://ostechnix.com/ubuntu-25-10-tpm-backed-full-disk-encryption-fde/

Ubuntu 25.10 To Feature Experimental TPM-Backed Full Disk Encryption (FDE) #ubuntu25_10 #TPM #FDE #QuestingQuokka #Security #FullDiskEncryption #TrustedPlatformModule #Linux #Opensource
https://ostechnix.com/ubuntu-25-10-tpm-backed-full-disk-encryption-fde/

Ubuntu 25.10 To Feature Experimental TPM-Backed Full Disk Encryption (FDE) #ubuntu25_10 #TPM #FDE #QuestingQuokka #Security #FullDiskEncryption #TrustedPlatformModule #Linux #Opensource
https://ostechnix.com/ubuntu-25-10-tpm-backed-full-disk-encryption-fde/

#FullDiskEncryption
#Gentoo
#Paranoia
#Linux
#SystemSecurity

Letting my paranoia take hold. Got the laptops root part encrypted. Thinking about taking this as far as possible with a key USB for the actual kernel and such. Have the computer totally encrypted.

Will probably start doing this by default for all my systems from now on. If I am going to take them with me in my vanlife adventures I want them secure.

Granted, if stolen a person could just reinstall a new OS. But at least I'd be sticking them with a bit of work so.

CyMaIS: 100 % DSGVO-konform

Die Datenschutz-Grundverordnung (DSGVO) schreibt strenge Vorgaben vor, wenn es um den Umgang mit personenbezogenen Daten geht. Wer seine Unternehmensdaten und die persönlichen Informationen von Mitarbeitenden oder Kund:innen schützen möchte, braucht mehr als nur eine Standard-Cloud. CyMaIS erfüllt nicht nur sämtliche DSGVO-Anforderungen, sondern geht mit ausgefeilten Sicherheitskonzepten und flexibler Infrastruktur noch einen Schritt weiter.

[…]

https://blog.cymais.cloud/blog/2025/06/19/cymais-100-dsgvo-konform/

CyMaIS: 100 % DSGVO-konform

Die Datenschutz-Grundverordnung (DSGVO) schreibt strenge Vorgaben vor, wenn es um den Umgang mit personenbezogenen Daten geht. Wer seine Unternehmensdaten und die persönlichen Informationen von Mitarbeitenden oder Kund:innen schützen möchte, braucht mehr als nur eine Standard-Cloud. CyMaIS erfüllt nicht nur sämtliche DSGVO-Anforderungen, sondern geht mit ausgefeilten Sicherheitskonzepten und flexibler Infrastruktur noch einen Schritt weiter.

[…]

https://blog.cymais.cloud/blog/2025/06/19/cymais-100-dsgvo-konform/

CyMaIS: 100 % DSGVO-konform

Die Datenschutz-Grundverordnung (DSGVO) schreibt strenge Vorgaben vor, wenn es um den Umgang mit personenbezogenen Daten geht. Wer seine Unternehmensdaten und die persönlichen Informationen von Mitarbeitenden oder Kund:innen schützen möchte, braucht mehr als nur eine Standard-Cloud. CyMaIS erfüllt nicht nur sämtliche DSGVO-Anforderungen, sondern geht mit ausgefeilten Sicherheitskonzepten und flexibler Infrastruktur noch einen Schritt weiter.

[…]

https://blog.cymais.cloud/blog/2025/06/19/cymais-100-dsgvo-konform/

Installing #VoidLinux is one thing, but documenting it is key. I'm working on #dracut hooks to automatically create and sign the #unifiedkernelimage. I've already done #FullDiskEncryption (including /boot)

The best thing is that i can lookup most of the stuff on the #ArchLinux #wiki (except #systemd stuff). I like #runit, though i'm not used to it yet.

I can also fix or reinstall the OS how much i want because of my separate /home partition. This level of customization and control is so cool.

I'm already excited to #automate the base system installation using #Ansible.

#linux #unix #void #customization #secureboot #automation

Installing #VoidLinux is one thing, but documenting it is key. I'm working on #dracut hooks to automatically create and sign the #unifiedkernelimage. I've already done #FullDiskEncryption (including /boot)

The best thing is that i can lookup most of the stuff on the #ArchLinux #wiki (except #systemd stuff). I like #runit, though i'm not used to it yet.

I can also fix or reinstall the OS how much i want because of my separate /home partition. This level of customization and control is so cool.

I'm already excited to #automate the base system installation using #Ansible.

#linux #unix #void #customization #secureboot #automation

Installing #VoidLinux is one thing, but documenting it is key. I'm working on #dracut hooks to automatically create and sign the #unifiedkernelimage. I've already done #FullDiskEncryption (including /boot)

The best thing is that i can lookup most of the stuff on the #ArchLinux #wiki (except #systemd stuff). I like #runit, though i'm not used to it yet.

I can also fix or reinstall the OS how much i want because of my separate /home partition. This level of customization and control is so cool.

I'm already excited to #automate the base system installation using #Ansible.

#linux #unix #void #customization #secureboot #automation

Installing #VoidLinux is one thing, but documenting it is key. I'm working on #dracut hooks to automatically create and sign the #unifiedkernelimage. I've already done #FullDiskEncryption (including /boot)

The best thing is that i can lookup most of the stuff on the #ArchLinux #wiki (except #systemd stuff). I like #runit, though i'm not used to it yet.

I can also fix or reinstall the OS how much i want because of my separate /home partition. This level of customization and control is so cool.

I'm already excited to #automate the base system installation using #Ansible.

#linux #unix #void #customization #secureboot #automation

Installing #VoidLinux is one thing, but documenting it is key. I'm working on #dracut hooks to automatically create and sign the #unifiedkernelimage. I've already done #FullDiskEncryption (including /boot)

The best thing is that i can lookup most of the stuff on the #ArchLinux #wiki (except #systemd stuff). I like #runit, though i'm not used to it yet.

I can also fix or reinstall the OS how much i want because of my separate /home partition. This level of customization and control is so cool.

I'm already excited to #automate the base system installation using #Ansible.

#linux #unix #void #customization #secureboot #automation

Thinking of trying #postmarketOS on my #PinebookPro.

I didn't even know you could run it as a desktop OS.

Supposedly the installer supports #FullDiskEncryption, which is... "poggers," I think the kids say.

#pmOS #FDE

@Codeschubse @linuxmint

A user named linux22 on the mint forums did a writeup on how to do #FullDiskEncryption on #LinuxMint 22, perhaps you can find some helpful pointers there. Good luck!

https://forums.linuxmint.com/viewtopic.php?t=198077

Dilemme #FullDiskEncryption sous #Linux :

mon installation Debian pour le vieux portable à processeur i3 et 4Go de RAM, je regrette de l'avoir faite avec chiffrement du disque parce que l'engin galère pas mal niveau performance, et c'est pour faire un serveur, donc c'est pas pertinent.

Je crois qu'on va recommencer ce soir.

'"the Trusted Platform Module (TPM) […] allows an unattended auto-unlock, providing a pass is no longer required. That completely fits to secure disks that have been put in a machine in a safe location. With FDE [Full Disk Encryption] and TPM, your data becomes protected and cannot be read outside of your machine."'

https://www.suse.com/c/full-disk-encryption-grub2-tpm/ #grub #tpm #FullDiskEncryption

#Cellebrite is just a hardware encryption key brute forcing device for hardware running #Android? Curious if it also has the same effect on #postmarketOS with #FullDiskEncryption. https://www.youtube.com/watch?v=I6mlaPLPcXU

OpenSUSE Aeon Desktop Enhances Security with Full Disk Encryption #Aeondesktop #Opensuse #FDE #FullDiskEncryption #Linux #Security
https://ostechnix.com/full-disk-encryption-in-aeon-desktop/

@stu

#NomadBSD is nice! Solid xfce desktop, persistent USB session (or desktop installer), and even GELI* #FullDiskEncryption, even on persistent USB.

*It stands for "Geom ELI."
As far as i can tell, only one person on the earth knows what ELI stands for. Yes, the author. Yes, I have emailed him., No, he's not telling. No, it doesn't stand for Encryption Layer Interface. Yes, I asked. 😆

#FreeBSD #GELI

Kudos to @opensuse and their work on systemd-boot integration!! Just switched from Grub2 with #secureboot , #snapper #btrfs snapshots and #fulldiskencryption configured following docs (https://en.opensuse.org/Systemd-boot) and it is working great.

Any #nixos user who could answer me this question?

If i setup nixos on my laptop, with luks #fulldiskencryption and copy the config file to my workstation, is that gonna work? I'm asking because luks has a unique id and stuff like that. Thanks in advance.

Also, #pikvm is something i really need. That way, i could use #fulldiskencryption on my server and still be able to reboot it or change #bios settings even when i'm not at home.

Got my #archlinux installation ready with #secureboot, #btrfs and #fulldiskencryption. Next step will be some #hardening with #lynis.

TPM-backed #FullDiskEncryption is coming to #Ubuntu

Based on Ubuntu Core’s FDE design, we have been working on bringing TPM-backed full disk encryption to classic Ubuntu Desktop systems as well, starting with Ubuntu 23.10 ( #ManticMinotaur ) – where it will be available as an experimental feature. This means that passphrases will no longer be needed on supported platforms, and that the secret used to decrypt the encrypted data will be protected by a #TPM and recovered automatically only by early boot software that is authorised to access the data.

WTF?

#France goes full #Cyberfacist:
#DGSI literally classified using #FullDiskEncryption, @torproject #TorBorwser, #Tails, @protonmail and #VPN's as "suspicious activity" in terms of #terrorism...
https://www.youtube.com/watch?v=cyFL7KJGcC0

SERIOUSLY, DID THESE #MILINTEL IDIOTS DRANK SOME WINE WITH ETHYLENE GLYCOL OR WHAT!?

WTF?

#France goes full #Cyberfacist:
#DGSI literally classified using #FullDiskEncryption, @torproject #TorBorwser, #Tails, @protonmail and #VPN's as "suspicious activity" in terms of #terrorism...
https://www.youtube.com/watch?v=cyFL7KJGcC0

SERIOUSLY, DID THESE #MILINTEL IDIOTS DRANK SOME WINE WITH ETHYLENE GLYCOL OR WHAT!?

WTF?

#France goes full #Cyberfacist:
#DGSI literally classified using #FullDiskEncryption, @torproject #TorBorwser, #Tails, @protonmail and #VPN's as "suspicious activity" in terms of #terrorism...
https://www.youtube.com/watch?v=cyFL7KJGcC0

SERIOUSLY, DID THESE #MILINTEL IDIOTS DRANK SOME WINE WITH ETHYLENE GLYCOL OR WHAT!?

I'm thinking of moving back from #NixOS to #Arch or #Debian.

I'm finding #NixOS just too complicated to deal with specially when it comes to #drivers.

Also, #NixOS doesn't support #systemd on #initramfs which makes #FullDiskEncryption harder as it doesn't allow me to use systemd-enroll.

I am a big fan of Willi Mutschler‘s btrfs-luks full disk encryption installation guides on his site, https://mutschler.dev, and have used them for installing Manjaro and Ubuntu 20.04 and newer versions. Recently, I set up Kubuntu 22.04 full disk encryption by following the same guide and noticed a couple of changes that had to be done to get it working. So I am documenting those here till he writes a new guide for Ubuntu 22.04. 🙂

In the step 3 of his excellent guide, the optimized mount options for SSD and NVMe drives are listed. The space_cache option mentioned in that section no longer works on Ubuntu 22.04 because the option has been renamed in the newer versions of the Linux kernel. So one has to specify the option as space_cache=v2. Otherwise, the Ubiquity installer will crash, and the installation will fail.

Also, in the Install the EFI bootloader section, it is a good idea to use the HWE Linux kernel package names corresponding to 22.04 instead of 20.04 since the packages containing the old LTS version in their name are ‘dummy transitional packages’. So the corresponding command can to be updated to

apt install -y --reinstall grub-efi-amd64-signed linux-generic linux-headers-generic linux-generic-hwe-22.04 linux-headers-generic-hwe-22.04

At the time of writing this post, the HWE package installs the same kernel version as the one that shipped with Ubuntu 22.04 since there isn’t a newer kernel released yet – these are usually backported from newer LTS versions.

With these minor changes, it should be possible to follow the steps in that documentation to set up full disk encryption with btrfs and luks on Ubuntu 22.04.

As a bonus, I have used the same guide for installing Kubuntu 20.04, 21.10 and 22.04, with appropriate substitutions, wherever needed.

I have usually skipped the last section in this guide, Install Timeshift, timeshift-autosnap-apt and grub-btrfs, in favour of using my tools of choice to do the same – Snapper and snapper-gui, both of which are available in the official Ubuntu repositories. I will write a blog post about it in the future. 🤞

#22-04 #btrfs #full-disk-encryption #kubuntu #luks #ubuntu

https://www.lguruprasad.in/blog/2023/01/18/ubuntu-22-04-desktop-installation-guide-btrfs-luks-full-disk-encryption-including-boot/

@Unperson Thank you. Full-disk encryption is mandatory for me.

#fde #fulldiskencryption