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

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

[Jens Schmidt]

This is related to

   https://lists.gnu.org/archive/html/emacs-devel/2023-05/msg00327.html

and bug#63627 I've opened to track progress.

plstore.el stores clear-text sensitive data in a number of places in a
running emacs without automatically expiring it as, for example,
password-cache does.

1. As usually, fixing these decreases convenience.  Is that OK?

2. Is fixing these considered a bug (relevant for emacs-29) even if it
    involves a bit more effort, possibly even new functions and
    variables?

Thanks.

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

[Ihor Radchenko]

Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:

> plstore.el stores clear-text sensitive data in a number of places in a
> running emacs without automatically expiring it as, for example,
> password-cache does.

To add on the issue, we had a somewhat similar problem related to
org-persist library that stores cached data.

https://list.orgmode.org/orgmode/CAM9ALR8fuSu0YWS1SehRw7sYxprJFX-r2juXd_DgvCYVKQc95Q@mail.gmail.com/

Within that thread, a concern have been raised about storing data
related to files from encrypted file system. Even the file names (for
example, stored by recentf) from encrypted FS may be considered
sensitive if they are stored as plain text.

I have considered two approaches there:
1. Expiry, when the data may persist within Emacs session, but is never
   written on disk.
2. Encrypting the stored data (similar to .authinfo.gpg)

> 1. As usually, fixing these decreases convenience.  Is that OK?

IMHO, at least some people are extremely sensitive about storing
sensitive data in plain text. I'd say that it is better to avoid storing
sensitive data in plain text by default. Possibly, with a toggle to
enable such risky storage for users who know what they are doing.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> Date: Tue, 30 May 2023 23:25:32 +0200
> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> 
> plstore.el stores clear-text sensitive data in a number of places in a
> running emacs without automatically expiring it as, for example,
> password-cache does.
> 
> 1. As usually, fixing these decreases convenience.  Is that OK?

In general, if the inconvenience is significant, it is best to make
the feature opt-in.  Even if we do make it ON by default, there should
be a way of getting back old behavior, and that way should be
documented in NEWS.

> 2. Is fixing these considered a bug (relevant for emacs-29) even if it
>     involves a bit more effort, possibly even new functions and
>     variables?

No, this is not a "bugfix" in terms applicable to the emacs-29 branch.
These changes should go to master.

Thanks.

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

[Adam Porter]

I've recently been thinking about similar issues.  In Ement.el, it's 
necessary to store a session token, which is used upon next connection 
to prevent having to log in with a password again (the Matrix protocol 
does not intend for users to re-enter their password on each 
connection).  For now, the token is stored in a plain-text file with 
permissions set securely, but obviously it would be good for the token 
to be encrypted at rest.

I once attempted to use the auth-source library to store it, but due to 
numerous problems[0], I gave up on that idea.

Since then we've gained the `persist' and `multisession' libraries, 
which seem like good tools, but neither one offers secure storage.

I think Emacs needs a new library to store Lisp data securely.  Ideally 
the API would simply return a Lisp object which could be used with 
common functions like alist-get, gethash, etc. to read data.  For 
writing, perhaps some kind of simple macro or function wrapper that 
would store the data securely, as-configured, without the application 
needing to know the details.

Even more ideally, such a feature would be part of `persist' and/or 
`multisession', or at least be built on top of them, to avoid having 
yet-another data-persistence library.

(I also hope we can figure out the situation with regard to having both 
`persist' and `multisession' now; I asked[1] last month, but the 
discussion didn't proceed very far.)

Does anyone else have thoughts about this?

Thanks,
Adam

0: 
https://old.reddit.com/r/emacs/comments/8lvda6/is_authsource_from_the_dark_side/
1: https://lists.gnu.org/archive/html/emacs-devel/2023-04/msg00269.html

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On Wed, May 31, 2023 at 11:39:31AM -0500, Adam Porter wrote:

[...]

