[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jack
Subject: Re: [Pan-devel] On gmime signing: Was: compile error from current git master head
Date: Tue, 12 Oct 2021 18:50:57 -0400

Hash: SHA256

Lets try that signing again.

On 2021.10.12 18:42, Jack via Discussions of Pan source code hacking. wrote:
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 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 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/ fails on one of the gmime calls because gpg_ctx (defined as " GMimeCryptoContext *gpg_ctx;" in 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 ( and, and their .h files.) At the very end of, 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.


Pan-devel mailing list


Description: application/pgp-keys

reply via email to

[Prev in Thread] Current Thread [Next in Thread]