bug#36834: 27.0.50; [PATCH] password-cache.el: confuses key absence with nil password

[Eli Zaretskii <eliz@gnu.org>]

Ping!  Any followups?  Stefan?  Should we just push this?

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 29 Jul 2019 16:12:45 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 36834@debbugs.gnu.org
> 
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
> 
> >> The change uses gethash instead of intern-soft, but those functions act
> >> differently when the password (the value associated with the key) was
> >> nil.
> >
> > Is it valid for the password to be nil?  The logic in password-read
> > suggests otherwise.
> 
> Callers are sending nil. If it is not valid, there is a problem
> elsewhere, but my understanding is that a nil password means "no
> password" and it is cached in the memoization sense.
> 
> >> The effect is that every call to password-cache-add with nil as
> >> password creates a new timer,
> >
> > Where is password-cache-add being passed a nil password?
> 
> The caller is auth-source-remember, IIRC, which itself is called from
> auth-source-search.

Can you show a reproducer?