Dear Maintainer,

I keep my hard drive encryption passphrase in the "second slot" of my
YubiKey, so that I can use a long, random, secure encryption
passphrase. The YubiKey impersonates a USB keyboard, and when I press
its button for 2.5 seconds it simulates typing the passphrase followed
by hitting the Enter key.

On other installers where I use this approach, most notably the Ubuntu
installer, when the YubiKey hits the entire on the first of the two
passphrase entry fields, either it moves the cursor to the second
field, or it tells me the two fields don't match and makes me enter
the second one.

The Debian installer, however, *erases the contents of the first
passphrase field* when the YubiKey sends the Enter.

This means that to configure my encryption passphrase for Debian to
what's in my YubiKey, I had to:

* Take out my phone.
* Open my password manager.
* Search for and find the entry where the passphrase is stored.
* Make it visible in the password manager.
* Laboriously type the 32-character random passphrase character by
  character, hoping that I don't make any mistakes, complicated by the
  fact that there are some ambiguous characters in it.
* Repeat the feat a second time.

What should take a few seconds instead takes several painstaking
minutes.

TLDR The Enter key should not clear the passphrase field that has
already been entered.

Hi,

Jonathan Kamens <jik@kamens.us> (2023-09-02):

I'm assuming the main problem is that Enter moves to the next screen,
you would have to send passphrase + <tab> instead of passphrase +
<enter> to have a desired effect in the graphical installer.

Try the text-based installer instead, password and passphrase
confirmations happen on two separate screens?

I realize this makes your life harder, but I don't think it would be
reasonable to change what Enter does at this point.


Cheers,

I am not proposing to change that Enter moves to the next screen. I am
proposing to change WHEN Enter can move to the next screen, or at the
very least, what happens when it fails to do so because the inputs on
the current screen are invalid.

Regarding either of these, what the installer does is _objectively
wrong_ when compared to the best practices that pretty much everyone
else in this industry uses.

Most installers don't activate the button to move to the next screen (or
the Enter shortcut for it) until the fields on the current screen are
valid. For those that do, if the fields are invalid, they just say that;
they don't clear the screen and make the user enter everything again.

The current behavior is clearly incorrect and improving it would
literally harm no one and not break any existing, working workflows.

I cannot even imagine the reasoning behind refusing to change it.

What do you think is "unreasonable" about improving the behavior? Whom
would it harm? Who would prefer the old behavior, and why?

Using a YubiKey to hold an encryption passphrase is a high-security
option which you should support, and YubiKey owners do not have control
over the character that the YubiKey sends at the end of the passphrase.

If you'd said to me, "You're right that we could improve this behavior,
but it isn't a high priority. We'll consider it at some point in the
future," I could understand that. I might be disappointed, but at least
I could understand that work has to be prioritized. But saying it's not
"reasonable" to change it? Completely unfathomable to me.