Archinstall 3.0 Overhauls The Text-Based Arch Linux Installer

[phoronix]

Phoronix: Archinstall 3.0 Overhauls The Text-Based Arch Linux Installer

Archinstall is the convenient text/CLI-based installer for Arch Linux that allows getting the Linux distribution easily installed in a matter of minutes. Released today is Archinstall 3.0 that overhauls the Arch Linux installer with now using the curses library for rendering of the text interface...

https://www.phoronix.com/news/Archinstall-3.0-Released

[Noitatsidem]

Does archinstall still save the password as plaintext on your hard drive or has that been solved?

[Torxed]

Does archinstall still save the password as plaintext on your hard drive or has that been solved?

We store the key for secondary encrypted partitions in plaintext on the encrypted root partition, with restricted permissions.
This is more or less the only way to do it without asking the user to enter password each time we want to unlock a partition during boot (assuming you're not using a HSM).

Other than that, we don't store cleartext passwords outside of the liveboot environment (we store it in plaintext in the live ISO environment in case you want to store your setup elsewhere).

There's also one note about passwords being in the log file, which I'm investigating but haven't been able to reproduce yet (mostly due to time constraints).

[ari55]

Nice! I will test it when the Dec iso will be ready.
archinstall ( on the Nov iso ) crashed when installing pipewire.
On reddit I've read that this bug was fixed.

[OlafLostViking]

Hi!

I just wanted to start setting up a machine with multiple partitions for several installations (I would like to try out NixOS and also have a second Arch as fallback) with Arch being the regular day-to-day setup.
* All root or home partitions must be encrypted (with self defined btrfs subvolumes).
* Revovery keys/password for emergencies, Nitrokey with PIN for regular decryption.
* TPM based decryption only if reliable secure boot checks were successful.
* The signing keys for the initial boot loader incl. its configuration shall be self provisioned ones.
* All this ideally while using a ESP per distro (I know, but my UEFI supports it and I would feel more comfortable if they cannot damage each other)
* Not really a job for the installation tool, but a login to the desktop (SDDM) shall use the Nitrokeys, too.

Are these things supported by the new installer or should I Just stick to the manual methods for now?

Thanks a lot!

[Fernando M. Muniz]

The only issue that I have with archinstall is that there's no basic UI for Wi-Fi connections, requiring you to use iwctl.
I was told the the reason for that is that archinstall is designed for experienced users.
Apart from this single design choice, it's excellent, and now it will be even better.

[Gabbb]

This is an excellent change, perhaps the partitioner will be usable now for more complex layouts. (when using Archinstall I usually start it with partitions already prepared)

[stormcrow]

We store the key for secondary encrypted partitions in plaintext on the encrypted root partition, with restricted permissions.
This is more or less the only way to do it without asking the user to enter password each time we want to unlock a partition during boot (assuming you're not using a HSM).

Other than that, we don't store cleartext passwords outside of the liveboot environment (we store it in plaintext in the live ISO environment in case you want to store your setup elsewhere).

There's also one note about passwords being in the log file, which I'm investigating but haven't been able to reproduce yet (mostly due to time constraints).

Unfortunate but true. This is the case with nearly every Unix-like system*. If you need authentication/decryption during the boot process the only way to do it for pretty much any service is to store the clear text creds on the root partition. This is the same for SMB mounts on boot, wireless networking encryption (remember with most distros the key is stored in user accounts, not setup at boot), encrypted NFS, etc. Even OpenBSD, that much vaunted 'security first' OS has to store initial state credentials in plain text - your choice whether the system partition is encrypted or not. For most people having to type in multiple passwords, or the same one multiple times, is just not worth the extra effort especially if you have to manage a fleet deployment.

Consumer grade HSMs are problematic. I've seen firmware updates wipe or make keys stored in them inaccessible. AMD's fTPM isn't even functional in some CPU revisions. They also don't solve the problem of theft of the entire device. Laptops grow legs extremely well!

(*) Macs get around the problem with a built in (fully functional & largely transparent) HSM where MacOS/iOS stores all the keys.

[caligula]

This is an excellent change, perhaps the partitioner will be usable now for more complex layouts. (when using Archinstall I usually start it with partitions already prepared)

Yes the original ui was really crappy. I also got more than a dozen python stack traces along the way. They should have used some statically typed language instead.

[Espionage724]

We store the key for secondary encrypted partitions in plaintext on the encrypted root partition, with restricted permissions.
This is more or less the only way to do it without asking the user to enter password each time we want to unlock a partition during boot (assuming you're not using a HSM).

Other than that, we don't store cleartext passwords outside of the liveboot environment (we store it in plaintext in the live ISO environment in case you want to store your setup elsewhere).

There's also one note about passwords being in the log file, which I'm investigating but haven't been able to reproduce yet (mostly due to time constraints).

I'm not sure what most of that means exactly at the moment, but that sounds like a lot of words to say yes to storing a password plaintext somewhere, and that sounds particularly odd and interesting to be singled out with Arch.

What do other distros do in this regard?