Add option --pinentry-program to gpgsm/gpgp2 or allow passing options to gpg-agent by environment variable
Closed, ResolvedPublic

Description

I'm building a web mail application using gpgme.

In this enviroment, it is obviously impossible to use the default pinentry.

Because gpgme_set_passphrase_cb() cannot be used, I have written my own
pinentry for use by this application.

I cannot use a running gpg-agent because the web mail application is acting on
behalf of thousands of different users, forbidding to keep one gpg-agent
permanently running for every user. Thus currently for every request involving
GnuPG action I'd have to:

1st: start gpg-agent --pinentry-program (my own pinentry)

2nd: do all the stuff with gpgme (using --gnupghome to access the keys and
settings for the user I'm currently acting for)

3rd: kill the gpg-agent process

This is an unnecessary overhead (and another re-inventing the wheel) because
gpg2/gpgsm already knows how to start gpg-agent on the fly.

Proposition:

If gpg2 would honor a --pinentry-program option, or if gpg-agent would honor a
PINENTRY_PROGRAM environment variable or alike, the already existing feature
that gpg-agent is called and killed by gpgsm/gpg2 could be used, making the use
of gpgme much easier.

Other, more general solutions would be to invent an environment variable
GPG_AGENT_OPTIONS_FILE that could be used to tell an on-the-fly started
gpg-agent to an options file different from the default one, or an environment
variable GPG_AGENT_OPTIONS containing addition options (overriding those given
in the options file but not those given on the command line of gpg-agent.)

Thank you very much to all developers for the great work you are doing with
GnuPG and related software.

Details

Due Date
Nov 25 2007, 1:00 AM
Version
2.0.4
perske set Version to 2.0.4.
perske added a subscriber: perske.
perske renamed this task from Add option --pinentry-program to gpgsm/gpgp2, to be passed to gpg-agent when started on the fly to Add option --pinentry-program to gpgsm/gpgp2 or allow passing options to gpg-agent by environment variable.May 13 2007, 2:38 PM
perske raised the priority of this task from Wishlist to Normal.
werner added a subscriber: werner.May 16 2007, 12:11 PM

Why are you using gpg2? Me seems that for your application gpg 1.4 is better
suited.

-----BEGIN PGP SIGNED MESSAGE-----

Hello,

thank you for your check-back.

Why are you using gpg2? Me seems that for your application gpg 1.4
is better suited.

I'll try to explain, hoping to make in clear without becoming too long:

Currently, my webmail program offers PGP cryptography using GnuPG
1.4.7. This is working without GPGME (when I wrote this, GPGME was not
yet in a usable state), but calls (via fork and exec) directly the
/usr/bin/gpg executable, passing all data via temporary files or pipes.

(See <Querverweis ins World Wide
Webhttp://www.uni-muenster.de/ZIV/perMail/SichereEMailMitPerMail.htmlVorsicht!>
and <Querverweis ins World Wide
Webhttp://www.uni-muenster.de/ZIV/perMail/Vorsicht!> if you are interested in
more information.)

I want to add S/MIME functionality. I _could_ add another set of
interface functions calling gpgsm (from GnuPG 2.0.4) directly, but you
are offering GPGME which makes writing own interface routines
unnecessary, and I'd like to benefit from that good work :-)

Thus I create gpg and gpgsm as outlined by these configure options (I
want my own installation not interfering with an installation that
might be delivered from the operating system distributor):

prefix=/usr/local/gpgfamily

gnupg-1: --prefix=$prefix

pth: --prefix=$prefix --enable-static --disable-shared

libassuan: --prefix=$prefix --with-pth-prefix=$prefix

libgpg-error: --prefix=$prefix --enable-static --disable-shared

libgcrypt: --prefix=$prefix --enable-static --disable-shared

  • - --with-gpg-error-prefix=$prefix

libksba: --prefix=$prefix --enable-static --disable-shared

  • - --with-gpg-error-prefix=$prefix

dirmngr: --prefix=$prefix --with-pth-prefix=$prefix

  • - --with-libassuan-prefix=$prefix --with-gpg-error-prefix=$prefix
  • - --with-libgcrypt-prefix=$prefix --with-ksba-prefix=$prefix

pinentry: --prefix=$prefix --enable-static --disable-shared

gnupg-2: --prefix=$prefix --with-pth-prefix=$prefix

  • - --with-libassuan-prefix=$prefix --with-gpg-error-prefix=$prefix
  • - --with-libgcrypt-prefix=$prefix --with-ksba-prefix=$prefix
  • - --with-dirmngr-pgm=$prefix/bin/dirmngr
  • - --with-pinentry-pgm=$prefix/bin/pinentry

gpgme --prefix=$prefix --with-pth-prefix=$prefix --enable-static

  • - --disable-shared --with-gpg-error-prefix=$prefix
  • - --with-gpg=$prefix/bin/gpg --with-gpgsm=$prefix/bin/gpgsm

When running interactively, the standard pinentry program shall be
used, when running from the webmail program, a self-written pinentry
program shall be used.

The webmail application, after setuid(USERNAME) and alike, initializes
gpgme and selects the GNUPGHOME by

gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP,gpginfo->file_name,

"/home/USERNAME/.webmail/gnupghome")

gpgme_set_engine_info(GPGME_PROTOCOL_CMS,gpginfo->file_name,

/home/USERNAME/.webmail/gnupghome")

But I see no chance to tell GPGME to use my nonstandard pinentry
program. For that problem, I'm looking for a solution.

Currently I'd to explicitly start a gpg-agent process (with the

  • - --pinentry-program option), parse its output, do my work with gpgme,

