Re: Storing sensitive data indefinitely in variables or buffers: Whether and how to fix?

[Eli Zaretskii]

> Date: Thu, 1 Jun 2023 15:47:39 -0500
> Cc: adam@alphapapa.net, emacs-devel@gnu.org, yantar92@posteo.net
> From: Adam Porter <adam@alphapapa.net>
> 
> plstore looks like an interesting library, but even that looks like more 
> than the simple solution I'm wishing for.  I'm not sure that, as an 
> application author, I should need to care about which keys in a record 
> are encrypted or not.  I just want to do something simple and Lispy, like:
> 
>    (alist-get "@alphapapa:matrix.org" (secure-storage 'ement-sessions))
> 
> To get my Matrix session's data.  Or:
> 
>    (map-nested-elt (secure-storage 'ement-sessions) 
> '("@alphapapa:matrix.org" token))
> 
> to get that session's token.  And then:
> 
>    (setf (map-nested-elt (secure-storage 'ement-sessions) 
> '("@alphapapa:matrix.org" token)) "foobarbaz")
> 
> to write the data to the secure storage.  And then the secure-storage 
> library should automatically handle the encryption/decryption, 
> filesystem location, backend format, prompting the user for a key and/or 
> caching it appropriately, etc.
> 
> I think this is the simplest kind of API that could be useful to 
> applications--and it would be really useful.

I see no problems implementing such a simple API on top of plstore.el.
But I don't really understand why you would care to use alist-get
instead of, say, plstore-get.  Why does it matter whether the storage
is presented as an alist or as an opaque storage with accessor and
setter?