> Since then we've gained the `persist' and `multisession' libraries, which
> seem like good tools, but neither one offers secure storage.
> 
> I think Emacs needs a new library to store Lisp data securely.  Ideally the
> API would simply return a Lisp object which could be used with common
> functions like alist-get, gethash, etc. to read data.  For writing, perhaps
> some kind of simple macro or function wrapper that would store the data
> securely, as-configured, without the application needing to know the
> details.
> 
> Even more ideally, such a feature would be part of `persist' and/or
> `multisession', or at least be built on top of them, to avoid having
> yet-another data-persistence library.

This sounds enticing from a technical POV. OTOH, I'm a bit wary of a
big intransparent cache dump.

I'm already wrangling with Org caching (for now, my sweet spot
seems to be directing it to a non-existing directory and ignoring
the complaints: paradoxically, Emacs is snappier then).

I'd hate to end up with a setup like the monster browsers have
these days: an obscure set of sqlite databases you need a huge
amount of dedication to extract some slivers of information from.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Eli Zaretskii]

> Date: Wed, 31 May 2023 11:39:31 -0500
> Cc: emacs-devel@gnu.org, jschmidt4gnu@vodafonemail.de
> From: Adam Porter <adam@alphapapa.net>
> 
> I think Emacs needs a new library to store Lisp data securely.

Can't we use the GnuTLS cryptography functions, like
gnutls-symmetric-encrypt, for that?

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

[Jens Schmidt]

On 2023-05-31  18:39, Adam Porter wrote:

> I think Emacs needs a new library to store Lisp data securely. 
> Ideally the API would simply return a Lisp object which could be
> used with common functions like alist-get, gethash, etc. to read
> data. For writing, perhaps some kind of simple macro or function
> wrapper that would store the data securely, as-configured, without
> the application needing to know the details.

Er, that's what I thought plstore.el is about: Persisting sensitive and 
non-sensitive data in a structured way, securely, with on-demand 
decryption.  It certainly has rough edges, and almost no UI at all, but 
I liked the basic idea.  See so far

   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63627

and

   https://lists.gnu.org/archive/html/emacs-devel/2023-05/msg00327.html

> Even more ideally, such a feature would be part of `persist' and/or 
> `multisession', or at least be built on top of them, to avoid having 
> yet-another data-persistence library.

That would make three persistence solutions, then, which is still less 
than 15 (https://xkcd.com/927).  I haven't checked 'persist' nor 
'multisession' yet, TBH.

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

[Ihor Radchenko]

<tomas@tuxteam.de> writes:

> I'm already wrangling with Org caching (for now, my sweet spot
> seems to be directing it to a non-existing directory and ignoring
> the complaints: paradoxically, Emacs is snappier then).

You will hit an error, sooner or later. We are going to use cache in more
scenarios.

If your Emacs is snappier without cache, you likely experience slowdowns
on long sessions. If so, it is another problem you are just postponing.

> I'd hate to end up with a setup like the monster browsers have
> these days: an obscure set of sqlite databases you need a huge
> amount of dedication to extract some slivers of information from.

I am sure we will not.

For multi-session, it is up to you whether to store information in
SQLite database or in plain text files. The default for
`multisession-storage' is 'files. I doubt that we are going to change
this default in the nearest dozen of years (It is Emacs after all :])

For org-persist, it is designed to store disposable information that can
be re-generated any time. Even then, org-persist tries to keep the
index.eln human-readable.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Ihor Radchenko]

Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:

> On 2023-05-31  18:39, Adam Porter wrote:
>
>> I think Emacs needs a new library to store Lisp data securely. 
>> Ideally the API would simply return a Lisp object which could be
>> used with common functions like alist-get, gethash, etc. to read
>> data. For writing, perhaps some kind of simple macro or function
>> wrapper that would store the data securely, as-configured, without
>> the application needing to know the details.
>
> Er, that's what I thought plstore.el is about: Persisting sensitive and 
> non-sensitive data in a structured way, securely, with on-demand 
> decryption.  It certainly has rough edges, and almost no UI at all, but 
> I liked the basic idea.

