USA layout, no compose key: '|' characters get typed as '>'

[Hypoon]

Expected behavior

If a password works in web portals using the browser extension, it should also work on the command line when authenticating (e.g., for ssh). Passwords should be typed on the command line exactly as they're displayed on the device (and how the browser extension enters them).

Actual behavior

The password shown on the device contains pipe characters ('|'), while the password typed on the command line substitutes greater-than characters ('>'), causing an authentication failure. Since passwords are usually not echoed on the command line, this is very challenging to troubleshoot. If relevant, I'm using the standard USA keyboard layout. I'm not using a compose key.

Step by step guide to reproduce the problem

1. Save a password in the mooltipass, containing pipe characters.
2. Open a terminal
3. Start editing a blank file
4. Manually scroll through accounts in the Mooltipass and have the Mooltipass type the password over USB
5. Observe that the password typed in the file does not match the saved password

Firmware Version

AUX MCU version: 0.73
Main MCU version: 0.84
Bundle version: 12

Moolticute Version - If Involved

N/A

Operating System

Gentoo Linux, but this issue is expected to be shared across Linux distributions. I can test it on other distributions if needed.

Mooltipass Extension

N/A

[Hypoon]

Commenting to add: USA (Linux) appears to work as intended. Why does this matter? Does my standard USB keyboard know what operating system the host is running? If not, why does Mooltipass need to know? (MacOS layouts make sense, since Apple computers do actually use different keyboards).

[Hypoon]

Looks like this is actually a duplicate of a few other closed GitHub issues, where the solution is to use the USA (Linux) layout. While I did search, I didn't see those issues until after I submitted this issue. In my opinion, the fact that this issue keeps popping up is an indication that something should be changed, whether in source code or in documentation.

[limpkin]

Does my standard USB keyboard know what operating system the host is running? If not, why does Mooltipass need to know?

Your keyboard doesn't know... however your keyboard sends keycodes, not characters. For example, right now I'm typing on a swedish keyboard but know where to type if I want to type 'a' on a US layout.
The Mooltipass is different: it wants to send characters, but has the OS layout "in the way".
To be fair I receive way more requests about layout issues on PC vs Mac....

[Hypoon]

When I switch between Windows and Linux, I don't have to change the labels on my keyboard. The same key positions correspond to the same characters. The layout does not change. It is NOT analogous to the difference between Swedish and US layouts.

…

On Thu, Mar 2, 2023, 02:49 Mathieu ***@***.***> wrote: Closed #386 <#386> as completed. — Reply to this email directly, view it on GitHub <#386 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKHIXOIQMT53QV4DT26C73W2BGHPANCNFSM6AAAAAAVMU6HOU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[My1]

what's your specific layout?

especially as on the ANSI US Layout the Pipe doesnt even share a key with the greater than symbol as far as I can see) https://commons.wikimedia.org/wiki/File:KB_United_States.svg

