| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
it's possible for different disks to have different encryption passwords
at startup.
In that case, we won't know which one to use, so bail.
https://bugzilla.gnome.org/show_bug.cgi?id=792339
|
| |
|
|
|
|
| |
Code taken almost verbatim from gnome-keyring.
https://bugzilla.gnome.org/show_bug.cgi?id=774776
|
| |
|
|
|
|
|
|
| |
commit bb12416da1f6 tries to make pam_gdm return AUTHINFO_UNAVAIL
if keyutils isn't around, but it inadvertently makes pam_gdm
return AUTHINFO_UNAVAIL when the password is available!
This commit fixes that.
|
| |
|
|
|
|
|
|
| |
right now we return PAM_SUCCESS if keyutils are unavailable.
This is the wrong default, we should fail if we aren't able to
get the password.
https://bugzilla.gnome.org/show_bug.cgi?id=770612
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the user has an encrypted disk then systemd will cache the password
they type into the keyring. It makes sense to try to use this password
for automatic login purposes first, since on single user machines,
the sole user password is likely to match the disk password.
Of course if it doesn't work we'll fall back to the old way of doing
automatic login without a password (and then the user will have to
manualy enter if they need to for gnome-keyring or whatever)
https://bugzilla.gnome.org/show_bug.cgi?id=769950
|
|
|
It doesn't do anything yet, but it will eventually get used for
autologin purposes, and maybe other things.
https://bugzilla.gnome.org/show_bug.cgi?id=769950
|
