But transporter-cloning Tuvix and and splitting one gets THREE allies. 🤭

If it doesn’t simulate a connected monitor, it looks like there are little HDMI shims that do called EDID emulators that are available for relatively cheap.

Obviously, you hang in the castle for a bit so you can go over to the ion storm later with a full understanding of context.

I probably shouldn’t have thrown in the word “now”; what I meant to say is FOSS formats are so good that the existence of RAR is ridiculous.

(Note: Anything I say could be B.S. I could be completely misunderstanding this.)

Clevis isn’t too difficult to set up - Arch Wiki documents the process really well. I’ve found it works better with dracut that mkinitcpio.

As for PCR registers (which I haven’t set up yet but should), what I can tell, it sets the hash of the boot partition and UEFI settings in the TPM PCR register so it can check for tampering on the unencrypted boot partition and refuse to give the decryption keys if it does. That way, someone can’t doctor your boot partition and say, put the keys on a flash drive - I think they’d have to totally lobotomize your machine’s hardware to do it, which only someone who has both stolen your device and has the means/budget to do that would do.

You do need to make sure these registers are updated every kernel update, or else you’ll have to manually enter the LUKS password the next boot and update it then. I’m wondering if there’s a hook I can set up where every time the boot partition is updated, it updates PCR registers.

I got a response to my e-mail; they say it’ll be fixed by Monday.

JavaScript be like that sometimes…

That is so me sometimes.

You’re somewhat right in the sense that the point of disk encryption is not to protect from remote attackers. However, physical access is a bigger problem in some cases (mostly laptops). I don’t do it on my desktop because I neither want to reinstall nor do I think someone who randomly breaks in is going to put in the effort to lug it away to their vehicle.

Clevis pretty much does TPM encryption and is in most distros’ repos. I use it on my Thinkpad. It would be nice if it had a GUI to set it up; more distros should have this as a default option.

You do have to have an unencrypted boot partition, but the issues with this can at least in be mitigated with PCR registers, which I need to set up.

It’s a smidge more difficult on Debian if you want to use a non-ext4 filesystem - granted for most people, ext4’s probably still fine. I use it on my desktop, which doesn’t have encryption.

No - so long as the Federation has transporters and warp drive (realspace FTL in Star Wars lingo), they can probably pull it off.

If they could beef up their runabouts, that might help too.

Yes, fellow OpenTTD player.

I know this topic has been beaten to death online and honestly discussion is pointless, but I’m convinced the Federation could beat the Empire solely based on these two things:

• Warp drive travels FTL through what Star Wars would call “realspace”; not only does this provide Federation starships extreme tactical maneuverability (Picard maneuver and the like), but if a starship warped away far enough, the Empire might struggle to pursue with hyperdrive.
• The Federation has transporters - I’m not sure imperial shield would be design to protect against e.g someone beaming a bomb (or in dire cases, the warp core) onto a Star Destroyer or whatever.

I’d say the major difficulties are 1) Starfleet has nothing like a tie fighter except runabouts, which aren’t (yet) designed for combat. 2) The Federation might try to negotiate while the Empire does some sort of secret operation.

I’m using LVM. The BIOS solution would be a bad idea because it would be more difficult to access the drive on other systems if you had to; LVM allows you to enter your password on other systems to decrypt.

Do your servers have TPM? Clevis might be the way to go; I use it on my Thinkpad and it makes my life easy. If the servers don’t have TPM, Clevis also supports this weird thing called Tang, which from what I can tell basically assures that the servers can only be automatically decrypted on your local network. If Clevis fails, you can have it fall back to letting you enter the LVM password.

Sent! Although I just realized it’s not like only one person has to send an e-mail; multiple would make it clearer that these images are important to some people.

Well, it was worth a shot.

I don’t do it for my desktop because 1) I highly doubt my desktop would get stolen. 2) I installed Linux before I was aware of encryption, and don’t have any desire to do a reinstall on my desktop at this time.

For my laptop, yes, I do (with exception of the boot partition), since it would be trivial to steal and this is a more recent install. I use clevis to auto-unlock the drive by getting keys from the TPM. I need to better protect myself against evil maids, though - luckily according to the Arch Wiki Clevis supports PCR registers.

Has someone sent an e-mail about the issue? If not, I can message debian-cd@lists.debian.org, which seems like the person you should contact.

This is very annoying to me; I’m a big fan of these images and they’re my goto for testing Debian on new hardware or doing full disk dumps/images.