Philip Martin wrote: > I can fix kwallet with this patch: [...]
Great. Without the patch: * Non-interactive commands will not try to authenticate from the kwallet, and instead attempt the next authentication method which will typically fail, leaving the user puzzled because the same command works fine without the '--non-interactive' option. With the patch: * Non-interactive commands will now simply work as they should, if the Kwallet is unlocked. * Non-interactive commands will throw an error, if locked. * Brings kwallet to the same behaviour as Gnome keyring. * But there are still some inconsistencies between neon/serf, and gnome/kde, w.r.t. whether it returns an error if locked or quietly goes on to try the next authn method. > However I am worried about the TOCTOU race. [...] So, there's a chance that a "Please unlock the keyring" GUI window will pop up, if the kwallet is configured to time out and happens to time out during the window of opportunity, or if some other process explicitly locks it during that same window. But that doesn't sound like a grave problem to me. Sure there are some scenarios where a hanging window is a problem, and if and when it happens it will be a surprise which is not nice. But if someone uses this on an unattended machine they need to ensure the keyring won't time out, or they won't get very far anyway. The same is already true for Gnome keyring. Seems like this fix is a big improvement already, and even better if we can make it more consistent with the Gnome-keyring behaviour. If we care about the races, we can see about fixing them later, if there is any feasible way to do so. - Julian