and kill the gpg-agent process. But gpgsm is able to start and kill
gpg-agent on the fly (and surely knowns much better than me how to do
it cleanly), using this feature would make life much easier - if only
the pinentry-program option could be set in any of those ways I proposed
in my previous message. (Using the options file of gpg-agent is not an
option because that would interfere with possible interactive using.)

Best regards


Rainer Perske, Zentrum für Informationsverarbeitung, Universität Münster
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (AIX)

iQDVAwUBRkr8EM9UbnbjB8C5AQFI9AYAmRUpbk+E/FklyEif0DvxXFWWQ1ZajBgp
U23FDhPSQVMXqCdoW141PCW0hMhZfReWfr1cqipASUB+1jCcIIZxZpHtlOhc5p//
KuMvwiZ/bZeSAx54uMbgtEFwqnA2NJYp92OscQ0K8dgT94tZcjEI7Kpp511Qfmqs
rdQUvMjJ7bxsOBXj0Ji5HUnIqy8reQONgfEsFebO50JhzKks0d5qYYDL6U82zE+C
MHh/eo8rWAQILWJcSHVUiigy6ucRfV5/

iuUl

-----END PGP SIGNATURE-----

Well, I understand.

What about a way to pass information from thye caller down to pinentry?

We have this kind of stuff already for some variables (e.g. DISPLAY) and there
is another request to add support for special kinds of X authentication. When
implementing that we could easily pass an envvar like PINENTRY_USER_DATA all the
way down from gpgme via gpg/gpgsm and gpg-agent to pinentry. Then you could let
your custom pinentry act on that variable and do whatever you want.

Would that help?

-----BEGIN PGP SIGNED MESSAGE-----

What about a way to pass information from thye caller down to
pinentry?

We have this kind of stuff already for some variables (e.g. DISPLAY)
and there is another request to add support for special kinds of X
authentication. When implementing that we could easily pass an
envvar like PINENTRY_USER_DATA all the way down from gpgme via
gpg/gpgsm and gpg-agent to pinentry.

That is definitly a very useful feature.

Then you could let your custom pinentry act on that variable and do
whatever you want.

Would that help?

Yes, it would, I think: My own pinentry would first look at the
environment variable and, unless called by the webmail application,
would immediately exec() the original pinentry.

But I see one disadvantage: I'd have to make my own pinentry the
default one for the _whole_ installation at _compile_ time instead of
keeping the original one as default. This means that only one
application can hook its own pinentry into one GnuPG installation this
way.

No problem for me, the solution you proposed seems to solve my problem
completely and makes solving some other, minor problems easier for me,
too; thus _please_ implement it soon. :-)

Thank you very much!


Rainer Perske, Zentrum für Informationsverarbeitung, Universität Münster
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (AIX)

iQDVAwUBRlHosc9UbnbjB8C5AQECegX/VWR24GaEQtLPhHOWqXOEU7Fqdt7IOCwk
PIDpsAyLDRGfSpy/43TUZ17Lni7208WvSdAeKXgB0/sVVxBPC9Z4Xs3hojLef7SK
+k3eDPu4qEOAFuwl+C10qheikPd1Sj08H6CCwVOk8loqgXyeVMhTJNXxfvGGZkcx
xQ3wgm4/IYAepTbn+3pGJVeP/J8NAT6ytSsxA4OTkt67iq7Gw0qXNKNRiiB8feF+
ZrpjFWNMJesRU2fJi6MGbsYrgbJ3r6AB

bJvM

-----END PGP SIGNATURE-----

werner set Due Date to Nov 25 2007, 1:00 AM.Nov 15 2007, 4:40 PM

I don't understand your the disadvantage point. You can use --pinentry-program
in gpg-agent.conf to use your pinentry wrapper.

-----BEGIN PGP SIGNED MESSAGE-----

I don't understand your the disadvantage point. You can use
--pinentry-program in gpg-agent.conf to use your pinentry wrapper.

You are right, there is no real disadvantage point. (I did not realize
that the same pinentry wrapper could be used not to add only one own
pinentry but to add any number of own pinentries (if such a rare case
should ever happen), defaulting to calling the original one.)

As said before: Your idea of passing an envvar like PINENTRY_USER_DATA
all the way down from gpgme via gpg/gpgsm and gpg-agent to pinentry
would help me very much, _please_ implement it :-)

Thank you very very much in advance


Rainer Perske, Zentrum für Informationsverarbeitung, Universität Münster
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (AIX)

iQDVAwUBRz+XPc9UbnbjB8C5AQHfAAYAinFuzGC2TKkOvDc8+UxOL5hGzOUwEy2j
B2ChYPuB7GsLQXdD+CCNCM2h3hH9zt5rzL5fvAN9W5K+Yic0ecTOLRelVic0oB92
ue7FfWlDbnDR2jOA2dKpn/zFPowj54wYF80X+fgkhdnFxXlv8kZUHJMAYPsZgna/
Bz34bQx/9lq42mNJTbjPZMaUnt+/YMLP0x9H4bXCkh7nyf/qogA1t79U3GC12srt
Tgj4VZeS5D6lcI9ysjZpoIgzu+h6KxDs

6tpZ

-----END PGP SIGNATURE-----

werner closed this task as Resolved.Dec 18 2007, 9:54 AM
werner claimed this task.
werner removed a project: In Progress.

This has been implmemented with 2.0.8rc1. 2.08 will be release later the week.