Re: 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]

Daniel Clemente  writes:

>> There is no such thing as "inline block" in Org syntax.
>
> I meant "inline task", sorry. I remembered "display: inline-block" from CSS…
> I don't think we need support for encrypted #+BEGIN_…/#+END… blocks.

I did not mean this.

>> > ** this is an inline block  :crypt:
>> > Content.

In the above, "Content." does not belong to the inlinetask.
Only inlinetasks with  END can have non-empty contents.

The fact that it is encrypted anyway is simply a bug in org-crypt.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: 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))

[Daniel Clemente]

> There is no such thing as "inline block" in Org syntax.

I meant "inline task", sorry. I remembered "display: inline-block" from CSS…
I don't think we need support for encrypted #+BEGIN_…/#+END… blocks.

Fixing the org-crypt + inline task bugs seems low priority since it's
an uncommon case and there are probably workarounds.


On Thu, 25 Jul 2024 at 07:30, Ihor Radchenko  wrote:
>
> Daniel Clemente  writes:
>
> > I found minor but unrelated issues, e.g. if you have an empty section like 
> > this:
> >
> > * abc2
> > :crypt:
> > * def
> >
> > … if you rename the abc2 header, e.g. to abc, it will ask the
> > encryption password again, even when the contents (an empty header)
> > didn't change.
> >
> > Another minor and weird bug: inline blocks. The part about showing the
> > unencrypted contents while keeping the disk contents encrypted doesn't
> > seem to work with encrypted inline blocks: they're saved encrypted,
> > but they're displayed encrypted. In fact they can't be displayed
> > unencrypted even if you call org-decrypt-contents. Maybe inline
> > encrypted blocks aren't supported.
> > To test this:
> > * section
> > ** this is an inline block
> >  :crypt:
> > Content.
> >
> > If you want you can split this to other threads or just ignore these
> > edge cases for now.
>
> There is no such thing as "inline block" in Org syntax.
> The current behavior of org-crypt is because it mishandles inlinetasks
> in specific way.
>
> I can add support for proper inlinetasks delimited by END line, but not
> for what you call "blocks" - that one is actually a bug when org-crypt
> encrypts everything spanning between one-line inlinetask down to the
> next heading.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: 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]

Daniel Clemente  writes:

> I found minor but unrelated issues, e.g. if you have an empty section like 
> this:
>
> * abc2:crypt:
> * def
>
> … if you rename the abc2 header, e.g. to abc, it will ask the
> encryption password again, even when the contents (an empty header)
> didn't change.
>
> Another minor and weird bug: inline blocks. The part about showing the
> unencrypted contents while keeping the disk contents encrypted doesn't
> seem to work with encrypted inline blocks: they're saved encrypted,
> but they're displayed encrypted. In fact they can't be displayed
> unencrypted even if you call org-decrypt-contents. Maybe inline
> encrypted blocks aren't supported.
> To test this:
> * section
> ** this is an inline block
>  :crypt:
> Content.
>
> If you want you can split this to other threads or just ignore these
> edge cases for now.

There is no such thing as "inline block" in Org syntax.
The current behavior of org-crypt is because it mishandles inlinetasks
in specific way.

I can add support for proper inlinetasks delimited by END line, but not
for what you call "blocks" - that one is actually a bug when org-crypt
encrypts everything spanning between one-line inlinetask down to the
next heading.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: 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))

[Daniel Clemente]