AFAIK, Adam had a very hard time dealing with auth-source.el. See the
reddit link in his message.

AFAIR, part of the problem was (1) poor documentation; (2) various edge
cases that had to be considered; (3) complex code required to make
things work. So, here he is asking for a _simple_ API that does not
require too much of tinkering with the internals. If such API is added
to plstore, it will certainly be great.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think Emacs needs a new library to store Lisp data securely.
>
> Can't we use the GnuTLS cryptography functions, like
> gnutls-symmetric-encrypt, for that?

I think that it is not just about encryption.
The API should also have ways to expire passwords and deal with a need
to update them individually.

multisession.el, AFAIU, only allows storing symbol values and the
smallest piece of data. But one cannot always dedicate a separate
variable symbol for each password or secret. An alist of (HOST .
PASSWORD) often needs to be stored with each HOST having dedicated rules
about expiry.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

On Thu, Jun 01, 2023 at 06:34:51AM +0000, Ihor Radchenko wrote:
> <tomas@tuxteam.de> writes:
> 
> > I'm already wrangling with Org caching (for now, my sweet spot
> > seems to be directing it to a non-existing directory and ignoring
> > the complaints: paradoxically, Emacs is snappier then).
> 
> You will hit an error, sooner or later. We are going to use cache in more
> scenarios.

I get to keep both parts, I know. I'd definitely prefer an official
switch, but with no code to offer I won't even dare to complain :)

> If your Emacs is snappier without cache, you likely experience slowdowns
> on long sessions. If so, it is another problem you are just postponing.

Actually not. Rather around the start. If interested, I can try
to provide data. But I won't bother people with it without a
request.

> > I'd hate to end up with a setup like the monster browsers have
> > these days: an obscure set of sqlite databases you need a huge
> > amount of dedication to extract some slivers of information from.
> 
> I am sure we will not.
> 
> For multi-session, it is up to you whether to store information in
> SQLite database or in plain text files. The default for
> `multisession-storage' is 'files. I doubt that we are going to change
> this default in the nearest dozen of years (It is Emacs after all :])

It is not specifically about SQLite...

> For org-persist, it is designed to store disposable information that can
> be re-generated any time. Even then, org-persist tries to keep the
> index.eln human-readable.

...but about complexity. Having a generic cache which works for all
applications will make the code (application code and cache data)
necessarily more inscrutable. OTOH, every little application doing
its own thing is problematic in its own way. As an engineer, you
seldom win ;-)

Please, don't take my complaints all too seriously. You are doing
a huge work; although I don't always like the direction taken, I
do admire what you're doing. I feel free to fat-finger it strategically
here and there to fit my needs :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Ihor Radchenko]

tomas@tuxteam.de writes:

>> You will hit an error, sooner or later. We are going to use cache in more
>> scenarios.
>
> I get to keep both parts, I know. I'd definitely prefer an official
> switch, but with no code to offer I won't even dare to complain :)

Maybe `org-element-cache-persistent' is enough for your needs?
This specific part can be disabled. The problem is rather with caching
previews and remote images - we previously had to rely on
`org-preview-latex-image-directory' and similar case-by-case approaches,
but aim to centralize cache storage into unified API.

>> If your Emacs is snappier without cache, you likely experience slowdowns
>> on long sessions. If so, it is another problem you are just postponing.
>
> Actually not. Rather around the start. If interested, I can try
> to provide data. But I won't bother people with it without a
> request.

If you are seeing "Reading from ... took ...sec", it may be either disk
reading speed (unlikely) or older Emacs where `read' was less optimized.

