The dotfiles repo does NOT contain any SDDM, PAM, mkinitcpio, bootloader, or KWallet configuration. All of those are system-level files managed outside this repo.
/etc/pam.d/sddm — replace pam_kwallet5.so references with pam_kwallet6.so in auth and session stacks
/etc/pam.d/sddm-autologin — same replacement if autologin is also desired
~/.config/kwalletrc — create/configure wallet to use blowfish or GPG encryption; set wallet name
Initialize wallet — run kwalletd6 or use kwallet-query to create the default wallet with the user's login password as the unlock password
To configure SDDM for Wayland session (currently X11 default)
/etc/sddm.conf.d/hyprland.conf (new file) — set DisplayServer=wayland or leave X11 and use Wayland session via wayland-session script
To configure SDDM autologin (Option A)
/etc/sddm.conf.d/autologin.conf (new file) — set User=alex, Session=hyprland
To track these system files in the dotfiles repo
Add symlinks or a deploy script — system PAM files are outside the current dotfiles scope
Risks and ambiguities
[risk] pam_kwallet5.so vs pam_kwallet6.so mismatch: PAM files reference kwallet5 module; installed binary is kwalletd6. The kwallet-pam package for KF6 provides pam_kwallet6.so — this must be installed from AUR or a compatible repo.
[risk] No KDE Plasma installed: The system uses Hyprland, not Plasma. KWallet works standalone, but Plasma's system tray integration for wallet prompts won't be present. Apps must use the KWallet D-Bus API directly.
[risk] SDDM running X11 compositor by default: The default.conf has DisplayServer=x11, but the user session is Hyprland (Wayland). SDDM itself can still launch Wayland sessions from an X11 greeter. This works but is a mismatch worth documenting.
[risk] autologin + KWallet security trade-off: If autologin is used (Option A), KWallet cannot be unlocked by the user password (there is none at login). The wallet would need to be set to "no password" (plaintext) or use a keyfile — both reduce security.
[risk] pam_u2f.so at top of system-login and sddm: U2F is configured as sufficient — meaning a hardware key can bypass password entirely. This could bypass KWallet unlock if the wallet password differs from the user password.
[risk] hyprlock uses auth include login: The lock screen delegates to the login PAM chain, which does NOT include kwallet PAM modules. Unlocking hyprlock will NOT re-open the wallet.
[risk] Dotfiles repo scope boundary: /etc/pam.d/, /etc/sddm.conf.d/, /etc/mkinitcpio.conf, and /boot/loader/ are all outside the dotfiles repo. These are system files. Either the dotfiles repo needs to expand its scope (with a deploy script), or these changes must be managed separately.
[risk] mkinitcpio uses classic encrypt hook, not sd-encrypt: The sd-encrypt (systemd) hook supports TPM2/FIDO2-bound LUKS keys for automatic unlock; the classic encrypt hook does not. If the goal involves TPM2-bound auto-unlock (true single-passphrase boot), migration to sd-encrypt would be required.
[ambiguity] "SDDM login" with LUKS: LUKS unlock happens at boot (initramfs), before SDDM. There is no mechanism for SDDM to "reuse" the LUKS passphrase directly. The integration point is: user types the same password at SDDM → PAM propagates it to pam_kwallet6 → wallet unlocked. The LUKS and SDDM passwords are independent unless deliberately set to the same value.