Description of problem: The ibus-typing-booster saves all my password that I enter to a terminal. It runs even when I haven't enabled it. It comes up when I am in tablet mode. The passwords can be read from it's database. Version-Release number of selected component (if applicable): How reproducible: Open a terminal and sudo or ssh to servers. Steps to Reproduce: 1. 2. 3. Actual results: It saves my passwords. Expected results: It shouldn't save my passwords. Additional info:
Is this with the virtual keyboard?
It starts when I switch to tablet mode. Then, if I write a password to a terminal with the virtual keyboard, it saves it. When I switch back to normal mode, it keeps running and trying to complete the normal keyboard too. And saves the passwords.
Input methods always have this problem in terminals. There seems to be no way an input method can know that a password prompt is currently visible in a terminal. In “normal” GUI programs (Gtk, Qt, ... programs which have “normal” entry fields), the program usually either disables input methods completely on entries which take a password *or* the program sets an input hint that this is a password entry and the input method can react. For example in ibus-typing-booster I have: https://github.com/mike-fabian/ibus-typing-booster/blob/main/engine/hunspell_table.py#L5735 ``` if (not self._input_mode or (self._input_purpose in [itb_util.InputPurpose.PASSWORD.value, itb_util.InputPurpose.PIN.value])): return self._return_false(keyval, keycode, state) ``` But terminals do not disable input methods when a password prompt is shown and they do not set such hints either. In some programs, there is a feature surrounding text which means that and input method can query what text is there in the vicinity of the cursor. With surrounding text, it would be theoretically possible for an input method to get the text next to the cursor and parse it to find out whether there is a password prompt or not. This would be quite error prone though, there are many variations of password prompts: Trying to match all password prompts with regular expressions reliably without false positives is quite hard. And I cannot even try to do this using surrounding text because none of the terminals I know of supports surrounding text. See this issue: https://gitlab.gnome.org/GNOME/vte/-/issues/2065 https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/vte.cc#L4457 ``` bool Terminal::im_retrieve_surrounding() { /* FIXME: implement this! Bug #726191 */ return false; } ``` I think vte is used by gnome-terminal *and* xfce4-terminal. I don’t know any other terminals supporting surrounding text either. I was wondering whether the terminals have any knowledge at all about whether a password prompt is shown or not. Usually, when a password prompt is shown, either the typed characters are not echoed at all or one sees a row of asterisks ***** But who does this? The terminal or the program showing the password prompt, i.e.is this hiding done by ssh or by the terminal? As I was not sure I tried to ask the xfce4 developers: https://gitlab.xfce.org/apps/xfce4-terminal/-/issues/112 But there was no reply. *If* the terminals know that a password prompt is shown, *then* they could set InputPurpose.PASSWORD. But my guess is that the terminal does not know that either, only the program doing the prompt (like ssh) knows.
OK, in the last comment I explained what the situation is for input methods and password prompts in terminals. Not much can be done at the moment short of disabling the input methods in terminals manually when needed, because the user knows when a password prompt is shown. *But* in this special case the user hasn’t even enabled ibus-typing-booster at all, it has been enabled automatically by the on-screen-keyboard (OSK). And there seems to be no way to manually temporarily disable it. So what can we do then? I was thinking about doing the following “hack” to make it less bad maybe: *If* I can detect that OSK is shown *and* I can detect that the input is into a terminal, *then* disable the (automatically enabled) ibus-typing-booster. Of course that would have the disadvantage that the OSK would not show any predictions in terminals, which might be bad for people who use chat or mail programs in terminals. But apart from that, predictions are of rather limited use in terminals anyway, terminals running shells usually offer other means to complete, for example the bash completions (I sometimes use typing-booster completions in terminals for some things which don’t work so well with bash completions and bash completions for most stuff, but that is a very special usecase). So I think disabling the (automatically enabled) typing booster if OSK is shown and input is into a terminal would be a resonable compromise. *But*, unfortunately I cannot even do that at the moment because: - I can detect that OSk is shown reliably only on Wayland, not on Xorg, see: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5865#note_1570500) - I can detect that the current input goes into a terminal only on Xorg, not on Wayland (I’ll open a new issue upstream for this ...) So there is no way that I can detect both OSK and input into a terminal at the moment. I am at a loss what else I could do at the moment.
(In reply to Mike FABIAN from comment #4) > - I can detect that the current input goes into a terminal only on Xorg, not > on Wayland (I’ll open a new issue upstream for this ...) https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5958
(In reply to Mike FABIAN from comment #5) > (In reply to Mike FABIAN from comment #4) > > - I can detect that the current input goes into a terminal only on Xorg, not > > on Wayland (I’ll open a new issue upstream for this ...) > > > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5958 This issue has been fixed by Jonas Ådahl in https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2511
https://github.com/mike-fabian/ibus-typing-booster/issues/393 https://github.com/mike-fabian/ibus-typing-booster/commit/eddf25f076d0cc7402ac9fa6f4bc792e78b2b5f4 which is included in: https://github.com/mike-fabian/ibus-typing-booster/releases/tag/2.19.6 now “fixes” the problem on Gnome Wayland if the merge request mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=2130717#c6 is available in gnome-shell. It switches off typing-booster completions *if* OSK is visible *and* the input purpose is TERMINAL.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-164aee39a7 for rawhide
https://bodhi.fedoraproject.org/updates/FEDORA-2022-d37f4a9196 for f37 https://bodhi.fedoraproject.org/updates/FEDORA-2022-a434ac3c9a for f36
Closing as FIXED in Rawhide. (Fixed only for Wayland, not for Xorg! But OSK is does not work so well on Xorg anyway, so maybe fixing this on Wayland is good enough for the moment).