>> > I'd hate to end up with a setup like the monster browsers have
>> > these days: an obscure set of sqlite databases you need a huge
>> > amount of dedication to extract some slivers of information from.
>> 
>> I am sure we will not.
>> 
>> For multi-session, it is up to you whether to store information in
>> SQLite database or in plain text files. The default for
>> `multisession-storage' is 'files. I doubt that we are going to change
>> this default in the nearest dozen of years (It is Emacs after all :])
>
> It is not specifically about SQLite...

Well. The current de facto situation is scattered files in your
.emacs.d. Not sure how it is better.

>> For org-persist, it is designed to store disposable information that can
>> be re-generated any time. Even then, org-persist tries to keep the
>> index.eln human-readable.
>
> ...but about complexity. Having a generic cache which works for all
> applications will make the code (application code and cache data)
> necessarily more inscrutable. OTOH, every little application doing
> its own thing is problematic in its own way. As an engineer, you
> seldom win ;-)

Not sure here. I'd rather say that the situation is an opposite.
Have you looked inside index.eln created by org-persist? It is not far
from how automatically generated `custom-set-variables' reads.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Adam Porter <adam@alphapapa.net>, emacs-devel@gnu.org,
>  jschmidt4gnu@vodafonemail.de
> Date: Thu, 01 Jun 2023 06:48:51 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I think Emacs needs a new library to store Lisp data securely.
> >
> > Can't we use the GnuTLS cryptography functions, like
> > gnutls-symmetric-encrypt, for that?
> 
> I think that it is not just about encryption.
> The API should also have ways to expire passwords and deal with a need
> to update them individually.

What would be the effect of expiring a password on stuff stored using
the password that just expired? would it mean I can no longer access
that stuff?  Or would it mean I must use a new password for storing
new stuff?  Or something else?

In any case, implementing some machinery for managing and expiring
passwords is relatively easy.  Cryptography, by contrast, is hard, so
we should use industry-strength implementations by experts for that,
and I think GnuTLS is a good candidate for that part, especially since
Emacs without GnuTLS is severely limited anyway (so we could assume
"almost everyone" have it).

> multisession.el, AFAIU, only allows storing symbol values and the
> smallest piece of data. But one cannot always dedicate a separate
> variable symbol for each password or secret. An alist of (HOST .
> PASSWORD) often needs to be stored with each HOST having dedicated rules
> about expiry.

You are AFAU talking about application layers about 2 levels above
what I was thinking about.  Before we discuss all those
application-level issues, we should decide how to store stuff
securely, and that AFAIU means some kind of encryption.  Which is why
I mentioned GnuTLS and its abilities exposed to Emacs Lisp.

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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think that it is not just about encryption.
>> The API should also have ways to expire passwords and deal with a need
>> to update them individually.
>
> What would be the effect of expiring a password on stuff stored using
> the password that just expired? would it mean I can no longer access
> that stuff?  Or would it mean I must use a new password for storing
> new stuff?  Or something else?

From API point of view, there should be a simple way to (1) retrieve
encrypted data, if unexpired; (2) retrieve expired encrypted data; (3)
get information if the data is expired or not.

> In any case, implementing some machinery for managing and expiring
> passwords is relatively easy.

Of course, it is easy to implement. Just wanted to raise the need to
have expiration.

> ...  Cryptography, by contrast, is hard, so
> we should use industry-strength implementations by experts for that,
> and I think GnuTLS is a good candidate for that part, especially since
> Emacs without GnuTLS is severely limited anyway (so we could assume
> "almost everyone" have it).

I agree.
Is Emacs built with GnuTLS support by default?

Another question about encryption is which secret should be used?
Should it be configurable by users? Should it be the same for the whole
secure storage? More granular? May encryption be disabled by users?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: adam@alphapapa.net, emacs-devel@gnu.org, jschmidt4gnu@vodafonemail.de
> Date: Thu, 01 Jun 2023 07:29:55 +0000
> 
> > ...  Cryptography, by contrast, is hard, so
> > we should use industry-strength implementations by experts for that,
> > and I think GnuTLS is a good candidate for that part, especially since
> > Emacs without GnuTLS is severely limited anyway (so we could assume
> > "almost everyone" have it).
> 
> I agree.
> Is Emacs built with GnuTLS support by default?

