Allow picking specific Monospace font

[LinuxOnTheDesktop]

Summary

It seem to me that, unless I force an override via a global (DE) font setting, KeePass will use fonts that do not clearly distinguish the zero character from the capital 'o' character.

Desired Behavior

'0' and 'O' would be clearly distinguished, ideally via a font that puts a strike through the number.

Possible Solution

The app would have a setting for changing its font and, ideally, to a font that clearly distinguishes 'O' and '0' - and the app would advertise the point of this (that point being, that it is important for a password program so to do - for, sometimes, one will transcribe what one sees in the app - onto, for instance, a different device).

Context

Sometimes I transcribe from one device to another, i.e. from what I see in KeePassXC to e.g. my phone.

[phoerious]

That's hard to do cross-platform. On Windows we already prefer Consolas, but on other platforms the Monospace font could be anything and no specific font is guaranteed to exist.

[droidmonkey]

What OS / Desktop Env are you using? We already implement "Monospace" font family in the password field. There is a known bug on LXDE regarding fonts and Qt. https://github.com/keepassxreboot/keepassxc/issues/1771#issuecomment-375773730

https://github.com/keepassxreboot/keepassxc/blob/develop/src/gui/PasswordEdit.cpp#L34-L37

[LinuxOnTheDesktop]

What OS / Desktop Env are you using?

I should have said: Linux Mint Cinnamon; and Cinnamon uses GTK for preference. I can provide some screenshots of 0s and Os if you like.

[Tux]

I just tried keepassxc today as a possible replacement for keepassx-0.4 and this was the first thing that struck me as "Unusable". openSUSE Tumbleweed and openSUSE Leap 15.0 This tool definitely needs a setting for a selectable font I compiled from git and added

			  <property name="font">
			    <font>
			      <family>Monospace</family>
			      </font>
			    </property>

to <widget class="QWidget" name="entryNotesTab"> in ../src/gui/EntryPreviewWidget.ui Now keepassxc is much better usable for me

[phoerious]

"Monospace" is not a font, it's a fallback name that could be anything. This points to a broken font config on your system and you should configure a different font as your default Monospace font.

KeePassXC respects that setting as long as Qt is made aware of what your Monospace font is:

[Tux]

I did, but I did not want to force my preferences onto the rest. My prefered fixed-width font = DejaVu Sans Mono

[rwky]

I'm using KUbuntu 19.04 and that has the default mono space font of 'Hack' this works fine in the Kate text editor but KeepassXC doesn't pick it up I'm not sure what font it's using see screenshot It makes it difficult to tell the difference between I and l and O and 0

This is what Kate displays

P.S. I have version 2.4.3 using the AppImage

[LinuxOnTheDesktop]

Kate's rendering of the zero seems somewhat strange and ugly but the rendering does satisfy the desideratum here. To wit: enable the user to distinguish the number zero from the letters 'o' and 'O'. Surely enabling the user to make that distinction is a basic prerequisite for a password manager.

[droidmonkey]

Are you using the qt5ct "theme"?

[rwky]

I assume you mean the plasma theme? It's 'Breeze Dark'

[droidmonkey]

This is probably a theme issue not passing the monospace font to Qt correctly. We request a monospace font in the password field.

[rwky]

I've tried this with a few different themes, KeepassXC gets the same font with all of them. Since it works with Kate and Konsole I'd assume the theme is doing it's thing correctly.

[droidmonkey]

Not necessarily. I believe Kate and Konsole request a specific font, not a font family like we do.

[rwky]

Any idea on how to debug further? It wouldn't be a terrible idea if keepassxc had an option to set a specific font.

On Fri, 11 Oct 2019, at 22:26, Jonathan White wrote:

Not necessarily. I believe Kate and Konsole request a specific font, not a font family like we do.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/keepassxreboot/keepassxc/issues/2741?email_source=notifications&email_token=AABFBI4KK5KM5YSKSCTLCLTQODVSBA5CNFSM4G2ECGL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBBIF5Y#issuecomment-541229815, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFBI67H5PQ4T7Q7GHULETQODVSBANCNFSM4G2ECGLQ.

-- Regards

Rowan Wookey BSc (Hons) Comp, CISMP, MBCS Server Administrator & Programmer

Please add [email protected] to your contacts/email whitelist.

[phoerious]

Which release are you using? AppImage? Snap? PPA? Distribution-native packages (if so, what distribution)?

[rwky]

P.S. I have version 2.4.3 using the AppImage

[phoerious]

The AppImage most likely does not pick up your system theme (which is a limitation of shipping our own Qt, unfortunately). The Snap or a native package should solve the problem. If you want the AppImage to use the correct font, you will have to modify the global fontconfig settings, most likely.

[LinuxOnTheDesktop]