The 3 small problems mentioned above are fixed, thanks.
Encryption is faster, and safer now. The part about communicating the
encryption status (communicating „this is actually encrypted on disk
even when you're seeing it unencrypted“) can be improved later if
others find the current behaviour confusing.

In the „Back to top level“ situation I mentioned, the encryption
prompt is canceled, and I'm happy that now I don't lose the section I
was encrypting.
Maybe you wanted to have org-crypt also catch this case (encryption
prompt canceled) to be able to show a „could not encrypt“ message. But
I think it's good enough as it is: it stays unencrypted, and on the
next attempt to save it, there will be another encryption password
prompt.

I found minor but unrelated issues, e.g. if you have an empty section like this:

* abc2:crypt:
* def

… if you rename the abc2 header, e.g. to abc, it will ask the
encryption password again, even when the contents (an empty header)
didn't change.

Another minor and weird bug: inline blocks. The part about showing the
unencrypted contents while keeping the disk contents encrypted doesn't
seem to work with encrypted inline blocks: they're saved encrypted,
but they're displayed encrypted. In fact they can't be displayed
unencrypted even if you call org-decrypt-contents. Maybe inline
encrypted blocks aren't supported.
To test this:
* section
** this is an inline block
 :crypt:
Content.

If you want you can split this to other threads or just ignore these
edge cases for now.

On Sat, 20 Jul 2024 at 14:12, Ihor Radchenko  wrote:
>
> Daniel Clemente  writes:
>
> > But org-crypt still feels strange. For instance, I decrypt a header,
> > add a space somewhere else and save. It's saved, but the header is
> > still visibly unencrypted in Emacs; that's unexpected, because
> > org-crypt-use-before-save-magic promised to „automatically encrypt
> > entries before a file is saved to disk“.
> > I checked the file from outside Emacs and I see that the header is
> > actually encrypted, so technically it did what it promised to do
> > though I don't see it in Emacs.
> > So there's a discordance between what I see and what is saved. Maybe
> > it's feature, not a bug: „you still see the decrypted contents but you
> > can trust that when they're saved they'll be saved encrypted“. This
> > may be clarified in the docstring. If it's a feature, I think it may
> > be useful; I just don't like having to trust that the silent
> > background-auto-encryption is working (I'll often want to verify the
> > file from outside Emacs). But users may have different preferences.
> > This may be material for another thread.
>
> Yup, I consider this as a feature. Especially for people using
> auto-save-visited-mode and similar. If saving is triggered on timer,
> while editing encrypted heading, encrypting everything in the middle of
> typing is not fun.
>
> > Minor thing, not important now: the cursor jumps to the end of the
> > header after a C-x C-s when in the middle of a currently-decrypted
> > block without changes.
>
> Should be better now on the latest version of the branch.
>
> > Another minor thing: I use a key that calls
> > (org-save-all-org-buffers), and if I press it e.g. from the *scratch*
> > buffer it may ask me the „Passphrase for symmetric encryption“
> > question (because I edited some crypted section) but I don't know
> > which buffer it's asking about. But it's not a problem because if I
> > press C-g then I'll see it.
>
> Should also be better now.
>
> > I see a new problem: with (org-crypt-use-before-save-magic) enabled, I
> > edit a decrypted section, press C-x C-s to save and it asks me for the
> > encryption password. Here, if I press C-g, org-crypt would catch it
> > and then tell me that it won't be able to encrypt due to the C-g.
> > However I'm not pressing C-g, what I'm doing is opening another TTY
> > frame (I'm running TTY emacsclient, with no X support, but under
> > urxvt); this makes the minibuffer disappear, and I see „Back to top
> > level“, and the whole contents of the section being encrypted are
> > lost.
>
> I tried to reproduce with the latest version of the branch. Seems to
> work fine. May you test?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: 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]

Daniel Clemente  writes:

> But org-crypt still feels strange. For instance, I decrypt a header,
> add a space somewhere else and save. It's saved, but the header is
> still visibly unencrypted in Emacs; that's unexpected, because
> org-crypt-use-before-save-magic promised to „automatically encrypt
> entries before a file is saved to disk“.
> I checked the file from outside Emacs and I see that the header is
> actually encrypted, so technically it did what it promised to do
> though I don't see it in Emacs.
> So there's a discordance between what I see and what is saved. Maybe
> it's feature, not a bug: „you still see the decrypted contents but you
> can trust that when they're saved they'll be saved encrypted“. This
> may be clarified in the docstring. If it's a feature, I think it may
> be useful; I just don't like having to trust that the silent
> background-auto-encryption is working (I'll often want to verify the
> file from outside Emacs). But users may have different preferences.
> This may be material for another thread.

Yup, I consider this as a feature. Especially for people using
auto-save-visited-mode and similar. If saving is triggered on timer,
while editing encrypted heading, encrypting everything in the middle of
typing is not fun.

