Rework client password input

[dougnazar]

Couple simple changes to password handling for the clients, mainly because I don't want to specify the password on a command line for my weekly battery tests. Cleaned up the usage of deprecated getpass() while I was at it.

• clients: Use readpassphrase() if available
• clients: Add option to read password from a file

[github-actions]

A ZIP file with standard source tarball and another tarball with pre-built docs for commit 86ca800 is temporarily available: NUT-tarballs-PR-3488.zip.

[AppVeyorBot]

❌ Build nut 2.8.5.4840-master failed (commit 5e2ef700a2 by @dougnazar)

• artifacts (if any)

[jimklimov]

Gotta review actual changes, but at face value seems similar to a solution for issue #3329 that is in dev/CI loops for a few weeks now (and cooking dependent branches for further binding/client support.

Rework of getpass*() may be bringing orthogonal value to that though.

[AppVeyorBot]

❌ Build nut 2.8.5.4841-master failed (commit 752a209865 by @dougnazar)

• artifacts (if any)

[AppVeyorBot]

✅ Build nut 2.8.5.4842-master completed (commit b1ae1a9df0 by @dougnazar)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.4842-master.7z

[AppVeyorBot]

✅ Build nut 2.8.5.4842-master completed (commit b1ae1a9df0 by @dougnazar)

[dougnazar]

Oops. I did a quick search for password before submitting but nothing showed up. I did see the other patch a while ago but thought it was just about client SSL support, and didn't include passwords.

Looks like I can do what I want with that patch, although it feels a little awkward to me. If I have a system file and a user file it'll only read the system file if I include it. Perhaps the system file should always be read, with any user/specified file overriding it. Then you could force system-wide various SSL defaults and then per-user have the login credentials.

Anyways, feel free to close, I'm happy with either solution.

[jimklimov]

Actually, per upscli_read_authconf_file() in that PR, following dedicated envvars goes first, then looking under $HOME of the user, and only the last option is a system-wide file.

Whichever is found is the only one parsed (but it may INCLUDE others explicitly).

Note that the system-wide file may be generally not readable by user accounts (the few admin accounts can be part of a POSIX group allowed to read it though).

[jimklimov]

UPDATE: I realized that #3329 did not seem like related to "authconf", as the comment with config file design got hidden by github. Reworded that issue and added links to make it clearer in hindsight :)

[dougnazar]

Actually, per upscli_read_authconf_file() in that PR, following dedicated envvars goes first, then looking under $HOME of the user, and only the last option is a system-wide file.

Whichever is found is the only one parsed (but it may INCLUDE others explicitly).

However if a user creates a authconf file, they may not know to include a system default file or where the CA file is or that they should force SSL.

Also, with a system default file, you wouldn't need to always specify -A default. If you leave the file blank, everything works the same as before. Only if you add/uncomment some lines does it start to use those settings.

Note that the system-wide file may be generally not readable by user accounts (the few admin accounts can be part of a POSIX group allowed to read it though).

The way I'd handle this is a world readable system default file that INCLUDEs a protected system file. That should gracefully fail for unprivileged users.

For instance, vim, nano, jed all load a system file first, then look for a user file. So that's probably why it feels more natural for me. I'm sure there are many counter examples too.