The AppImage most likely does not pick up your system theme (which is a limitation of shipping our own Qt, unfortunately). The Snap or a native package should solve the problem. If you want the AppImage to use the correct font, you will have to modify the global fontconfig settings, most likely.

For my part I don't think I was using the AppImage. I should have recorded whether or not I was in my original report. I cannot easily check now because, whilst keepassxc has its shutdown problem, I'm using KeePass under Wine.

[rwky]

I've tested on another machine and the app image is working fine, oddly enough the snap doesn't pick up the dark theme so doesn't look right but that's a separate issue.

Considering it works fine on one system I'd assume it's some weird problem local to the one machine and not a keepassxc problem.

[droidmonkey]

That's what I've been saying :smirk:

[sts10]

👋 I'm here because today I mistook an S for a 5 in a password.

(Screenshot is from v2.5.1, via Snap, Kubuntu 18.04, but I think the 5 vs. S issue was worse on my Mac...)

One idea we might borrow from 1Password that I like is using a slightly different color for numbers -- maybe a green, to match the KeePassXC logo? This would help mitigate/bypass the font availability problem discussed above. Just an idea.

Edit: My particular use-case was reading a password from my laptop to input on a mobile device, something that I admittedly do infrequently.

Debug info in case

KeePassXC - Version 2.5.1 Revision: 0fd8836 Distribution: Snap

Qt 5.9.5 Debugging mode is disabled.

Operating system: Ubuntu Core 18 CPU architecture: x86_64 Kernel: linux 5.3.0-23-generic

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare (signed and unsigned sharing)
• YubiKey
• Secret Service Integration

Cryptographic libraries: libgcrypt 1.8.1

[jimcheetham]

Using color alone isn't a wonderful differentiator, for accessibility reasons.

Perhaps every glyph/character should have an indicator or some sort, identifying its type (upper/lower case, number, non-"ascii") ... not necessarily all the time, but only when displayed in a context that means its likely the user will be manually retyping the phrase.

Here's an example, with the passphrase on one line and the glyph indicators on a second line, in the limited medium of text in markdown :-) so I get to avoid issues with variable-width glyphs and actual useable UI design ...

1lo0O⚬
NLLNU!

Number one, lower letter L, lower letter L, lower letter O, number zero, upper letter O, pictograph "o"

[sts10]

Using color alone isn't a wonderful differentiator, for accessibility reasons.

Ugh, sorry, I feel bad for not thinking about this. Thanks for your note.

[jimcheetham]

Absolutely not my intention to make you feel bad - color isn't a bad indicator! Just not on its own, without other elements :-) You could argue in this case that as the color would only be providing a hint, and that we already had the actual content on display, it wouldn't be inappropriate.

[ajay-gh]

Let me add a few observation, simply because I think there is a problem - and it hasn't been fully addressed !

• first, a number of older posts on this board show that users with different platforms have run into the very same 'font' problem, and have not been very satisfied with the proposed solutions;
• I have had problems with ambiguous passwords (osx), and simply changing a system wide font settings (not a standard option under osx) did not solve the problem;
• next, try and edit a new entry in keepassXC, add a user name with ambiguous letters (oO0LliI ...), copy this user name and paste it into the other fields like notes or password. The result: the chars look different in every field, and you still don't know what you read.

[remark: the "monospace" setting in general settings changes sth, but it doesn't solve the problem]

For any user who cannot use autotyping or who's got to enter some passwords manually into his DB which where generated by another system (e.g. Apple's Timemachine) this is quite unsatisfactory. Best Regards

[felix-otto]

While trying out KeePassXC I missed the option to customize the font used for displaying the password(s). It's a feature I know from KeePass 2 (see screenshot below). Tools => Options => Interface (2)

Source Code Pro helps me to distinguish look-alike characters in passwords. In other situations/environments I prefer different (mono space) fonts.

Setup: KeePassXC 2.7.4 and KeePass 2.52 on Windows 10 22H2

[droidmonkey]

You can change the default monospace font on windows in the registry: https://superuser.com/a/1567627 The font selection is a feature we are interested in adding though

[felix-otto]

The font selection is a feature we are interested in adding though

👍

I didn't find such a clear statement in the existing issues (so far it was rather about mono space in general or font size). Looking forward to see this in one of the future releases.

[michaelk83]

Source Code Pro helps me to distinguish look-alike characters in passwords.

You can use colored passwords for that since 2.7.2.

[haarp]

I'm seconding (tenthing?) this request. I understand that there are bugs that can prevent KXC from picking up the system's monospace font. But why use the system font to begin with? There's no guarantee that it has distinguishable characters.

IMO it's in a password manager's interest to either provide a good font, and/or allow the user to override it. It shouldn't depend on the system to provide it with a suitable font.

Thanks!