emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Daniel Clemente <n142857@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-orgmode@gnu.org
Subject: Re: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options)
Date: Tue, 2 Jul 2024 16:53:33 +0000	[thread overview]
Message-ID: <CAJKAhPDtbrW01WSLTnT=CeqMuyDMvnSPehf2StV-kMUTXoerSg@mail.gmail.com> (raw)
In-Reply-To: <87le2qy8ri.fsf@localhost>

> > In addition, „leaving some encrypted sections unencrypted for a short
> > amount of time, and closing and reopening the buffer during that time“
> > isn't a bug, it's a possible user behaviour that we can't control. But
> > org-crypt can mention that that behaviour is unsafe when using on-disk
> > cache. Or detect it (if it's fast) and warn the user.
>
> I did not mean that opening/closing buffer is a bug.
> And I do not see why this behavior is unsafe, sorry.
>

Closing a buffer is unsafe when this happens at the same time:
1. you have org-element-cache-persistent set to t (the default)
2. you're using org-crypt and have temporarily decrypted a region but
for some reason not reencrypted yet (maybe you plan to reencrypt it
some hours later today)
3. the cache directory is in a place which is not as private as the
org file. E.g. a network disk, an unencrypted hard drive etc.

It's unsafe because closing the buffer triggers saving the org-element
cache to disk.

> >
> > Disabling backups makes sense too, if we decide that unencrypted
> > private data shouldn't end up in backups.
> > I don't have an absolute opinion. Some people may prefer having
> > backups of all data (including private unencrypted data).
>
> Actually, thinking about it more, I realize that backups may never
> contain unencrypted data as long as we never write this unencrypted data
> when saving normally. That's because backup is always taken from disk
> and never from the buffer contents.
>
> So, the real problem to solve is how to _reliably_ prevent the
> unencrypted data to be saved onto the disk.
>

If that works, that's good.


> > If it's possible to detect whether encryption failed in this buffer,
> > there could be a warning saying „Last encryption failed. Really
> > save?“.
>
> Yes. In fact, `org-entrypt-entries' throws an error when encryption
> fails. However, this error is displayed as a simple message, which is
> immediately hidden by "Wrote ..." message emitted a bit later.
>
> This is because `basic-save-buffer' has
>
> ;; Don't let errors prevent saving the buffer.
> (with-demoted-errors "Before-save hook error: %S"
>   (run-hooks 'before-save-hook))
>
> If we use `write-contents-functions' instead of `before-save-hook',
> there should be no such problem.
>

It seems so.
But can you also prevent auto-save from saving it?
I randomly found in tar-mode.el line 860 that auto-save doesn't call
the write-contents-functions hook.


> What I am saying is that "we might have bugs, so be careful" is not
> something we need to write in the documentation. The only exception is
> when there is a known, long-living bug, that we cannot fix quickly and
> must warn users about.
>

The needed message isn't „we might have bugs, so be careful“
… but „if for some reason you keep org-crypt sections unencrypted for
long periods of time, be careful“.
That situation may come from user behaviour (e.g. not having enabled
org-crypt-use-before-save-magic), not from bugs.



> > It would be different If we had a third component… E.g. imagine we had
> > a component/overlay/text property/… in Emacs that could tell whether a
> > buffer's region contains very private information or not; then all
> > other components could just obey that setting (that section won't be
> > backed up, it won't end up in disk cache, … It can even be displayed
> > in a different face). Then org-crypt just needs to set that flag when
> > encryption fails. Does something like that exist? Anyway this is a bit
> > utopic or overengineered. Simpler ways of improving things are with
> > documentation (e.g. „Don't do this, it's unsafe“), with messages
> > („You're doing this, which may be unsafe“), or with questions („Really
> > do this unsafe thing?“)
>
> Sounds interesting, but I am afraid that this idea is too abstract. It
> is not clear what Emacs is supposed to do with such regions. Maybe Eli
> has something better to say.
>

By the way, there's already reveal-mode which marks some private
sections and replaces them with asterisks. For instance if you edit
~/.authinfo and write this
machine some_pc  login my_user port su password my_password
…then you'll see
machine some_pc  login my_user port su password ********
unless you position the cursor there.
It seems it's a display thing only, using overlays. I thought that
maybe unencrypted org-crypt sections could be marked or displayed like
that (with * when unfocused), and then org-element could detect them
and avoid caching those parts. But I'm not sure if org-persist sees
overlays.
Anyway this is beyond my Emacs knowledge and I'm speculating.
 also don't know whether „unfocused unencrypted org-crypt sections“
replaced by asterisks would look nice.


  reply	other threads:[~2024-07-02 16:55 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-12  9:38 Please document the caching and its user options Eli Zaretskii
2024-06-14 13:12 ` Ihor Radchenko
2024-06-14 13:41   ` Eli Zaretskii
2024-06-14 15:31     ` Ihor Radchenko
2024-06-14 15:56       ` Eli Zaretskii
2024-06-15 12:47         ` Ihor Radchenko
2024-06-15 13:01           ` Eli Zaretskii
2024-06-15 14:13             ` Ihor Radchenko
2024-06-15 14:37               ` Eli Zaretskii
2024-06-16  9:05                 ` Ihor Radchenko
2024-06-16 10:41                   ` Eli Zaretskii
2024-06-23  9:12                     ` Björn Bidar
2024-06-15 13:47           ` Ihor Radchenko
2024-06-14 13:56   ` Jens Lechtenboerger
2024-06-14 14:31     ` Publishing cache (was: Please document the caching and its user options) Ihor Radchenko
2024-08-12  7:55       ` Proposal: Change publication timestamps (was: Publishing cache) Jens Lechtenboerger
2024-08-15 18:29         ` Ihor Radchenko
2024-08-25 17:00           ` Proposal: Change publication timestamps Jens Lechtenboerger
2024-09-15 12:02             ` Jens Lechtenboerger
2024-09-17 18:33               ` Ihor Radchenko
2024-06-16  5:40   ` Please document the caching and its user options Daniel Clemente
2024-06-16 12:36     ` Ihor Radchenko
2024-06-17 12:41       ` Daniel Clemente
2024-06-18 15:53         ` Ihor Radchenko
2024-06-18 16:15           ` Eli Zaretskii
2024-06-18 16:25             ` Ihor Radchenko
2024-06-18 16:33               ` Eli Zaretskii
2024-06-18 16:55                 ` Ihor Radchenko
2024-06-19  9:27                   ` Colin Baxter
2024-06-19 10:35                     ` Ihor Radchenko
2024-06-19 13:04                       ` Eli Zaretskii
2024-06-19 13:30                         ` Ihor Radchenko
2024-06-19 16:07                           ` Colin Baxter
2024-06-19 16:15                             ` Ihor Radchenko
2024-06-18 22:06               ` Rudolf Adamkovič
2024-06-19  4:29                 ` tomas
2024-06-23 11:45           ` Daniel Clemente
2024-06-24 10:36             ` Ihor Radchenko
2024-06-26 12:59               ` Daniel Clemente
2024-06-26 13:21                 ` org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options) Ihor Radchenko
2024-06-27  8:55                   ` Daniel Clemente
2024-06-27 10:15                     ` org-encrypt-entries is slow (was: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options)) Ihor Radchenko
2024-07-02 16:54                       ` Daniel Clemente
2024-07-02 19:16                         ` Ihor Radchenko
2024-07-04 10:36                           ` Daniel Clemente
2024-07-06 13:02                             ` Ihor Radchenko
2024-07-10 13:09                               ` Daniel Clemente
2024-07-11 10:40                                 ` Ihor Radchenko
2024-07-15 17:00                                   ` Daniel Clemente
2024-07-20 14:14                                     ` Ihor Radchenko
2024-07-24 13:47                                       ` Daniel Clemente
2024-07-25  7:31                                         ` Ihor Radchenko
2024-07-25 14:08                                           ` Daniel Clemente
2024-07-25 14:15                                             ` Ihor Radchenko
2024-10-05 18:56                           ` Daniel Clemente
2024-10-20 12:57                             ` Ihor Radchenko
2024-06-27 10:34                     ` org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options) Ihor Radchenko
2024-07-02 16:53                       ` Daniel Clemente [this message]
2024-06-27  9:27                 ` Please document the caching and its user options Eli Zaretskii
2024-06-27 10:11                   ` Ihor Radchenko
2024-06-27 10:30                     ` Eli Zaretskii
2024-06-28 12:54                     ` Rudolf Adamkovič
2024-06-28 15:31                       ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJKAhPDtbrW01WSLTnT=CeqMuyDMvnSPehf2StV-kMUTXoerSg@mail.gmail.com' \
    --to=n142857@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).