On Tue, 25 Apr 2023 at 07:52, Gustavo Barros <gusbrs.2...@gmail.com> wrote:
> My view is that there really should be a way of doing it. Because this
> has relevant security implications. And because users should be able
> to have control of their data in the first place. And then if one such
> a feature, necessarily requiring persistence (as opposed to the
> convenience of "just" speeding things up), a user-error could be
> signaled saying "sorry, can't do that because you disabled
> persistence". And the two cases you mentioned seem quite the exception
> to me. Of course, I'm speaking here about writing information about /
> of the org file itself to an external file, naturally internet
> downloads must go somewhere and that should be easy. The thing is Org
> is used for a lot of things. You can rest assured I have no intention
> of exporting my encrypted files alongside some remote content. But I
> do wish to be able to make sure my passwords are safe.
For the record, even ".org.gpg" files generate an entry in the cache
index. (True, not the `:persist-file' itself though).
My ~/.cache/org-persist/index contains:
(:container
((elisp org-element--headline-cache)
(elisp org-element--cache))
:persist-file "c8/fd2b62-45cc-41c8-8571-d944c76b1f15" :associated
(:hash "7fd2d95e0f9239939598e7a9b8d5a273" :file
"/path/to/myfile.org.gpg" :inode 41551881)
:expiry 30)
Please, please, be reasonable about this. Please, do not store
information about known encrypted files in other places. Please, allow
users to disable the feature cleanly and safely for arbitrary files if
they choose to.
Best,
Gustavo.
