emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Storing sensitive data indefinitely in variables or buffers: Whether


From: Adam Porter
Subject: Re: Storing sensitive data indefinitely in variables or buffers: Whether and how to fix?
Date: Wed, 31 May 2023 11:39:31 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]