unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ken manheimer <ken.manheimer@gmail.com>
To: Daiki Ueno <ueno@unixuser.org>
Cc: emacs-devel@gnu.org
Subject: Re: interjecting a custom epa passphrase prompt
Date: Sun, 5 Dec 2010 12:51:53 -0500	[thread overview]
Message-ID: <AANLkTikLtNMAzXf_JFb4zj7Ljtb-Oq3TLKkSYuTi11SD@mail.gmail.com> (raw)
In-Reply-To: <m3vd3crjtx.fsf-ueno@unixuser.org>

On Wed, Dec 1, 2010 at 9:26 PM, Daiki Ueno <ueno@unixuser.org> wrote:
>
> ken manheimer <ken.manheimer@gmail.com> writes:
>
> > i am trying to use 'epg-context-set-passphrase-callback' to adjust the
> > context for encryption to try to interject my own prompting, but it's
> > having no effect.
>
> Most likely you are using GnuPG 2, which does not ask passphrase on tty
> or on status FD, unlike GnuPG 1.  Try:
>
> $ gpg --version

you're right, i was using gnupg v2.

> Assuming that:
>
> > has all provision for custom passphrase prompting in epg been
> > eliminated?
>
> Still you could use GnuPG 1 for your custom passphrase prompting, since
> GnuPG 2 is not a newer version of GnuPG, but a separate product.

well, i'm surprised!  the passphrase callback does become effective
when i switch to using gnupg v1.  i'm very glad i have an avenue to
preserve the allout features.  it's a mixed situation, though,
requiring user intervention make a configuration choice that has
unclear security and other implications.

i think i understand that epg design decision, though - epg uses the
discretion for prompting that the underlying gnupg implementation
makes available, in a sense deferring responsibility for that security
exposure to that underlying gnupg implementation.

i guess i can tell allout users that they can get passphrase hinting
and verification if they configure epg to use gnupg v1 rather than
gnupg v2, but to realize that that involves passphrase handling in
emacs lisp code, which is more susceptible to subvention than
containing it solely in the gnupg execution.

one thing i notice would have been helpful would be to have some clear
warning about this underlying gnupg behavior dependence in the epg.el
code, somehow associated with the passphrase callback code.  if
situated well and clearly, this could help developers using the epg
library a lot in making choices connected with somewhat special uses
like mine, in allout.

i want to thank you very much for the speedy response, by the way!
that was very helpful - i could quickly confirm that i could reap some
results from my efforts to that point, and continue forward, which was
very reassuring.  i'm sorry i didn't reply sooner - the little time i
had available was spent confirming and scoping out how i would use the
passphrase callback.  i hope to have some more time, soon, to complete
allout's switchover to epg.

> Regards,
> --
> Daiki Ueno

--
ken
http://myriadicity.net



  reply	other threads:[~2010-12-05 17:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-02  2:04 interjecting a custom epa passphrase prompt ken manheimer
2010-12-02  2:26 ` Daiki Ueno
2010-12-05 17:51   ` ken manheimer [this message]
2011-05-20  3:43     ` Thomas Lynch
2011-05-20  6:35       ` Daiki Ueno
2011-05-21 15:30         ` Tom Lynch
2011-05-22  0:41           ` Daiki Ueno
2011-05-22 23:07             ` Tom Lynch
2011-05-22 23:09               ` Tom Lynch

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.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=AANLkTikLtNMAzXf_JFb4zj7Ljtb-Oq3TLKkSYuTi11SD@mail.gmail.com \
    --to=ken.manheimer@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=ueno@unixuser.org \
    /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.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).