Open Bug 1527745 Opened 5 years ago Updated 1 year ago

Implement OS re-authentication on Linux (Gnome Keyring)

Categories

(Core :: Security: PSM, enhancement, P4)

All
Linux
enhancement

Tracking

()

People

(Reporter: MattN, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [cc-autofill-reserve])

Filing this to track the blocker to shipping credit card storage. It seems like we may have to settle with locking the keystore at the OS level.

Blocks: 1527746

We would like to initially narrow it down and only implement it for Gnome Keyring.

Summary: Implement OS re-authentication on Linux → Implement OS re-authentication on Linux (Gnome Keyring)
Priority: P3 → P2
Whiteboard: [cc-autofill-mvp]
Priority: P2 → P3
Priority: P3 → P4
Whiteboard: [cc-autofill-mvp] → [cc-autofill-reserve]

Years ago, our strategy for how to accomplish a "check that the user can enter the account credential" was to use gnome-keyring's gnome_keyring_lock and gnome_keyring_unlock with an auxiliary keyring only used for this purpose. For whatever reason, three years ago, we could only use lock_all, perhaps because the specific lock didn't exist, or we couldn't programmatically construct a keyring. I don't recall which was the problem.

This lock/unlock is just a roundabout way to get to what we actually want: a boolean of whether the user is able to reauthenticate. If they can't, we actually don't want to lose access to the data we're using with libsecret, or at least we want to be very careful with what secret(s) we lose access to. On MacOS and Windows we have that capability, of getting authentication without actually locking.

You need to log in before you can comment on or make changes to this bug.