[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 |
-----BEGIN PGP SIGNED MESSAGE-----
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 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
_______________________________________________
Pan-devel mailing list
Pan-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-devel
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEESqvC39GTzDgsgynjy2RXY2/wKDIFAmFmEVEACgkQy2RXY2/w
KDKjEAf/eamItUst6V472cH+uM4mPsFa64mgMIvhYb0bcSqwTBqdjuXylaLmc6XE
HFIoH4rwgmehqLNzMstMnu+yOJRLf2Hzz75tNgG0yLDso7htPE2EgKiuu9DnEFuX
rBgXtgL9+Gria0YLEJsMOWSMcePgcZMUFV9T8yjjzDFOQHJxTrXmtr/TwFwFNlkw
gVe9LP9FG4ILnQjIBr1GEmy6Nc7Sk9vCcjAfO6fnLQCRzS0gVRPDs3+M0MFn0TmK
hdBVWKHb+jltQ5EIFxfwSCtFgTIRxc0cfu6qYbykFkKCoc3zgVmKZ77Y7xUIP4PA
Tt4Aj1rLPl0EmZuEViphQ/Nk2lYJJg==
=Fltg
-----END PGP SIGNATURE-----
ostroffjh@users.sourceforge.net.asc
Description: application/pgp-keys