> Minor thing, not important now: the cursor jumps to the end of the
> header after a C-x C-s when in the middle of a currently-decrypted
> block without changes.

Should be better now on the latest version of the branch.

> Another minor thing: I use a key that calls
> (org-save-all-org-buffers), and if I press it e.g. from the *scratch*
> buffer it may ask me the „Passphrase for symmetric encryption“
> question (because I edited some crypted section) but I don't know
> which buffer it's asking about. But it's not a problem because if I
> press C-g then I'll see it.

Should also be better now.

> I see a new problem: with (org-crypt-use-before-save-magic) enabled, I
> edit a decrypted section, press C-x C-s to save and it asks me for the
> encryption password. Here, if I press C-g, org-crypt would catch it
> and then tell me that it won't be able to encrypt due to the C-g.
> However I'm not pressing C-g, what I'm doing is opening another TTY
> frame (I'm running TTY emacsclient, with no X support, but under
> urxvt); this makes the minibuffer disappear, and I see „Back to top
> level“, and the whole contents of the section being encrypted are
> lost.

I tried to reproduce with the latest version of the branch. Seems to
work fine. May you test?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: 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))

[Daniel Clemente]

In that branch, I don't see the previously mentioned bugs; thanks.

But org-crypt still feels strange. For instance, I decrypt a header,
add a space somewhere else and save. It's saved, but the header is
still visibly unencrypted in Emacs; that's unexpected, because
org-crypt-use-before-save-magic promised to „automatically encrypt
entries before a file is saved to disk“.
I checked the file from outside Emacs and I see that the header is
actually encrypted, so technically it did what it promised to do
though I don't see it in Emacs.
So there's a discordance between what I see and what is saved. Maybe
it's feature, not a bug: „you still see the decrypted contents but you
can trust that when they're saved they'll be saved encrypted“. This
may be clarified in the docstring. If it's a feature, I think it may
be useful; I just don't like having to trust that the silent
background-auto-encryption is working (I'll often want to verify the
file from outside Emacs). But users may have different preferences.
This may be material for another thread.

The part about the slowness has improved to acceptable levels, thanks.

Minor thing, not important now: the cursor jumps to the end of the
header after a C-x C-s when in the middle of a currently-decrypted
block without changes.

Another minor thing: I use a key that calls
(org-save-all-org-buffers), and if I press it e.g. from the *scratch*
buffer it may ask me the „Passphrase for symmetric encryption“
question (because I edited some crypted section) but I don't know
which buffer it's asking about. But it's not a problem because if I
press C-g then I'll see it.

I see a new problem: with (org-crypt-use-before-save-magic) enabled, I
edit a decrypted section, press C-x C-s to save and it asks me for the
encryption password. Here, if I press C-g, org-crypt would catch it
and then tell me that it won't be able to encrypt due to the C-g.
However I'm not pressing C-g, what I'm doing is opening another TTY
frame (I'm running TTY emacsclient, with no X support, but under
urxvt); this makes the minibuffer disappear, and I see „Back to top
level“, and the whole contents of the section being encrypted are
lost.



