unwrapping a PKCS#7 SignedData part without verifying the signature about gmime

[jstedfast]

I think this seems like a reasonable feature to have.

[jstedfast]

unwrap, extricate, extract, or unseal... I was thinking unencapsulate but apparently that's not a word ;-) It's also kinda long...

I'm leaning toward unwrap or extract. Internally I've used the word extract in some comments.

I was thinking of adding a GMimeVerifyFlags, but then I'd have to return NULL for the GMimeSignatureList which is the same as the value returned on error, so that feels like a bad API.

Unfortunately, adding a new virtual method on GMimeCryptoContext would break API/ABI, so this would be a good candidate for a GMime v4.0 API.

[dkg]

I prefer unwrap over extract, i think, but i'd be happy with either.

As for the API/ABI break, i think i'm a bit confused:

adding a new value for GMimeVerifyFlags seems like it would be a subtle API/ABI break itself (see #71).

I was unaware that adding a new virtual method breaks API! is that code really part of the practical API/ABI surface? Is the idea that some other GMimeCryptoContext implementation out there might break because it can't fulfill that API? Do we know of other GMimeCryptoContext implementations?

Also: PKCS#7 SignedData will only ever be handled by GMimeApplicationPkcs7Mime objects, not by generic GMimeCryptoContext -- does it need to use the CryptoContext at all?

[jstedfast]

Adding new VerifyFlags doesn't break API/ABI.

Adding a new virtual method breaks ABI because the struct size changes.

Balsa implements their own GMimeCryptoContext subclasses (or used to). I hope they don't find the need to anymore now that GMime uses GpgME.

GMimeApplicationPkcs7Mime uses GMimeCryptoContext to do encryption/decryption/signing/verifying/etc and should also use it to unwrap the signed-data since it would use GpgME to do so. The point of GMimeCryptoContext is to allow consumers of GMime to plug in their own crypto backend (which, admittedly, is less needed now that GMime uses GpgME... but it's there for historical reasons).

[dkg]

When i say that a new VerifyFlag breaks API, I'm using "API" as a description of the semantic behavior of a piece of software with respect to its stated programming interface.

While a new VerifyFlag doesn't change the structure of the API, it does change the semantics, particularly when that flag is supplied.

#71 describes why a new flag might subtly alter the programmer's expectation of the interface, which is an API break (although one not detectable by standard API verification techniques).

Anyway, if this can't be done without a API or ABI break, so be it :) -- i just wanted to explore the range of options we have available.