Archinstall 3.0 Overhauls The Text-Based Arch Linux Installer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mr.Elendig
    replied
    Originally posted by caligula View Post

    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.
    In most cases that would only have made the error look different.

    Leave a comment:


  • ayumu
    replied
    Originally posted by Torxed View Post
    We store the key for secondary encrypted in plaintext on the encrypted root partition, with restricted permissions.
    This is more or less the only way to do it withoutpartitions asking the user to enter password each time we want to unlock a partition during boot (assuming you're not using a HSM)..
    There is a trivial, MUCH BETTER way than storing the passphrase in plaintext, which is extreme negligence.

    Use another key slot. LUKS2 gives you key slots. Use them. Use another key slot, and a keyfile.

    It really is that simple.

    Leave a comment:


  • pieman
    replied
    have they finally added the ability to create swap partitions with it?

    Leave a comment:


  • Espionage724
    replied
    Originally posted by Torxed View Post

    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?

    Leave a comment:


  • caligula
    replied
    Originally posted by Gabbb View Post
    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.

    Leave a comment:


  • stormcrow
    replied
    Originally posted by Torxed View Post

    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.

    Leave a comment:


  • Gabbb
    replied
    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)

    Leave a comment:


  • Fernando M. Muniz
    replied
    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.

    Leave a comment:


  • OlafLostViking
    replied
    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!
    Last edited by OlafLostViking; 17 November 2024, 11:45 AM.

    Leave a comment:


  • ari55
    replied
    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.

    Leave a comment:

Working...
X