On Thu, 11 Jul 2024 at 10:39, Ihor Radchenko  wrote:
>
> Daniel Clemente  writes:
>
> > I see it's trying to decrypt things (therefore it asks for the
> > password). It shouldn't, since I didn't modify any encrypted section.
> > I said „it asked me for an encryption password“ because the GPG prompt
> > confusingly uses the word „encryption“ („Passphrase for symmetric
> > encryption“), though it's actually asking for a decryption password.
> > ...
> > This is the text "abc" encrypted with password "abc". Use this file:
> >
> > * hi  
> > :nocrypt:
> > -BEGIN PGP MESSAGE-
> >
> > jA0ECQMCVpS/qSoed5f/0joBYoIRWdgt/+PVQCsZh9sg176SdnvP2Wc8tH/CV1Rk
> > l2MjAh3Rk19Q2aP2EffpZ5CFeGELTMXCnCYv
> > =FNtI
> > -END PGP MESSAGE-
> >
> > Open the file, add a space to the title and save it. The first time it
> > works (no questions asked) because there's no tag called :crypt:
> > Now change the :nocrypt: to :crypt: and save.  It asks for the
> > password. Press C-g to cancel.
> > Change again the tag to :nocrypt:. Save. It asks for the encryption
> > password; it shouldn't.
> > Add a space to the title, save, it keeps asking for the encryption
> > password, though there's no :crypt: section.
>
> This should be fixed now.
> May you try yet again?
>
> >> > - Org spends around 20 seconds trying to save the file, in a loop,
> >> > reporting:  (error "org-crypt: Encryption failed.  Not saving the
> >> > buffer. Error: GPG error: \"Encrypt failed\", \"Canceled; Exit\"")
> >>
> >> This is curious, but I again have no clue. Maybe the new version of the
> >> branch works a bit better.
> >>
> >
> > Since this error can happen because of a problem in a different buffer
> > (not the current one), would it be good to mention the file name in
> > that error message?
>
> Yes. Done now on the branch.
>
> > I didn't see this particular problem again. But I see others, which
> > are hard to report and reproduce. For instance I had an encrypted
> > section under a :crypt: header (I see „BEGIN PGP“ and hex codes), I
> > save, and saving *UNencrypts* the header before saving, without
> > asking. It should never decrypt when saving, but it does. This happens
> > with the same small example I posted above (but using the :crypt:
> > tag).
>
> The other problem you reported had something to do with incorrectly
> cycling encryption state during save. I hope that fixing one also fixed
> another.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: 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]

Daniel Clemente  writes:

> I see it's trying to decrypt things (therefore it asks for the
> password). It shouldn't, since I didn't modify any encrypted section.
> I said „it asked me for an encryption password“ because the GPG prompt
> confusingly uses the word „encryption“ („Passphrase for symmetric
> encryption“), though it's actually asking for a decryption password.
> ...
> This is the text "abc" encrypted with password "abc". Use this file:
>
> * hi  
> :nocrypt:
> -BEGIN PGP MESSAGE-
>
> jA0ECQMCVpS/qSoed5f/0joBYoIRWdgt/+PVQCsZh9sg176SdnvP2Wc8tH/CV1Rk
> l2MjAh3Rk19Q2aP2EffpZ5CFeGELTMXCnCYv
> =FNtI
> -END PGP MESSAGE-
>
> Open the file, add a space to the title and save it. The first time it
> works (no questions asked) because there's no tag called :crypt:
> Now change the :nocrypt: to :crypt: and save.  It asks for the
> password. Press C-g to cancel.
> Change again the tag to :nocrypt:. Save. It asks for the encryption
> password; it shouldn't.
> Add a space to the title, save, it keeps asking for the encryption
> password, though there's no :crypt: section.

This should be fixed now.
May you try yet again?

>> > - Org spends around 20 seconds trying to save the file, in a loop,
>> > reporting:  (error "org-crypt: Encryption failed.  Not saving the
>> > buffer. Error: GPG error: \"Encrypt failed\", \"Canceled; Exit\"")
>>
>> This is curious, but I again have no clue. Maybe the new version of the
>> branch works a bit better.
>>
>
> Since this error can happen because of a problem in a different buffer
> (not the current one), would it be good to mention the file name in
> that error message?

Yes. Done now on the branch.

> I didn't see this particular problem again. But I see others, which
> are hard to report and reproduce. For instance I had an encrypted
> section under a :crypt: header (I see „BEGIN PGP“ and hex codes), I
> save, and saving *UNencrypts* the header before saving, without
> asking. It should never decrypt when saving, but it does. This happens
> with the same small example I posted above (but using the :crypt:
> tag).

The other problem you reported had something to do with incorrectly
cycling encryption state during save. I hope that fixing one also fixed
another.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: 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))

[Daniel Clemente]

> > With that code I see something strange: I opened a file which had
> > encrypted :crypt: sections (never unencrypted), and after adding a
> > space somewhere else and saving, it asked me for an encryption
> > password. It shouldn't, since all sections are encrypted.
> > I also see „org-crypt: Re-encrypting all decrypted entries due to
> > auto-save“ asking me for the encryption password.
>
> Note that it may be asking about _different_ buffers, not just current.
> That's because auto-save-mode saves all the buffers, not just current :)
>

