#322 A password manager installed by default
Closed: Won't fix by aday. Opened by cereal-lava-planet.

A password manager is a must nowadays and it can be difficult to trust in a provider, especially if you aren't familiar with computers. Fedora could have a local password manager installed by default.

Secrets seems a good candidate: https://gitlab.gnome.org/World/secrets


Well we already have gnome-keyring. Does Secrets show what you have in gnome-keyring? I think Secrets is just a client for KeePass. If we install a GUI, it should really be able to display the contents of our existing password manager.

We used to have Seahorse, but I removed it when it had been unmaintained for a long time. Nowadays it is maintained again, but... it's still not really designed to be presented to end users.

cereal-lava-planet commented

Does Secrets show what you have in gnome-keyring?

No.

I think Secrets is just a client for KeePass.

It is. The UI is way more simple and easy to use.

I tried Seahorse a while back and it's too "technical".

Whether we include KeePass or Bitwarden by default, I'm not sure the visibility is enough to encourage even one additional user to actually use it. I think a Fedora Magazine article has the potential reach and encourage more users about the benefits of using a password manager.

Do other platforms include a password manager by default, or do they just have password storage integrated into their browsers already?

Secrets is a nice app and I can see the point that password management is a common requirement. I think that if we were to include it, what I'd want to see is:

  • Integration with our default browser
  • Greater conformity with the GNOME HIG
  • An app vision and roadmap that is in line with what we'd want for a preinstalled Fedora app (ie. are the developers happy to develop an app that is somewhat generic, or are they planning on getting creative with it?)

IMO the weak point of password managers right now is that they either try to emulate a keyboard to enter the passwords which doesn't work on wayland and is generally a bad idea or require apps to have integration for the specific password manager.

So what I would like to see before shipping a password manager that doesn't integrate well with apps is some kind of autofill support.

My $0.02: gnome-keyring is our password manager and apps must use libsecret APIs to access it. Integration with other services like KeePass or Bitwarden would be great as a bonus, but it cannot replace gnome-keyring.

Do other platforms include a password manager by default, or do they just have password storage integrated into their browsers already?

Safari browser integrates with macOS/iOS Keychain which is used as the central local store for all keys and passwords. I'm not sure about Windows and Edge.

Firefox has a built-in password manager. Its storage is encrypted but by default, lacking a primary password set for the user profile, the storage is automatically decrypted. This same storage is synced to the cloud. I'm not seeing a way to add arbitrary information (credit cards, identities, secure notes) like I can with Bitwarden. Also, there's a Bitwarden flatpak on flathub.

Having come from macOS where all passwords, no matter the app, are located in Keychain's database - I like the idea of it being centralized. But in practice, I don't miss it. I prefer the sync to cloud approach anyway, for multiple device support. That too is available with Firefox Sync, the database is cross platform so it's available on Firefox mobile as well.

gnome-keyring's all-or-nothing approach doesn't work with the flatpak security model at all, firefox and chrome don't support it and any kind of synchronization functionality doesn't exist. I wrote a firefox extension for it a few years ago because I really used it. At this point however I would argue that it's one of the most useless things of the entire system.

It would be nice for apps to be able to store secrets encrypted with a key that's derived by the login but that doesn't belong in a password manager.

It would be nice to have an app to store sensitive information such as passwords, credit cards, identities, passkeys but the user must be in control over what other apps have access to.

It would also be nice if I could fill in forms with data from the Contacts app, or credit card details from an app specifically for that. All while being sandboxed. None of that works with the gnome-keyring/libsecret design.

Other operating systems allow you to have password-less logins and fill in forms with information that any app provides and we're stuck in the 90s.

gnome-keyring's all-or-nothing approach doesn't work with the flatpak security model at all,

I'm confused. The secrets portal works fine for flatpaks? And you cannot hide secrets from host apps no matter what, so no point in pretending that it's possible to do that. Not sure what you suggest changing.

firefox and chrome don't support it

But GNOME apps do?

and any kind of synchronization functionality doesn't exist.

I'd like to see native support for password synchronization. In the meantime, you can sync web browser passwords using Firefox Sync via Epiphany. Hardly ideal, though: ideally, you would be able to sync everything using System Settings.

I wrote a firefox extension for it a few years ago because I really used it. At this point however I would argue that it's one of the most useless things of the entire system.

Do you want to type your wi-fi password every time you connect to a wi-fi network? What about your SSH passphrase every time you git push? If that doesn't sound fun then you need gnome-keyring.

It would be possible to replace gnome-keyring with something newer that implements the same libsecret D-Bus APIs, though. Getting rid of libsecret's APIs would be a much bigger undertaking.

It would be nice for apps to be able to store secrets encrypted with a key that's derived by the login but that doesn't belong in a password manager.

I don't understand. A key derived from... the login password? That's similar to how gnome-keyring works currently, right?

It would be nice to have an app to store sensitive information such as passwords, credit cards, identities, passkeys but the user must be in control over what other apps have access to.

I'd like to see it possible to share secrets across different applications, too. For sandboxed apps, this is a bit harder because it's not currently supported by the secrets portal. (Unsandboxed apps will of course always have access to all secrets for all apps no matter what.)

It would also be nice if I could fill in forms with data from the Contacts app, or credit card details from an app specifically for that. All while being sandboxed. None of that works with the gnome-keyring/libsecret design.

Well it doesn't work currently, but I'm not sure you'd need to change anything in gnome-keyring or libsecret to make this possible. I think you'd only need to rework the secrets portal to define some mechanism for sharing across applications.

Additionally, you'd want to define some well-known schemas for storing secrets (contacts, credit cards, whatever) standardized somewhere.

Other operating systems allow you to have password-less logins and fill in forms with information that any app provides and we're stuck in the 90s.

Sadly people have been making the same requests for a long time, but nobody has volunteered to work on it. This seems like something that would be great to improve, though.

Metadata Update from @aday:
- Issue tagged with: meeting

From this discussion, I'm not hearing support to install Secrets by default. If any working group members feel differently, just shout and we can discuss. Otherwise, I think we should probably let this issue go.

Personally I would like to see a better password management story but I'm not sure that's something for the Workstation Working Group.

Metadata Update from @aday:
- Issue untagged with: meeting
- Issue tagged with: default-apps

Nothing much happening here - I think we should close this issue.

Improving the password management story would still be great, but I think we need an integrated solution.

Metadata Update from @aday:
- Issue close_status updated to: Won't fix
- Issue status updated to: Closed (was: Open)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/workstation/tickets/issues/322

Please continue any further discussion there.

Metadata