Bug 2356892

Summary:	Fedora 42 beta: Keyring password not set after configuring username and password in setup window
Product:	[Fedora] Fedora	Reporter:	Alexandru Cheltuitor <calexandru.dev>
Component:	gnome-keyring	Assignee:	Matthias Clasen <mclasen>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	42	CC:	awilliam, calexandru.dev, christopher, debarshir, do.siekierskipd, gnome-sig, mclasen, ndegraef, robatino, rstrode, stefw, walters
Target Milestone:	---	Keywords:	Desktop, Regression
Target Release:	---
Hardware:	x86_64
OS:	Linux
URL:	https://ibb.co/Sw31BMHS
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-04-02 22:27:28 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2291265

Description Alexandru Cheltuitor 2025-04-02 11:06:04 UTC

After installing the distribution, restarting the distro and finishing the setup, I installed seahorse (Password & Keys) and noted that the default "Login" keyring is locked (usually it's unlocked after logging in). This shouldn't be the case since auto-login is not enabled and I have set a user password to "test" (I also confirmed that auto-login is disabled). Upon pressing on unlock I'm greeted with an error message saying the password is incorrect. I'm also unable to reset the password of the keyring since I don't know what password was used for the keyring.

This basically prevents any application from using the keyring since it's locked. For example, the Proton VPN app for F42 is unusable at this point since it requires keyring access to login into the application as it stores data there.

I've used the the image Fedora-Workstation-Live-42_Beta-1.4.x86_64.iso and installed it in a VM. All updates have been installed prior to doing this test.

Reproducible: Always

Steps to Reproduce:
1. Download beta image (Fedora-Workstation-Live-42_Beta-1.4.x86_64.iso was used in this case)
2. Install the distro in VM (used Boxes). I didn't setup encryption and used the entire disk. Allocated 8 CPUS, 20GiB of storage and 4GiB of RAM. All other values are on default values.
3. Wait until the distro installation is done, remove media and reboot VM
4. Proceed with last setup steps by providing the username and password (other options such as locations and such didn't matter much). Ensured that password were the same and correct by clicking on the eye icon
5. Update packages with sudo dnf upgrade -y
6. Install seahorse sudo dnf install seahorse
7. Launch seahorse and note that default "Login" keyring is locked
8. Click on "Unlock"
9. Type in user password

Actual Results:
1) The keyring is locked even after login
2) The keyring apparently has a different password from the user password, as it's impossible to unlock it with the user password that was set to "test"

Expected Results:
1) The keyring should be unlocked upon login
2) The keyring should have the same password as the user password

During installation I changed the keyboard to PT-nodeadkeys, although I don't think this should matter since I double-checked that the user password was set correctly to "test".

Comment 1 Fedora Blocker Bugs Application 2025-04-02 11:27:09 UTC

Proposed as a Blocker for 42-final by Fedora user calexandru2018 using the blocker tracking app because:

 Apps that depend on keyring won't be able to be used due to this keyring bug, as the keyring password is not the same as the user password for some reason, thus users won't be able to use this transparently as it will require the user manually delete the keyring and create a new one.

Comment 2 Christopher Boni 2025-04-02 15:53:50 UTC

Have you upgraded your system after install? I'm certain this bug was resolved with an update this update: https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a35898dbf

Comment 3 Alexandru Cheltuitor 2025-04-02 15:56:46 UTC

(In reply to Christopher Boni from comment #2)
> Have you upgraded your system after install? I'm certain this bug was
> resolved with an update this update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a35898dbf

As I've mentioned in the steps to reproduce, the first thing I did after installing the VM was to run `sudo dnf upgrade`, unless you mean `dist-upgrade` then no, I haven't done that.

Comment 4 Adam Williamson 2025-04-02 19:10:38 UTC

Can you try with a current nightly and see if you can reproduce it? https://openqa.fedoraproject.org/nightlies.html

Comment 5 Alexandru Cheltuitor 2025-04-02 22:09:55 UTC

(In reply to Adam Williamson from comment #4)
> Can you try with a current nightly and see if you can reproduce it?
> https://openqa.fedoraproject.org/nightlies.html

I've tried on https://kojipkgs.fedoraproject.org/compose/branched/Fedora-42-20250402.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-42-20250402.n.0.iso and yes the issue if fixed. Sorry for the extra noise.

Comment 6 Adam Williamson 2025-04-02 22:27:28 UTC

Thanks for confirming!

*** This bug has been marked as a duplicate of bug 2349314 ***

Comment 7 do.siekierskipd 2025-04-06 14:38:08 UTC

I have the same issue. I installed Fedora 42 Workstation Beta and ran an update. Should I reinstall the system from scratch, or will this change eventually come through, and everything will be fixed after an update?

Comment 8 Adam Williamson 2025-04-09 22:54:54 UTC

The update will eventually come through (in fact you should have it already), but if this is caused by something bad happening *at first install / boot time* and it's persistent, the update won't necessarily fix it. You might want/need to reinstall with a recent nightly or the release candidate.