There are sometimes several per language especially in linux there are a lot of variants, for example on Linux I love to use German (no dead keys), rather than the normal German Layout where some keys e.g. the tick in both directions (` and ´ ) or the roof (^) act as dead keys to compose letters like the é from Pokémon, which at best I use rarely.

one thing I have done is change the password generation rules to not use the characters affected.

also one thing that changes in linux on German Keyboard especially is that Linux only takes the AltGr for the 3rd level (for example the pipe), while on windows Ctrl+Alt also works for the 3rd level

[Hypoon]

Yes, that's the layout I use (ANSI US). It is the most common layout in the US. My USB keyboard has that layout, and my distribution is configured to use the "us" kbd layout. There are no dead keys in this layout or on this keyboard, at least for printable characters (maybe Sys Rq counts, but that's out-of-scope for mooltipass).

[My1]

okay, then assuming your MP is also configged to US it kinda doesnt make sense that it brings a larger than symbol tho, normally.

according to the keytable in the repo a pipe is either on the very first key on the second row from the bottom on an ISO keyboard (basically between Z and L-Shift) OR on the third row from either side (not counting f-keys so asdf etc.) the final key before enter

minible/scripts/keyboards/cldr-keyboards-37.0/keyboards/windows/en-t-k0-windows.xml

Lines 97 to 98 in 7f880df

	<map iso="C12" to="|"/> <!-- (key to right of ') base=\ -->
	<map iso="B00" to="|"/> <!-- (key to left of Z) base=\ -->

These map to the scancodes 86 and 43 (decimal) respectively, which is 56 and 2b in hex, which checks out with the list from the kbd project.

minible/scripts/keyboards/cldr-keyboards-37.0/keyboards/windows/_platform.xml

Line 53 in 7f880df

<map keycode="86" iso="B00"/>

minible/scripts/keyboards/cldr-keyboards-37.0/keyboards/windows/_platform.xml

Line 41 in 7f880df

<map keycode="43" iso="C12"/>

https://kbd-project.org/docs/scancodes/scancodes-1.html#ss1.4

The fun part that comes in might be THIS, which I found after looking how the symbol keys move around between iso and ANSI keyboards:

also after browsing the kbd repo I found this nugget.

https://github.com/legionus/kbd/blob/master/data/keymaps/i386/qwerty/us.map#L53

so it basically maps the ISO-Bottom-Left Key (86) in the same fashion as a German Keyboard, rather than the backslash/pipe the US Keyboard normally uses at that location

[My1]

@limpkin is there a reason why the key is mapped twice in the en-t-k0-windows.xml? based on what does the MP decide on which key to use? especially as "B00" is not a key that even exists on an ANSI keyboard and apparently gets differently mapped from time to time as seen above, wouldnt it be useful to throw the B00 binding out entirely for the US Keymap and just rely on "C12" instead? After all at least in the version of the XML that I picked up from the spanish issue a while ago, all B00 bindings for US are identical to the C12 Bindings

@Hypoon does the \ key above the enter key on an ansi keyboard ever change between operating systems or otherwise on a US Layout?

[limpkin]

this directly comes from the CLDR :)
from our chat:

minible/scripts/keyboards/cldr_parser.py

Line 562 in 3f7cd62

if c12_to_d13 and isocode == "B00":

[Hypoon]

Living and working in the IT industry in the United States for ~15 years, the upper-right "ANSI" configuration is VERY common. The ISO configurations with the L-shaped enter/return key are around, but I've probably seen them (in person) fewer than ten times, and I can't be certain which of those three configurations they were. I've noticed keyboards with smaller backspace keys, too, a few times. They had an extra key inserted next to the backspace key, but I don't remember what it was.

All of this is to say that in the United States, over 99% of full-size USB keyboards have the ANSI layout, and I'm not exaggerating at all, since I have personally used several hundred full-size USB keyboards.

@My1, no. I have never seen the "" key on ANSI keyboards do anything aside from produce "", and that's a very important symbol on Windows computers (considering that they use backslashes in paths). Furthermore, it's the only backslash key on the ANSI layout, so I imagine Windows users would notice pretty quickly if it behaved strangely.

[Hypoon]

Originally sent on IRC:

Another chapter in the keyboard layout nightmare: I changed my layout to the Linux variant as a workaround for the pipe-vs-greater-than issue. Since then, I've had to reset a few passwords without understanding why. I just figured it out today.

Under the previous keyboard layout, the mooltipass had been sending the wrong characters for certain symbols. The passwords that were created under the old layout were CONSISTENTLY being sent the wrong symbols. The password being used on the machine didn't match the password reported on the mooltipass, but this didn't matter because I never typed it in manually.

When I fixed the keyboard layout, now it's sending the correct symbols (consistent with what's displayed on the mooltipass), but these corrected symbols don't match the password the machine expects, which was created with the wrong symbols.

So... this weekend I get to walk through my credential library and fix all my non-web credentials so they're sane and reliable again.

@limpkin, a fix was discussed on IRC which involved adjusting the tool which interprets or generates the layouts. I'm not familiar enough with it to understand exactly what the tool does, so I could be misremembering, but hopefully you know what I mean by that. Can this issue (or one of the similar ones) be reopened to track progress on implementing the change?