Consider merging exact key feature

[duritong]

GPG has the issue that finding a key for bar@example.com, also returns a key
for foobar@example.com.
This can be restricted by adding <> around the address: bar@example.com.
Hence GPGME::Key.find_exact simply wraps <> around each email you passed to the method
and delegates the rest to GPGME::Key.find

This is quite a common use case and I used this already in a couple of projects. So it would be nice to have it upstream, to not always re-add this stuff. And just a seperate gem for that code part would be silly.

There was some discussion about it regarding the complexity with @mrsimo mrsimo#3 (comment)

What do you think? I can improve it if you have any suggestions or dislikes regarding the code structure.

[ueno]

well, though you seem to have use cases, I'm still not convinced that the new method will improve usability.

actually:
find(:public, "<bar@example.com>")
is written shorter than:
find_exact(:public, "bar@example.com")
could you provide some examples? btw we may want to improve the doc of the find method, according to "How to Specify a User Id" section of gpg manual, which even describes different "exact" matching rules...

[duritong]

While I agree it is shorter, you will often have different kind of inputs (keyid, input from a config file, from a user) to the find method. So with what I ended up so far, is to the same thing I do in the find_exact method right before the find method and if I had that at multiple places write a wrapper for it, which is exactly what the find_exact is.

So my point is that I have the following options:

• copy that wrapper in whatever project I need it
• write a wrapper gem for gpgme (which is since the api change not anymore that necessary and would probably only contain that single short method)
• give it upstream as other users might have that use case as well.

I can live with each of them, but imho the last one is the nicest one. But if you think that ruby-gpgme gets to messy with that, I will go with one of the other options.

Improving documentation would be good, because a lot of tools are just passing the plain email-address and so might end up encrypting things with the wrong key.

[ueno]

OK, that makes sense. However, I feel the method itself a bit too specific. I'd suggest:

• extend find method to accept matching style like find(:public, "bar@example.com", :match => :email)
• (optional) rename find_exact to find_by_email, and add find_by_user_id, find_by_dn, find_by_issuer_dn, etc.

How does this sound?

[duritong]

Sounds good to me. Will do such an implementation.