Re: org-crypt ?

[Ihor Radchenko <yantar92@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