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

[Justus Winter]

Ben Kibbey <bjk at luxsci.net> writes:

> On Tue, Aug 09, 2016 at 10:59:41AM +0200, Justus Winter wrote:
>> Ben Kibbey <bjk at luxsci.net> writes:
>> 
>> > * common/init.c (init_common_subsystems): Initialize libgcrypt.
>> 
>> Merged, thanks!
>
> Noticed the mention of header files and GPG_ERR_SOURCE on xmpp so I
> revised the original patch to move gcrypt.h after everything else and
> also coding style. Should apply after reverting the previous one.

Common, don't flip flop on that one.  All the programs have an insane
amount of initialization boilerplate, and your patch reduces that a tiny
bit, by moving some initialization of a common subsystem that happens
everywhere to 'init_common_subsystem', which sounds perfectly
reasonable imho.

Also, xmpp is nice, but the discussion is already lost to history, so
let's quickly recap the potential problems, and then have a proper
discussion here.

I remember three things, 1/ the order of includes may be important, 2/
some magical way that the error source is set that your change may have
changed accidentally, 3/ i18n.h being included in common/init.c being a
problem, 4/ init_common_subsystems might be running as root.

Did I miss anything?

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.

2/ Likewise.  It might be convenient, but it sounds too magical to be
good.  Explicit is better than implicit.

3/ I don't understand that point at all.

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
be the case if one runs gnupg as root, and I don't see why we should/how
we could protect the user in this case, or it is not run as root in the
first place, and then this point is moot.


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
side-effects, I believe we should make sure that such side-effects
cannot happen instead of reverting that change.

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/20160810/19c21a4a/attachment-0001.sig>