On Tue 2019-10-01 12:43:35 +0000, Jeffrey Stedfast wrote:
I think GMIME_DECRYPT_NO_VERIFY is a fantastic idea for solving your problem while at the same time making the least invasive changes. Since it was such a simple change, I've already committed a patch for this feature.
Sweet, thanks! Any chance you might consider releasing a roll-up minor release of GMime with this change, the fix for #60, and the other outstanding fixes (and maybe the textual cleanup in https://github.com/jstedfast/gmime/pull/62) ? If this is released as 3.2.4, and code is compiled against 3.2.4 that uses this flag, i note that if that code is then running against an earlier version of gmime, the flag will be ignored. That's a little bit weird -- i can't know whether it will be respected without forcing the runtime to be at least as recent as the compile-time build -- but i also think it's relatively harmless, since it's mainly intended as a performance optimization. It's a "non-critical" flag, if you will. All that said, i can imagine a new flag being added in the future, which older versions of GMime won't know how to interpret but it would be unsafe to ignore it -- a "critical" flag. I wonder whether it's worth reserving some bits in the flag field that GMime should explicitly fail on if it sees them set but doesn't know what they mean. That way, when future flags are proposed, we can decide whether they're "critical" or not, and allocate them into the appropriate part of the flag space. To do that right, i think that GMime would need to ensure that all of the currently-unallocated "critical" flag bits are 0 during a requested decryption. If any of them are set to 1, the decryption could fail with an error like "critical flag X set but unsupported". Does that make sense as a form of defensive API design?
dkg wrote:There is still a disparity between wall-clock and CPU time which i'll look into further
For the record, i think this disparity is due to gpgme double-forking
its spawned GnuPG instances. After they're orphaned, their CPU totals
aren't counted as descendents of the main process, so bash's time
builtin can't account for them.
--dkg
Attachment:
signature.asc
Description: PGP signature