Integrate benburkert's interesting fixes + some test fixes #3
Conversation
(cherry picked from commit 161b684)
Having the GPG_AGENT_INFO environment variable present while runinng the tests interfers with testing. So we unset this specific ENV at the very beginning of testing.
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
|
I just pushed a new additional method I need, and a small typo fix... |
| keys_or_names = [""] if keys_or_names.nil? || (keys_or_names.is_a?(Array) && keys_or_names.empty?) | ||
| find( | ||
| secret, | ||
| [keys_or_names].flatten.collect{|k| if k =~ /.*@.*/ && !(k =~ /<.*@.*>/) then "<#{k}>" else k end }, |
There was a problem hiding this comment.
I´m pretty concerned with this line. I need a lot of brain power to get to understand it, the 1 letter variable with two regexp´s and a ternary make it pretty hard.
Also, I´m not sure if this kind of method has to be part of the API. after all it´s 'normal' gpg behavior, so I have the feeling it's the user who should be passing emails in <> to the normal find instead. I'd probably add a comment on the find method explaining it, though.
There was a problem hiding this comment.
The issue is the following:
Given you have 2 keys: one for bar@example.com and one for foobar@example.com. If you do a gpg --list-keys bar@example.com you get both keys. If you do gpg --list-keys '<bar@example.com>' you get only one key. To do the lookup with angle brackets is actually the solution that gpg developers recommend. A lot of existing tools assume that looking up a key for an address just returns one key or post-process the found keys and sort out the ones that don't match the exact pattern or are expired. Querying the keys with '<>' around means for example that you have only to sort out expired keys, but not think about possible other keys with totally unrelated keys. Imagine a key for a@example.com or o@example.com, which will likely return multiple times different keys.
I implemented that find_exact method in a couple of projects over and over again. This is also one reason why I started with rugpg. But given your work on ruby-gpgme, this would be the only method that is actually left over and which is a common use case for a lot of projects. Hence I propose and would love to see a direct integration in ruby-gpgme.
I agree that I tend to write compact rather than readable code. If you prefer, I could propose a more "readable" but less compact version.
There was a problem hiding this comment.
Some in details about that can be found here: http://old.nabble.com/key-lookup-strategies-td30325738.html
Hi
I integrated some other changes by benburkert that seemed to be interesting and are also required to get the tests working again.
Thanks
duritong