It would be good to know what buffer it is asking about; see
suggestion later below, about mentioning its name.
But I think it's already telling me which buffer it is, by moving the
point to the affected section, before asking the question.
It's the first section in the current file. And I can see that it's
actually encrypted.

I see it's trying to decrypt things (therefore it asks for the
password). It shouldn't, since I didn't modify any encrypted section.
I said „it asked me for an encryption password“ because the GPG prompt
confusingly uses the word „encryption“ („Passphrase for symmetric
encryption“), though it's actually asking for a decryption password.
It calls:

  org-decrypt-entry()
  (progn (org-decrypt-entry))
  (if (get-text-property (point) 'org-crypt-auto-encrypted) (progn
(org-decrypt-entry)))
  (while (not (eobp)) (if (get-text-property (point)
'org-crypt-auto-encrypted) (progn (org-decrypt-entry))) (goto-char
(next-single-char-property-change (point) 'org-crypt-auto-encrypted)))
  (save-restriction (widen) (goto-char (point-min)) (while (not
(eobp)) (if (get-text-property (point) 'org-crypt-auto-encrypted)
(progn (org-decrypt-entry))) (goto-char
(next-single-char-property-change (point)
'org-crypt-auto-encrypted
  (save-excursion (save-restriction (widen) (goto-char (point-min))
(while (not (eobp)) (if (get-text-property (point)
'org-crypt-auto-encrypted) (progn (org-decrypt-entry))) (goto-char
(next-single-char-property-change (point)
'org-crypt-auto-encrypted)
  (let ((modified-flag (buffer-modified-p))) (save-excursion
(save-restriction (widen) (goto-char (point-min)) (while (not (eobp))
(if (get-text-property (point) 'org-crypt-auto-encrypted) (progn
(org-decrypt-entry))) (goto-char (next-single-char-property-change
(point) 'org-crypt-auto-encrypted) (set-buffer-modified-p
modified-flag))
  org-crypt--decrypt-marked-entries()
  run-hooks(after-save-hook)
  basic-save-buffer(t)



> > But I tried removing all :crypt: tags (I renamed them to something
> > else), and saving a large file seems as slow as before. A few seconds
> > (often 5 seconds; sometimes it's just 2 or 3; this was the case before
> > too). Here's when it's 5, for 1 save:
>
> I think I fixed this now.
> May you try the latest version of the same branch?
>

This particular case in which there are no :crypt: tags is fast now,
thanks. In the same large file as before, saving is instantaneous
(well, the usual 100 to 200 ms).

  22   2% - run-hook-with-args-until-success
  22   2%  - org-crypt--encrypt-and-mark-entries
  22   2%   - let
  22   2%- condition-case
  22   2% - unwind-protect
  22   2%  - org-encrypt-entries
  22   2%   - org-encrypt--map-items
  22   2%- let*
  22   2% - if
  22   2%  - or
  22   2%   - save-excursion
  22   2%- save-restriction
  22   2%   re-search-forward


> > I also see new problems (which would take me a long time to explain
> > since I don't understand the code or the settings), where:
> > - Org asks me for an encryption password even if there are no :crypt:
> > tags. I just changed the only :crypt: tag to a :nocrypt: tag and saved
>
> I cannot reproduce. May you create a small example file and explain how
> to trigger the problem you are seeing?

This is the text "abc" encrypted with password "abc". Use this file:

* hi  :nocrypt:
-BEGIN PGP MESSAGE-

jA0ECQMCVpS/qSoed5f/0joBYoIRWdgt/+PVQCsZh9sg176SdnvP2Wc8tH/CV1Rk
l2MjAh3Rk19Q2aP2EffpZ5CFeGELTMXCnCYv
=FNtI
-END PGP MESSAGE-

Open the file, add a space to the title and save it. The first time it
works (no questions asked) because there's no tag called :crypt:
Now change the :nocrypt: to :crypt: and save.  It asks for the
password. Press C-g to cancel.
Change again the tag to :nocrypt:. Save. It asks for the encryption
password; it shouldn't.
Add a space to the title, save, it keeps asking for the encryption
password, though there's no :crypt: section.


>
> > - Org spends around 20 seconds trying to save the file, in a loop,
> > reporting:  (error "org-crypt: Encryption failed.  Not saving the
> > buffer. Error: GPG error: \"Encrypt failed\", \"Canceled; Exit\"")
>
> This is curious, b

Re: 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]

Daniel Clemente  writes:

>> May you try
>> https://git.sr.ht/~yantar92/org-mode/log/feature/org-crypt-refactor branch?
>> Is encryption speed satisfactory then?
>
> With that code I see something strange: I opened a file which had
> encrypted :crypt: sections (never unencrypted), and after adding a
> space somewhere else and saving, it asked me for an encryption
> password. It shouldn't, since all sections are encrypted.
> I also see „org-crypt: Re-encrypting all decrypted entries due to
> auto-save“ asking me for the encryption password.

Note that it may be asking about _different_ buffers, not just current.
That's because auto-save-mode saves all the buffers, not just current :)

> But I tried removing all :crypt: tags (I renamed them to something
> else), and saving a large file seems as slow as before. A few seconds
> (often 5 seconds; sometimes it's just 2 or 3; this was the case before
> too). Here's when it's 5, for 1 save:

I think I fixed this now.
May you try the latest version of the same branch?

> I also see new problems (which would take me a long time to explain
> since I don't understand the code or the settings), where:
> - Org asks me for an encryption password even if there are no :crypt:
> tags. I just changed the only :crypt: tag to a :nocrypt: tag and saved

I cannot reproduce. May you create a small example file and explain how
to trigger the problem you are seeing?

> - Org spends around 20 seconds trying to save the file, in a loop,
> reporting:  (error "org-crypt: Encryption failed.  Not saving the
> buffer. Error: GPG error: \"Encrypt failed\", \"Canceled; Exit\"")

This is curious, but I again have no clue. Maybe the new version of the
branch works a bit better. 

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: 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))

[Daniel Clemente]

> May you try
> https://git.sr.ht/~yantar92/org-mode/log/feature/org-crypt-refactor branch?
> Is encryption speed satisfactory then?

With that code I see something strange: I opened a file which had
encrypted :crypt: sections (never unencrypted), and after adding a
space somewhere else and saving, it asked me for an encryption
password. It shouldn't, since all sections are encrypted.
I also see „org-crypt: Re-encrypting all decrypted entries due to
auto-save“ asking me for the encryption password.

But I tried removing all :crypt: tags (I renamed them to something
else), and saving a large file seems as slow as before. A few seconds
(often 5 seconds; sometimes it's just 2 or 3; this was the case before
too). Here's when it's 5, for 1 save:

4669  82% - command-execute
4076  72%  - funcall-interactively
4055  72%   - save-buffer
4051  71%- basic-save-buffer
3831  68% - run-hook-with-args-until-success
3831  68%  - org-crypt--encrypt-and-mark-entries
3831  68%   - org-encrypt-entries
3831  68%- org-scan-tags
3831  68% - org-element-cache-map
1859  33%  - org-element--parse-to
 848  15%   + org-element--cache-put
 655  11%   + #
 120   2%   + org-element--cache-find
  28   0% org-element--cache-active-p
  20   0% #
  16   0% org-element-type
   4   0% #
   4   0% #
1100  19%  - #
 804  14%   - org-entry-get-with-inheritance
 780  13%- org-element-lineage-map
 720  12% - #
 668  11%  + org--property-local-values
  12   0%org-element-begin
   4   0%delq
  36   0% + org-element--property
   8   0% + org-element-type-p
   4   0%   functionp
   8   0%  org--property-get-separator
   8   0%  make-closure
 208   3%   + org-element--property
  32   0%   + org-get-tags
   8   0%   + org-element-begin
 384   6%  + org-element-at-point
 164   2%re-search-forward
 132   2%  + #
  44   0%  + #
  16   0%match-data
  12   0%  + org-element--property
   8   0%  + #
   8   0%make-closure
   4   0%buffer-base-buffer
   4   0%  + org-element-type-p
 220   3% + basic-save-buffer-1
   8   0% execute-extended-command
   6   0%   + org-delete-backward-char
   3   0%   + org-self-insert-command
   3   0%   + previous-line
   1   0%   + next-line
 593  10%  - byte-code


I also see new problems (which would take me a long time to explain
since I don't understand the code or the settings), where:
- Org asks me for an encryption password even if there are no :crypt:
tags. I just changed the only :crypt: tag to a :nocrypt: tag and saved
- Org spends around 20 seconds trying to save the file, in a loop,
reporting:  (error "org-crypt: Encryption failed.  Not saving the
buffer. Error: GPG error: \"Encrypt failed\", \"Canceled; Exit\"")

Re: 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]

Daniel Clemente  writes:

>> Does it also happen when you use the latest Org mode version?
>>
>
> Yes, with today's build. It happens with an 11 Mb Org file which has
> 19721 headers (some of them reach level 13).
> Here I enabled the profiler, added a space, saved (1 time only), and
> reported CPU. It took around 5 seconds.
>
> ...
> 3931  76%  - org-encrypt-entries
> 3931  76%   - org-scan-tags

May you try
https://git.sr.ht/~yantar92/org-mode/log/feature/org-crypt-refactor branch?
Is encryption speed satisfactory then?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: 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))

[Daniel Clemente]

> > For instance, I don't use it because it adds around 5 seconds to each
> > saving of a large file. If it were instantaneous I would enable it.
> > With it disabled, this explains why I often find unencrypted sections
> > at the end of the day… I have to rely on myself to reencrypt them
> > again.
>
> Does it also happen when you use the latest Org mode version?
>

Yes, with today's build. It happens with an 11 Mb Org file which has
19721 headers (some of them reach level 13).
Here I enabled the profiler, added a space, saved (1 time only), and
reported CPU. It took around 5 seconds.

4616  89% - command-execute
4349  84%  - funcall-interactively
4127  80%   - save-buffer
4127  80%- basic-save-buffer
3931  76% - run-hooks
3931  76%  - org-encrypt-entries
3931  76%   - org-scan-tags
3931  76%- org-element-cache-map
1764  34% - org-element--parse-to
 868  16%  - org-element--cache-put
 848  16%   - avl-tree-enter
 840  16%- avl-tree--do-enter
 792  15% - avl-tree--do-enter
 748  14%  - avl-tree--do-enter
 688  13%   - avl-tree--do-enter
 632  12%- avl-tree--do-enter
 576  11% + avl-tree--do-enter
  52   1% + org-element--cache-compare
  56   1%+ org-element--cache-compare
  44   0%   + org-element--cache-compare
   4   0% avl-tree--node-branch
  44   0%  + org-element--cache-compare
  48   0% + org-element--cache-compare
 580  11%  - #
 448   8%   + org-element-headline-parser
  20   0%   + org-element-section-parser
   4   0% org-element-type
 136   2%  + org-element--cache-find
  20   0%#
  16   0%org-element-type
  12   0%throw
   8   0%  + #
   8   0%  + #
   4   0%org-element--cache-active-p
1161  22% - #
 857  16%  - org-entry-get-with-inheritance
 797  15%   + org-element-lineage-map
   8   0% org-element-at-point
   8   0% make-closure
   8   0% org--property-get-separator
   4   0% mapconcat
 184   3%  + org-element--property
  16   0%  + org-get-tags
   8   0%  + org-encrypt-entry
   8   0%org-element-begin
   4   0%#
   4   0%functionp
 446   8% + org-element-at-point
 200   3%   re-search-forward
 124   2% + #
  44   0% + #
  28   0%   match-data
  12   0%   make-closure
   8   0% + org-element--property
   4   0%   #
   4   0%   org-element-type-p
   4   0%   #
   4   0%   throw
 196   3% + basic-save-buffer-1

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]

Daniel Clemente  writes:

> For instance, I don't use it because it adds around 5 seconds to each
> saving of a large file. If it were instantaneous I would enable it.
> With it disabled, this explains why I often find unencrypted sections
> at the end of the day… I have to rely on myself to reencrypt them
> again.

Does it also happen when you use the latest Org mode version?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at