Re: [Pan-devel] On gmime signing: Was: compile error from current git master head

[Jack]

Well, it turns out I was having problems testing this because my own  
gnupg configuration was messed up.   I have finally gotten that fixed,  
and just posted a test message to comp.security.pgp.test.  The article  
got posted, and I can see (in Pan) that it has an attachment  
signature.asc, but I can't actually see the signature.  I have uploaded  
my key to keyservers.ubuntu.com.  In case it matters, I have signed  
this message and also attached my public key.  Any ideas whether I'm  
missing something, or is there still something missing from Pan?


On 2021.09.21 20:43, Jack via Discussions of Pan source code hacking.  
wrote:
> I'm keeping the threading, but dropping the context.  I think I found  
> a clue here to why gpg signing is broken.
>
> The call to message_add_signed_part in pan/usenet-utils/mime-utils.cc  
> fails on one of the gmime calls because gpg_ctx (defined as "  
> GMimeCryptoContext *gpg_ctx;" in gpg.cc in the same directory is NOT  
> a gmime crypto context.
>
> In terms of why that is the case, gpg_ctx seems to appear only in  
> those two files (gpg.cc and mime-utils.cc, and their .h files.)  At  
> the very end of gpg.cc, there is:
>
>   void init_gpg()
>   {
> //    gpg_ctx = g_mime_gpg_context_new (request_passwd, "gpg2");
>     if (!gpg_ctx) gpg_inited = false; else gpg_inited = true;
> //     
> g_mime_gpg_context_set_auto_key_retrieve(GMIME_GPG_CONTEXT(gpg_ctx),true);
> //     
> g_mime_gpg_context_set_always_trust(GMIME_GPG_CONTEXT(gpg_ctx),false);
> //    g_mime_gpg_context_set_use_agent(GMIME_GPG_CONTEXT(gpg_ctx),  
> false);
>   }
>
> which looks to me like nobody actually ever figured out how to make  
> this work, and commented out older attempts.  (No, I have not yet  
> gone through git logs to see the actual history of this file.)   I  
> see that the second line tests for gpg_ctx, but the only place it  
> ever gets set is the commented out first line, so it can't possibly  
> succeed.  This is clearly going to take a good bit more digging - and  
> I just hope the presence of "gpg2" is for gnupg version 2, and  
> doesn't reflect on the gmime2 -> gmime3 migration.
>
> Jack