[PATCH] tools/gpgconf.c (main): Initialize libgcrypt.

[Justus Winter]

Werner Koch <wk at gnupg.org> writes:

> On Wed, 10 Aug 2016 14:36, justus at g10code.com said:
>
>> 1/ If the order is important, I don't like that, and we should fix
>> that.  That sounds like the code is trying to be clever with the
>> preprocessor.
>
> config.h must always be the first header becuase it controls features

Sure, but other than that.

> provided by the system headers.  The latter SHOULD prepend application
> specific headers to ease debugging.
>
> [ some magical way that the error source is set that your change ..]
>> 2/ Likewise.  It might be convenient, but it sounds too magical to be
>> good.  Explicit is better than implicit.
>
> The tricky part is the GPG_ERR_SOURCE which has a default unless set in
> another way.  In general not a problem but sometimes things get messed
> up.

And did the commit in question change that?

(I still don't like it.)

> [i18n.h being included in common/init.c]
>> 3/ I don't understand that point at all.
>
> Pretty easy: This requires linking to libintl even for tools which have
> no need for it.

If we want to avoid that, then we could simply avoid translating the
error message.

>> 4/ Is that actually a problem?  I just checked, none of the gnupg
>> components on my Debian/Linux system are suid root, so that could only
>
> On Linux this is not a problem as long as the amount of mlocked memory
> is small enough.  On other OSes you may want to suid the application to
> take advantage of mlocked memory.

Right, other Unices.  However, is that really still a problem?  We even
allow unpriviliged users to use small amounts of wired memory on Mach
these days.

>> I believe that the change we merged looks very reasonable (hence I
>> merged it), and such a change should not be able to have subtle
>> side-effects like the ones Werner fears.  If there are weird implicit
>
> The gcry_check_version is important and chould be done explicit.

And we didn't remove that, we just moved it.

On the other hand, if we were to revert this change, then the following
programs are using init_common_subsystems without properly initializing
gcrypt:

agent/preset-passphrase.c
common/t-recsel.c
dirmngr/dirmngr_ldap.c
tools/gpg-connect-agent.c
tools/gpg-wks-client.c
tools/gpg-wks-server.c
tools/gpgconf.c
tools/gpgtar.c

This actually strengthens my point.  The initialization is so complex,
that even you got it wrong, and noone knows the code as well as you.  We
need to make this simpler.

Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20160811/986930f1/attachment-0001.sig>