GNOME Bugzilla – Bug 711252
Use a header bar
Last modified: 2018-08-03 19:32:45 UTC
The use of titlebar + menubar + toolbar in the current seahorse looks rather outdated. It would be nice to have the app be more consistent with the new GNOME 3 apps. From a design perspective, it is not too hard to move the existing UI around to fit a more modern form: https://raw.github.com/gnome-design-team/gnome-mockups/master/passwords-and-keys/wire-passwords-and-keys.png This accommodates all the existing actions. There are possible half-way points between the current form of seahorse and what is shown in the mockups. For example, you could port to use a header bar and keep the existing sidebar (thus negating the need for the view switcher and search filters).
This sounds interesting and I would like to work on it if the maintainers agree on the direction. To check the usability, I have created an initial implementation. To test my work (which is still heavily rebasing): $ cd ~/jhbuild/checkout $ git clone -b wip/dueno/headerbar https://github.com/ueno/seahorse $ jhbuild build seahorse $ jhbuild run seahorse Here is also an screencast: http://du-a.org/~ueno/seahorse-headerbar.webm The migration is being done in 3 steps: (1) fixes to the build process (2) modernize the implementation, preserving the current UI (3) modernize the UI, using headerbar and popover (1) is filed as bug 752516. (2) means to replace GtkAction with GAction so that (3) can be implemented easier. At the moment, I have not touched sidebar, key list, generator, etc, as I am uncertain that we can eliminate some less common features (e.g. combined mode) for the new design. I would like to hear opinions on that.
Cool that you want to work on this, Daiki! The screencast looks really promising. The mockups in the original bug are really old, and I think I'll need to go back and take another look at them. I'll let you know when I have something.
OK, here we go. New mockups! https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/passwords-and-keys/passwords-and-keys.png I realise that this is possibly a bit more dramatic than what you were thinking of originally, and that this is a much thinned down version of Seahorse. However, having considered what the app is useful for, this seems like an effective approach. Also, this is open to modification, so let me know if anything needs changing.
I think the ability to manually add passwords is a critical feature. That really beats using a text file or scrap paper for them. Other than that, the slimmed-down the UI is much nicer, as is getting rid of all the confusing details about keyrings. I'm not completely sold on getting rid of the UI for certificate management, but the current mess is probably worse than nothing, certs are probably best managed from the command line since normal users shouldn't be touching those, and the application is of course not called "Passwords and Keys and Certificates."
(In reply to Michael Catanzaro from comment #5) > I think the ability to manually add passwords is a critical feature. That > really beats using a text file or scrap paper for them. Other than that, the > slimmed-down the UI is much nicer, as is getting rid of all the confusing > details about keyrings. Are apps able to use the passwords that you manually enter into Seahorse? Or do you have to manually find, copy and paste them, in order to use them?
> Are apps able to use the passwords that you manually enter into Seahorse? Or > do you have to manually find, copy and paste them, in order to use them? All apps have the ability to use all the passwords (i.e. all apps you install on your system are trusted). But I don't think any non-malicious app would use a password that was manually entered. I have to copy/paste. It's important when a site's login form that isn't autodetected by Epiphany, so the password can't be remembered automatically (e.g. GNOME Bugzilla); in that case, it's either save the password manually in the keyring, or pick a memorable (i.e. insecure) password, or request a password reset requests whenever I clear cookies or log in from a different device....
(In reply to Michael Catanzaro from comment #7) > > Are apps able to use the passwords that you manually enter into Seahorse? Or > > do you have to manually find, copy and paste them, in order to use them? > > All apps have the ability to use all the passwords (i.e. all apps you > install on your system are trusted). But I don't think any non-malicious app > would use a password that was manually entered. I have to copy/paste. It's > important when a site's login form that isn't autodetected by Epiphany, so > the password can't be remembered automatically (e.g. GNOME Bugzilla); in > that case, it's either save the password manually in the keyring, or pick a > memorable (i.e. insecure) password, or request a password reset requests > whenever I clear cookies or log in from a different device.... But the point remains that an app has to know how to use the password: it needs to know the website, email account, or so on. If you manually enter a password on its own, your apps can't use it. To me, Seahorse's is the front-end to the system-wide password and key storage - the storage that is used by apps. If you have two pools of passwords - one for manual use, and one for automatic use - it confuses the role of the app. There are plenty of other apps you can use to manually store your passwords.
(In reply to Allan Day from comment #8) > There are plenty of other apps you can use to manually store your passwords. tbh I don't know of one, so my plan is to use gedit if seahorse loses this capability. I don't care whether my passwords are encrypted in gnome-keyring because I care as much about my files on disk as I do about my passwords. Maybe some users have other security requirements and would be displeased by this change, but it's fine by me.
Just a user scenario from a random user here: I currently use KeepassX to store all my passwords manually, with its encrypted database stored on a cloud service like Google Drive so I can access it on all my devices. Since my hard drive is encrypted anyway, I also try to let the system (Firefox and passwordless gnome-keyring) store as much as possible all of my passwords as well so I don't have to manually copy and paste into my programs. But this is just convenience: the ground truth is the cloud-stored password database, which is also used for example my phone. It would be nice if gnome-keyring could manage all of that, but it would have to be rewritten to use a well-known database storage format, so it can be shared with other platforms. It's probably more feasible to just let gnome-keyring manage GNOME's passwords.
Thanks for working on this, seahorse really need some love. I'm wondering the status of this redesign. Also, having a good password manager in GNOME would be awesome and very useful to push good security practices. To my opinition, there is no reason why it should not be done by seahorse, that would be the central point for managing user secrets, but that's open to discussion for sure.
Thank you for improving seahorse! I'd like to ask what the current status of the project is. I've found the GitHub repository ueno/gnome-credentials. Quote from the README: "... [I]t might be eventually merged back, once the design and features have been finalized." Is there any information whether the code has been merged back? And if yes, where is it merged back? The repo seems to be dead for some months. Is the project also dead?
I think so. We've had several people interested in working on seahorse doing work in separate GitHub repos. We need somebody to step up and take over maintenance of the current seahorse repo, regardless of whether that means maintaining the existing code or starting from scratch.
(In reply to dev.nipe.systems from comment #12) > I'd like to ask what the current status of the project is. I've found the > GitHub repository ueno/gnome-credentials. Quote from the README: > > "... [I]t might be eventually merged back, once the design and features have > been finalized." I removed this sentence as I am not sure if it still makes sense. It would be certainly better not to create a fork, but reorganizing the current Seahorse code to match the new design would be a significant task and error prone (like bug 752990). Anyway, for what it's worth, I have created a release and made it installable through flatpak: $ flatpak install --from https://ueno.github.io/gnome-credentials-releases/gnome-credentials.flatpakref $ flatpak run org.gnome.Credentials I can migrate it to git.gnome.org at some point, but first I would like to hear any opinions about it.
I got a crash: ** (gnome-credentials:2): CRITICAL **: credentials_secret_schema_network_password_real_get_title: assertion 'value != NULL' failed *** Error in `gnome-credentials': free(): invalid pointer: 0x0000000000450722 *** I don't have a backtrace because I don't know how to install debuginfo for a flatpak app. I think you should probably migrate gnome-credentials to git.gnome.org now and get a Bugzilla product created, that way we can deal with these issues on Bugzilla in a sane manner. And have it replace seahorse in the GNOME modulesets.
Created attachment 352179 [details] Backtrace of flatpak app (In reply to Michael Catanzaro from comment #15) > I don't have a backtrace because I don't know how to install debuginfo for a > flatpak app. I got the same crash.
(In reply to Michael Catanzaro from comment #15) > I got a crash: > > ** (gnome-credentials:2): CRITICAL **: > credentials_secret_schema_network_password_real_get_title: assertion 'value > != NULL' failed > *** Error in `gnome-credentials': free(): invalid pointer: > 0x0000000000450722 *** Assuming that the assertion failure caused the following crash, I have removed the assertion (it was too rigid actually), and rebuilt the flatpak. > I think you should probably migrate gnome-credentials to git.gnome.org now > and get a Bugzilla product created, The git repo was moved to git.gnome.org a while ago, but I am still waiting for Bugzilla product creation.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/seahorse/issues/95.