I didn’t mean to criticize your work, which is just a password manager with adaptive interface - the more apps with adaptive interface out there the better. I also see it’s in the World area, not GNOME (which I mistakenly assumed)
NIH here comes to the approach of projects which instead of uplifting existing code (which is more or less stable and relatively widely adopted interfaces) just create (or adopt) new application which provides similar functionality but does not support existing interfaces. Which creates that so-called fragmentation.
So my frustration here was from misconception that gnome adopted this project as Yet Another Password Manager. While in reality it is not. Sorry for emotional blast.
2 Likes
happy new year ! and thank you for putting into words your side of the coin …
i was confused about this as well … why name it ‘gnome-passwordsafe’ ? wasn’t it shorter and more descriptive to name it ‘kdbx’ after the most sought out feature it has > the .kdbx file for back-up/sharing with other systems ? since ‘seahorse’ on the desktop is missing this VERY important feature … it could implement it or make use of it in it’s code base ? are there any licensing limitations ?
i’m not fond of ‘seahorse’ on the desktop as it is too obvious in the up-to-date-version from PureOS-GNOME-Byzantium that it is a mobile-wannabe app …
what is the back-end (CLI) for ‘gnome-passwordsafe’ ? do i need to write an alias just for this ?
gnome-passwordsafe had a 2-year development hiatus and a completely new set of developers. So consider the name an historic artifact, nobody of the current devs was involved in the naming and you would need to ask the original one about the reasoning :-).
1 Like
There is no backend for it. The GUI is all there is.
I cannot comment on seahorse and its codebase, I have never looked at it.
kdbx would be my preferred name too (it sounds a bit KDE-ish), but the team likes the gnome way of naming software (ho, humm, no comment), so the tendency is towards renaming it is enclave.
what about GNOME/kdbx then ? 
or G/kdbx or G-kdbx … but then the G could be confused with GNU instead of GNOME … i’m always hesitant to write it like that when i suggest packages 
I pulled myself out of that naming debate. I only vetoed the proposal “passwords”. (just imagine saying or googling “I use passwords to store my secrets.”). Also there are plenty issue proposals to support other backends. It seems that as soon as there is a semi-decent GUI app everybody thinks it should support their favorite web service too.
2 Likes
I think this is a pretty crucial feature, especially on a phone since there is no physical keyboard for unencumbered copy/paste operations and limited screen area. How would it work on the phone? Would the user need to open the Password Safe app, find and somehow copy the username, switch to the web browser app, pull up the keyboard, paste it in, then go back and repeat for the password?
Apologies, but this sounds like a troublesome workflow just to log in to a website; especially if the web browser app is exited after each use to conserve the phone battery, losing all session data and active logins. Maybe the situation is better though; I don’t have my Librem 5 yet so I can’t test how it would work. Hopefully I’m wrong.
Hmm, guess I should have watched the demonstration video before posting because it answers the question of how the workflow goes on the phone. It is a copy/paste operation switching back and fourth from the Password Safe app and the web browser. The operation seems to be better than I had imagined with an easy copy to clipboard function in the app and then a long tap paste function in the browser.
Still, this is less than ideal but I suppose isn’t as bad as it could be. Seems at least usable, nonetheless. Hopefully Password Safe will gain the autofill feature sometime.
I guess that’s some wayland limitation. Apps can’t detect the name of the current application in the foreground, etc. Afaik it’s even not that easy to just paste input into other application’s windows…
Anybody, please feel free to prove me wrong. Unfortunately, there isn’t any autotype API just like Android.
Wayland does seem to be an issue. Keepass seems to work around this issue:
For Unix-like systems with Wayland compositors, there is a plugin called KPUInput, which allows KeePass to use the
/dev/uinputdevice for sending keypresses to other windows.
(https://keepass.info/help/kb/autotype_wayland.html)
There is a further explanation of possible security issues with this approach in that kb article that is important to know.
Really, I guess I really don’t mind not having autotype; I might have been confusing that with having a browser plugin that can read the password database and automatically fill in login credentials for web pages. I don’t think that Password Safe has that feature either though. I know KeepassXC (which is what I use) does have it and it would make things so much easier if it worked the same way on the Librem 5.
1 Like
It is, and this “Plugin” is not for mere mortals. It is a pity that a more secure protocol then requires even insecurer hacks to circumvent these. IMHO, with that plugin any local user can fake any input all the time, even when only logged in via SSH. Given, that might be a reasonable limitation on a phone, but still.
2 Likes
The browser plugin is the way to go. However since the browser typically has its own “password safe”, all you really need is some means of doing a two-way sync between the two safes.
1 Like
It is indeed, but it is a pity, having to implement application-specific plugins. It will work in Firefox, but not Chromium, Epiphany, or your BankinApp™. It is a pity the Gnome system has defined/implemented a system-wide autofill system mechanism which can not be used by a small user application without replacing system daemons. Because that would be the really right way to do it. Kudos to Android with its Autofill system there.
2 Likes
I would suppose that the Gnome keyring can be used from any application, without even a plugin, much less an application-specific one.
Beyond that, they would need a single, uniform system API for accessing keyrings, with a provider plugin for the specific type of keyring (e.g. Password Safe) that you want to use. That would avoid application-specific plugins and that would allow transparently replacing one type of keyring with another.
The main reason to want to avoid Gnome keyring is the desire for cross-platform compatibility / synching across diverse platforms. Neither is a requirement for me.
1 Like
That is correct, but now we are starting to talk past each other. This thread is about Gnome-passwordsafe not being able to autofill credentials into applications, ie. web browsers.
Part of the difficulties are due to wayland’s explicit security design (not being able to type into other application’s windows, or not even being able to get the NAME of other application windows). One way around this, is by using a autofill service. Fortunately such a specification exists: org.freedesktop.Secret is a DBUS-based, provider-agnostic manner to provide autofilling for applications making use of that implementation. That specification is Desktop-independent and can be supported by all applications and DEs.
So, if gnome-passwordsafe would implement this API, all would be good. However, only one such provider can exist at any point in time, and that API is taken up by the gnome-keyring daemon on the Librem5 (and Gnome DEs).
However, gnome’s keyring provides a lot more than passwords for applications (https://wiki.gnome.org/Projects/GnomeKeyring/Architecture):
- System wide for thing like wifi passwords or ldap.
- User session specific needed for oauth, GOA, gpg key and so on. Basically you do not to sync it as it specific to the session or machine.
- Implementing an SSH agent, various PKCS#11 modules, etc…
- Portable accounts, this is usual account related to websites or internet services. This is a the issue here. These are password you would like to be able to transfer between machines.
The issue to have gnome-keyring accept additional password providers https://gitlab.gnome.org/GNOME/epiphany/-/issues/1122 was being closed for now, so we cannot hook an additional credential provider in there. And the other alternative, is replacing gnome-keyring completely, and modifying the gnome-session to not autoload it, which is quite invasive. Looking at keyring-daemon’s architecture and thinking about having to completely replace all this, just make use to the system’s autofill feature, gives me nightmares.
1 Like
Are you sure of that? I wasn’t implementing it myself but when I was introspecting it via dbus (when my seahorse was crippled by missing libhandy dependency) I figured it queries multiple backends sequentially.
Yes, only one service provider can provide org.freedesktop.Secret at any one point in time. gnome-keyring might internally query various backends.
https://gitlab.gnome.org/GNOME/epiphany/-/issues/1122#note_972884 told us we’d need to uninstall gnome-keyring if we want to become a password provider. Quote: “You can’t have multiple password managers installed… that wouldn’t make sense. One is enough. ”
1 Like
Sorry I think I confused it with libaccounts which has its own frontend (accountsservice) and multiple pluggable backends, and which also consumes libsecrets for passwords.
1 Like
GNOME-keyring is basically the SeaHorse GUI-frontend from the users perspective though, right ?