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

Previous Next

Package: emacs;

Reported by: Óscar Fuentes <ofv <at> wanadoo.es>

Date: Mon, 29 Jul 2019 05:13:01 UTC

Severity: normal

Tags: patch

Found in version 27.0.50

Done: Óscar Fuentes <ofv <at> wanadoo.es>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 36834 <at> debbugs.gnu.org (full text, mbox):

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 36834 <at> debbugs.gnu.org
Subject: Re: bug#36834: 27.0.50; [PATCH] password-cache.el: confuses key
 absence with nil password
Date: Mon, 29 Jul 2019 16:12:45 +0200
"Basil L. Contovounesios" <contovob <at> 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.

>> and password-in-cache-p returns nil if
>> there exists a (key nil) entry on password-data, when previously it
>> would return non-nil.
>
> I think a nil key is also not expected.

(key nil) means a hash table entry with `key' as key and nil as value,
not that key is nil.

> Note that password-in-cache-p is currently identical to
> password-read-from-cache.  One can probably be written in terms of the
> other.

Yes, right now they are identical, which causes a problem, because
checking for key existence shall not be the same as retrieving the value
when value can be nil.

> Even if these "memhash" checks are TRT, I suggest either reusing or
> copying the hash table method of map-contains-key, rather than comparing
> against an interned symbol.

Is map-contains-key available by default? I'm wary of introducing new
dependencies for saving just a few characters.





This bug report was last modified 5 years and 287 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.