GnuTLS will be compiled in by default if it's available, yes.

> Another question about encryption is which secret should be used?
> Should it be configurable by users? Should it be the same for the whole
> secure storage? More granular? May encryption be disabled by users?

This should probably be controlled by some user option.

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On Thu, Jun 01, 2023 at 10:11:57AM +0300, Eli Zaretskii wrote:
> > From: Ihor Radchenko <yantar92@posteo.net>
> > Cc: Adam Porter <adam@alphapapa.net>, emacs-devel@gnu.org,
> >  jschmidt4gnu@vodafonemail.de
> > Date: Thu, 01 Jun 2023 06:48:51 +0000
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > >> I think Emacs needs a new library to store Lisp data securely.
> > >
> > > Can't we use the GnuTLS cryptography functions, like
> > > gnutls-symmetric-encrypt, for that?
> > 
> > I think that it is not just about encryption.
> > The API should also have ways to expire passwords and deal with a need
> > to update them individually.
> 
> What would be the effect of expiring a password on stuff stored using
> the password that just expired? would it mean I can no longer access
> that stuff?  Or would it mean I must use a new password for storing
> new stuff?  Or something else?

This might be a slight misunderstanding: if I understand Ihor correctly,
only the cached password is expired, so the user would have just to
reenter it. This is to mitigate the risk that someone else takes over
an abandoned session (a mild form of user presence check, if you will).

If I understand you correctly, you seem to envision the expiry of the
password itself, which is something different, to happen at the "server"
side.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Jens Schmidt]

On 2023-06-01  08:42, Ihor Radchenko wrote:

> AFAIK, Adam had a very hard time dealing with auth-source.el. See the
> reddit link in his message.

Did that.  However, it is my understanding that auth-source is an
abstraction for credential retrieving (".netrc 3.0"), while plstore is a
generic persistence library.  I'm targeting plstore.

> AFAIR, part of the problem was (1) poor documentation; (2) various 
> edge cases that had to be considered; (3) complex code required to 
> make things work. So, here he is asking for a _simple_ API that does 
> not require too much of tinkering with the internals. If such API is 
> added to plstore, it will certainly be great.

The API is available and IMHO sufficiently simple, but issues (1) and
(2) are surely present in plstore.  Plus it does not handle expiry in
any way.  Will do my best to do something about all these, keeping the
results of this thread in mind.

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

[Adam Porter]

Thanks to all for the discussion on this thread.

IMHO expiry is an orthogonal issue to, at least, the kind of backend 
data storage/retrieval library I'm asking for.  I think it should be up 
to the application to prune the data according to its needs.  The 
storage API should simply save and return data to the application.  So 
if the application wants to expire some data, it should retrieve the 
collection, discard elements it doesn't need anymore, and rewrite the 
collection using the library's API.

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.

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?

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

[Adam Porter]

On 6/2/23 01:30, Eli Zaretskii wrote:
>> 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?

I don't mean that it should be an alist specifically.  I mean that I'd 
just like to get/put a Lisp object, which I could then use with standard 
Lisp functions like alist-get, plist-get, gethash, as well as map-elt, 
and setf wrappers for setting, etc.

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

[Eli Zaretskii]

> Date: Sun, 4 Jun 2023 18:47:07 -0500
> Cc: jschmidt4gnu@vodafonemail.de, emacs-devel@gnu.org, yantar92@posteo.net
> From: Adam Porter <adam@alphapapa.net>
> 
> > 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?
> 
> I don't mean that it should be an alist specifically.  I mean that I'd 
> just like to get/put a Lisp object, which I could then use with standard 
> Lisp functions like alist-get, plist-get, gethash, as well as map-elt, 
> and setf wrappers for setting, etc.

And I ask again: what's the problem of using plstore-get etc. instead?
why does it have to be "standard Lisp functions"?