all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: David Masterson <dsmasterson@gmail.com>,  emacs-orgmode@gnu.org
Subject: Re: org-crypt ?
Date: Sun, 12 Jun 2022 09:37:31 +0800	[thread overview]
Message-ID: <87zgiiach0.fsf@localhost> (raw)
In-Reply-To: <871qvuy8vn.fsf@gmail.com>

Tim Cross <theophilusx@gmail.com> writes:

> Ihor's response to this indicates I'm incorrect here. As I stated
> earlier, it has been a long time since I used org-crypt, so I'd trust
> his advice more. However, from a technical perspective, I don't
> understand how gnupg or org-crypto can prompt to get the different keys
> and know which chunk to apply which key to, but that is my limited
> technical expertise more than anything else. With asymmetric encryption,
> you specify the key name, so it knows which key belongs with each
> encrypted chunk. I don't see in the code how this is handled for
> symmetric encryption where no key name is specified. 

If you run M-x org-decrypt-entry, the prompt will be for that entry. It
is up to the user to figure out which key is the key to be used there.

If you run M-x org-decrypt-entries, it simply runs org-decrypt-entry on
each encrypted headline appearing in the buffer. From top to bottom. No
indication will be done about which headline is being processed at any
given point. The user may need to count.

Of course, the last scenario is not very user-friendly, but I doubt that
many users really use different symmetric encryption keys on different
headings in a single file. Nobody bothered enough to implement a more
verbose prompt.

>>> Probably, though I don't know what else you would put in there which
>>> isn't already there. Feel free to supply a PR or patch once you have
>>> worked it out. However, as noted in the commentary section, org-crypt.el
>>> is really a very light-weight wrapper around functions in epg.el, so
>>> likely the first place to start when looking for documentation and
>>> examples is the epa/epg/easyPG manual
>>
>> Not good at writing these days, buy I'll consider.
>
> Please do. Often the best documentation comes from end users rather than
> developers. The developer is often too close to the code, which makes it
> harder for them to appreciate what users don't understand/know. For a
> user, the challenges they encounter are often 'fresher' and puts them in
> a better place to explain things. People on the list will provide
> feedback to help clarify and improve what you write. 

Fully agree. It is too easy to skip "obvious" things in documentation
when you know ins and outs of the code.

Best,
Ihor


  reply	other threads:[~2022-06-12  1:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10  4:08 org-crypt ? David Masterson
2022-06-11  3:35 ` Tim Cross
2022-06-11 21:29   ` David Masterson
2022-06-12  0:28     ` Tim Cross
2022-06-12  1:37       ` Ihor Radchenko [this message]
2022-06-12  3:07       ` David Masterson
2022-06-12  4:04         ` Tim Cross
2022-06-12  6:19           ` David Masterson
2022-06-12  4:15         ` Ihor Radchenko
2022-06-12  5:55           ` David Masterson
2022-06-14  4:13             ` Ihor Radchenko
2022-06-11  4:17 ` Ihor Radchenko
2022-06-11 21:17   ` David Masterson
2022-06-11 21:46     ` Ignacio Casso

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

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

  git send-email \
    --in-reply-to=87zgiiach0.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=dsmasterson@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.