User credentials should allow specifying hashed password strings in the JSON files.

[brettski74]

When creating automated installations, it's undesirable to have plain-text passwords floating around in our configuration files. It would be desirable to be able to specify a hashed password string similar to how the Ansible user module handles passwords. Maybe this could be done by having a different key for specifying the hashed password like "password-hash" and have the script use that preferentially and fall back to "!password" if the password hash was not specified.

[Torxed]

That might be better. A tiny (fractional) concern would be maintainability.
If we strictly limit it to pam then the format of /etc/shadow doesn't change very often.
But we have a few different scenarios to keep track of - and I'm not sure they all share a common format.
Luks vs PAM? Vs postgresql? We'd also eliminate our ability to boot up a system with a set password via with installation.Boot() as session which can login to a installed system typically.
Although 99% of the time, you don't need to supply credentials because running from a live environment machinectl will bypass logins, but it has been required in the past : )

I like the idea of a fallback method, the downside would be that people might get sloppy with storing this safely and if for whatever reason the backup method gets stored - it's on the loose :) User error, but lets try to figure out a way to avoid it.

[brettski74]

I'm new to Arch, so it's possible I'm unaware of the scope of variability, but I don't think we need to solve all use cases at once. If we solve for the default case, that should be a good start. Support for other cases can be added later if there is value, but given that implementing other authentication schemes likely involves other additional work, I'm not sure it's clear what the solution should be for them or if there should be one in the stock setup.

I'm unfamiliar with with installation.Boot() as session, but I'm assuming that if there are use cases that need to know the plain-text password, using the fallback option should still allow that. My concern is mainly around setting up root and non-root users on a bunch of bare-metal machines that I want to be able to setup in a repeatable and maintainable way without needing to have plain-text passwords everywhere. The workaround I was planning was to set up all the accounts with dummy passwords and then have an Ansible playbook run as a custom command to update all the users to real passwords using the hashed passwords, but that seems inelegant.

As for sloppy users, there's only so much we can do. We already have plain-text passwords in the output, so the security concern is already there. Anything which provides an opportunity to remove that should be an improvement. I expect that less technical users are going to either go through the guided prompts anyway, or work from a JSON file generated from that. If the guided setup outputs a hashed password string instead of plain-text, then we've got them on the right track at least. I'm assuming anyone who's rolling their own JSON files should know what they're doing already and understand the security implications and/or complexities of different authentication schemes.

[svartkanin]

#3276 provides this now