On 04/21/17 at 04:07pm, David Phillips wrote:
This fixes a bug I encountered with a GPG keyring where the key id used to locate a key in the keyring was ambiguous within my keychain.
This commit ensures that all valid return values are checked to catch this and related error cases rather than incorrectly taking an error case to mean the key was found, since this is rarely going to be the case. --- lib/libalpm/be_package.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/lib/libalpm/be_package.c b/lib/libalpm/be_package.c index 7e8b7920..1891fa5a 100644 --- a/lib/libalpm/be_package.c +++ b/lib/libalpm/be_package.c @@ -754,10 +754,21 @@ int SYMEXPORT alpm_pkg_load(alpm_handle_t *handle, const char *filename, int ful alpm_list_t *k; for(k = keys; k; k = k->next) { char *key = k->data; - if(_alpm_key_in_keychain(handle, key) == 0) { - if(_alpm_key_import(handle, key) == -1) { + switch(_alpm_key_in_keychain(handle, key)) { + case 1: + /* key is known; proceed */ + break; + case 0: + /* key is unknown; attempt to import */ + if(_alpm_key_import(handle, key) == -1) { + fail = 1; + } + break; + case -1: + /* error finding key in keychain */ + default: fail = 1;
Just below this, an error message is printed if fail is true, saying that the key is missing. If we got a generic code, that may not be the case, and is the exact opposite of the problem that prompted patch. I'm wondering if this is necessary at all, though. This bit of code is specifically just for importing missing keys. Any other significant errors should be caught during the actual validation attempt, where we already provide the actual gpg error message. If the gpgme segmentation fault is no longer an issue, do we gain anything other than bailing out slightly sooner by adding the extra check and complexity for printing an appropriate error message here?
- } + break; } } FREELIST(keys); -- 2.12.2