Date: Thu, 09 Jul 2026 01:23:56 +0000 From: bugzilla-noreply@freebsd.org To: sysinstall@FreeBSD.org Subject: [Bug 295428] Installer: root password truncates to 32 characters Message-ID: <bug-295428-8135-4Imk4mtDJj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-295428-8135@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295428 --- Comment #1 from Devin Teske <dteske@FreeBSD.org> --- Investigated and problem appears to be here: https://cgit.freebsd.org/src/tree/usr.sbin/bsdinstall/scripts/rootpass#n99 https://cgit.freebsd.org/src/tree/usr.sbin/bsdinstall/scripts/rootpass#n100 ``` "Password" 0 0 '' 0 17 32 32 \ "Repeat password" 1 0 '' 1 17 32 32 \ ``` Wherein 32 is interpreted by the invocation of bsddialog (shown below) ``` bsddialog ... --passwordform ... ``` as `fieldlen` and `maxletters` as-documented in `man bsddialog`: ``` --passwordform text rows cols formrows [label ylabel xlabel init yfield xfield fieldlen maxletters] ... ``` And the POLA violation that is afoot here is that (you can see) nowhere in the invocation is the user told that their password is going to be truncated to 32 characters. Now, as you are typing, you see asterisks (*) [because --insecure is passed] and because fieldlen and maxletters is the same number, the user has no visual indication that their keystrokes have reached a limit. ``` output=$(bsddialog --backtitle "$OSNAME Installer" \ --title "Set $username password" \ --cancel-label "Skip" \ --passwordform --insecure \ "Please select a password for the system management account ($username) $errormsg" \ 0 0 2 \ "Password" 0 0 '' 0 17 32 32 \ "Repeat password" 1 0 '' 1 17 32 32 \ 2>&1 1>&5) ``` Put quite simply, user starts typing, field starts filling with asterisks, field fills completely with asterisks, and user continues typing thinking that their keystrokes are continuing to register. However, when the user hits enter, no error is generated and instead the input is (to the user's perception) truncated and when they boot to the login prompt, they will be (as I was) astonished that their password does not work. On a hunch alone, I (as stated previously) started truncating my password until it let me in. Simply making fieldlen greater than maxletters would have generated a user interface that would have communicated to the user that their additional keystrokes beyond maxletters were being ignored and not registering. On top of that user experience change, putting in the dialog text to the effect of "limited to N characters" would have further communicated why the behavior was such that an unlimited number of characters will not register. This can be tested by changing the test-invocation below (that replicates the installer prompt): ``` bsddialog --backtitle "FreeBSD Installer" --title "Set root password" --cancel-label "Skip" --passwordform --insecure "Please select a password for the system management account (root) " 0 0 2 "Password" 0 0 '' 0 17 32 32 "Repeat Password" 1 0 '' 1 17 32 32 ``` to instead pass `33 32` such as below: ``` bsddialog --backtitle "FreeBSD Installer" --title "Set root password" --cancel-label "Skip" --passwordform --insecure "Please select a password for the system management account (root) " 0 0 2 "Password" 0 0 '' 0 17 33 32 "Repeat Password" 1 0 '' 1 17 33 32 ``` However, that doesn't quite do it. What it does is reveal yet another bug. When you get to the 32'nd character of input, the cursor stops moving forward (good; indicating you've reached the max) and the cursor is stopped before the end of the field (also good). However, when you press backspace, you expect the 32'nd character to be removed. That is not what happens. Because the cursor did not advance to the next position when the max is hit and backspace causes the character immediately to the left of the cursor to be deleted, the 31'st character is removed. Put quite simply, if you use the above invocation which has 33 fieldlen and 32 maxletters and enter: 12345678901234567890123456789012 Then press backspace followed by ENTER, you get: 1234567890123456789012345678902 So it is clear that bsddialog is not tracking when it has reached maxletters to artificially remove the last character but keep the cursor stationary so that the rather astonishing removal of the second-to-last character does not occur. This is of course all entirely orthogonal to displaying to the user what the maximum is. I say this because naturally we will want to support more than fieldlen letters/characters, and there is no indication whatsoever that the maximum has been reached. This fact will remain whether we omit --secure or not. The good: There is a *very* subtle indication when fieldlen>maxletters that the max has been hit, and that is when an '*' appears under the cursor instead of immediately to the left (applies only when --insecure is given). The bad: Few will be paying that close of attention to notice it, and even if they do, if they choose to backspace, then you hit the second bug and start removing all-but the last character typed (which is tantamount to corrupting the input because without seeing the characters, there's no indication to the user that the input is nor malformed). There is of course only one workaround and that is to use the arrow keys to advance the cursor to the right after first deleting the maxletters'th character and then delete one additional character to take the input to maxletters-2. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-295428-8135-4Imk4mtDJj>