apply menu password entry to SMB + hotspot

[dndrks]

addresses #1531

summary

this PR proliferates the menu password entry (under SYSTEM > PASSWORD) to the SMB + hotspot passwords as well.

implementation

• for SMB, I used printf for the smbpasswd -a command because it requires double-verification of the new password
• for hotspot, a hidden .system.hotspot_password file is created in the data folder, which holds the password. this file is checked by wifi.lua whenever the hotspot is activated.
  • if the file exists, norns passes the password contained
  • if the file doesn't exist, norns uses the default "nnnnnnnn"
  • since maiden doesn't show hidden files in the file selector, this seemed like a good solution (it is viewable in maiden by accessing <norns_address>/maiden/#edit/dust/data/.system.hotspot_password)

testing

this tested well on my standard norns (CM3+) and macOS Monterey 12.0.1:

• connected via Cyberduck + changing the password: new password was prompted and accepted
• connected via SMB + changing the password: new password was prompted and accepted
• connected via hotspot + changing the password: after disabling and re-enabling hotspot on norns (since the password is only proliferated when hotspot is activated), network connectivity was lost and new password was prompted + accepted

[tehn]

smb password set, awesome!

hotspot--- concerned that this technique puts the system password in plaintext on a file in dust. maybe @ngwese or @catfact have alternative ideas?

[ngwese]

i agree it is maybe not ideal that the password is within view of maiden. early on i remember having wifi code which created the hotspot connection configuration once instead of each time the hotspot connection is enabled. i've long forgotten the reasons why we have it that way instead of creating it when for example the password is being changed and simply activating later.

i couldn't come up with any alternative ideas which were more secure. i guess at a minimum sticking the password under /home/we/.config/... would be slightly better. fwiw network manager stores wifi passwords in clear text within per connection config files in /etc/NetworkManager/<name>.nmconnection but at least the file is only readable by root. again that isn't much of a hurdle since the we user has password-less sudo.

alternatives could be to generate a new random password each time hotspot is enabled and print it to the screen. i contemplated printing a QR code to the screen but while that would be slick for a mobile devices it would not work well for a computer.

[dndrks]

thanks for the additional insights + brainstorming <3

alternatives could be to generate a new random password each time hotspot is enabled and print it to the screen.

this is a cool idea! this morning, i was thinking a fair middle-ground between this and storing in a too-accessible location might be requiring the user to generate the password each time they enable hotspot. which is initially attractive to me because i use hotspot a fair amount during dev on my mac and feel ornery about clearing my previously-saved network or waiting for it do the minute-long cycle of trying to connect with the previous credential before it just gives up. but that's honestly less overall effort than using the encoders to enter a password on norns.

rad, i'm happy to take a pass at this, unless there's any counter arguments to this approach (@tehn) ?

[ngwese]

i agree that generating a random password each time is going to be annoying for anyone who uses hotspot with regularity. if we could do setting password on first activation or simply recreate the hotspot connection profile when changing the password i think that would minimize friction.

the one thing which occurs to me is that the nmcli profile creation might fail if the nub isn’t plugged in.

[tehn]

has anyone tried hotspotting in reverse, ie have your mac make the hotspot then join that? or is the problem that setting up hotspot is obscure for various os's? (yes i am trying to rationalize taking away the hotspot feature!)

…

On Fri, Apr 29, 2022, 9:18 AM Greg Wuller ***@***.***> wrote: i agree that generating a random password each time is going to be annoying for anyone who uses hotspot with regularity. if we could do setting password on first activation or simply recreate the hotspot connection profile when changing the password i think that would minimize friction. the one thing which occurs to me is that the nmcli profile creation might fail if the nub isn’t plugged in. — Reply to this email directly, view it on GitHub <#1570 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB4I4FYD6W7GMSVYPSX4PLVHPOSPANCNFSM5UTAA57A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ngwese]

i’m not sure if the internet sharing functionality in macos would allow the wifi to act as both an AP (for norns) and a client to an existing wifi network. i have used a wired ethernet from norns directly connected to a laptop and the laptop connected to the outside world via wifi. that worked fine.

i have no idea if the same could be accomplished on linux or windows with the same level of ease.

taking a step back if the motivation for the hotspot password is to protect norns in a shared environment more so than it is today the existing default password might be fine as long as maiden eventually gets password protection. (which i intend to look at after the norns converged branch is fully stable)

[tehn]

ah, i never expected that internet sharing would work with hotspot in any OS--- as the transceiver would need to be active on two channels--- i'm uncertain modern wifi cards are even capable of doing this?

more my point: it seems we have hotspot mode to address the situation where a known wifi network isn't available, and we don't want to explain in the docs how to have your computer (in macos, windows, and linux) create a hotspot (hosted by your computer) for norns to connect to. so we complexify norns in order to lessen the assumed knowledge by the user of their OS. in the end, all we're trying to do is get a network connection between these two devices. is this a fair assessment?

back to the actual point:

i think what dan's PR is trying to do is simplify the password situation, so there aren't multiple passwords. more of a usability issue than a security issue. (of course, if any of us saw a "norns" network in a coffee shop, tada)

[ngwese]

apologies if my responses above muddied the waters. i think it is fine for all the passwords to be the same and i agree that the end goal is to establish a connection between norns and computer with the minimum of friction.

sticking the password in clear text in a file is certainly a improvement over a fixed non configurable password. keeping the password in a file away from parts served by maiden at least keeps it from being accessed directly via URL.

[dndrks]

sorry for the massive delay! i forgot that we landed on greg's super helpful summary:

sticking the password in clear text in a file is certainly a improvement over a fixed non configurable password. keeping the password in a file away from parts served by maiden at least keeps it from being accessed directly via URL.

with this in mind, i pushed the following improvements:

• after new password is set via SYSTEM > PASSWORD, hotspot password is saved to a hidden and maiden-inaccessible home/we/norns/.system.hotspot_password file
• if maiden is open during password reset, user will see a prompt to toggle wifi off/on for the change to take effect

i think this covers folks pretty well, but happy to keep pokin' if there are further concerns (@ngwese + @tehn ). all's been tested, working well through a few password changes connecting with a macOS Monterey device + Pi3B shield