Provide verify_result from ctx

[jkraemer]

Provide verify_result from ctx

[morten-andersen]

Hi duckdalbe,

A quick answer: Yes I think you are right. If I understand the GPGME documentation correct we are actually not checking the signatures at all in that code.

We should iterate the signatures in the VerifyResult (retrieved via the verify_result() as you point out) and check the validity of each as we do in `GpgmeHelper#sign_verify().

I think it will be appropriate to throw an exception in case a signature verification fails, as signature verification only happens when the caller has explicitly set the verify option.

Maybe I will have time to look into fixing this with appropriate test case in the coming weekend.

Thanks for pointing it out.

Best Regards
Morten

[duckdalbe]

Hi Morten,

thank you for the quick reply!

Actually GPGME does check the signature, but mail-gpg doesn't provide a way to look at the result.

In my eyes it would be most helpful to simply attach the verify_result to the mail or mail-part, so one could e.g. do something like this:

if mail.signature.valid?
  logger.info("Good signature: #{mail.signature}")
else
  logger.error("Invalid signature: #{mail.signature}, stopping processing!")
end 

Throwing exceptions on invalid signatures could be a problem when handling multipart-messages: how could one decide which part has the invalid signature and which has the valid signature or isn't signed at all? (In my experience unfortunately this happens quite often when people use the "inline-format".)

Best wishes!

[jkraemer]

I just gave this a try, please have a look at the verify_result_passing branch and tell me what you think

[jkraemer]

I would appreciate if anybody could come up with a test case checking the actual behavior for an encrypted/signed message where the signature is invalid. I think gpgme itself will throw an error in this case...

[duckdalbe]

Works good for encrypted pgp/mime-messages, cool!

Actually you could attach the signatures rather than the verify_result itself, there's nothing more to the latter than the signatures. But that's only cosmetics.

How about the code to verify non-encrypted messages?

[jkraemer]

I updated the feature branch (and rebased it onto current master) so the verify_result member variable of Mail::Message is set to contain the verification result when #signature_valid? is called.

About pulling out the signatures - yes I also was not sure about whether to do this or not, but I feel it might be more robust to just pass through the complete wrapper object (i.e. gpgme might add any additional stuff in there and we would automatically handle it).

[duckdalbe]

Finally I found some time to look at it and I found it working well!

For me it feels a little bit confusing to have to send decrypt(verify: true) to encrypted messages and receive a message with the signature-mime-part stripped, while I have to send signature_valid? to signed but unencrypted messages and separate the plain body from the signature-mime-part manually.

From a "user"-perspective it might be less surprising to send e.g. verify() to the unencrypted message and also receive a clone of the message stripped by the signature.

[jkraemer]

yes this feels a little bit inconsistent, however I am not entirely sure how to fix this. For now I added signature verification of inline signed messages and merged the branch to master.

[duckdalbe]

How about copy = mail.verify(), where copy would be stripped by the signature but enriched by verify_result.

That would be analogous to decrypt() and least surprising, I think.

[duckdalbe]

BTW: Yay for the verification of "inline"-signatures!

[jkraemer]

good idea, I implemented it like this now :)