RFE: use fingerprints instead of key IDs internally #1549
Labels
Comments
|
Yeah, started down this road in 2017 but ran into hidden obstacles or out of steam. Or both. |
|
At the very least we can check the fingerprint of a public key against those of its signatures. |
|
This will still need to be changed even if #1935 is fixed. |
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Sep 6, 2022
Commit 4bbeec1 "fixed" an old terminology confusion about keyid vs fingerprint, but in the process broke pgpPubkeyFingerprint() for any external callers, as it now only feeds on decoded packets whereas before it did the decoding by itself. Add the decoding step back to the public function to make it usable outside rpmpgp_internal.c again, retrieving a fingerprint seems like an useful (public) API to have. This is kind of a regression fix in that prior to commit 4bbeec1 pgpPubkeyFingerprint() returned meaningful data to the outside caller and afterwards it didn't, however that commit broke the API anyhow so it's kinda complicated. Maybe we should just call it a bugfix and be done with it. Related to rpm-software-management#1549
pmatilai
added a commit
that referenced
this issue
Sep 6, 2022
Commit 4bbeec1 "fixed" an old terminology confusion about keyid vs fingerprint, but in the process broke pgpPubkeyFingerprint() for any external callers, as it now only feeds on decoded packets whereas before it did the decoding by itself. Add the decoding step back to the public function to make it usable outside rpmpgp_internal.c again, retrieving a fingerprint seems like an useful (public) API to have. This is kind of a regression fix in that prior to commit 4bbeec1 pgpPubkeyFingerprint() returned meaningful data to the outside caller and afterwards it didn't, however that commit broke the API anyhow so it's kinda complicated. Maybe we should just call it a bugfix and be done with it. Related to #1549
pmatilai
added a commit
to pmatilai/rpm
that referenced
this issue
Sep 16, 2022
Commit 4bbeec1 "fixed" an old terminology confusion about keyid vs fingerprint, but in the process broke pgpPubkeyFingerprint() for any external callers, as it now only feeds on decoded packets whereas before it did the decoding by itself. Add the decoding step back to the public function to make it usable outside rpmpgp_internal.c again, retrieving a fingerprint seems like an useful (public) API to have. This is kind of a regression fix in that prior to commit 4bbeec1 pgpPubkeyFingerprint() returned meaningful data to the outside caller and afterwards it didn't, however that commit broke the API anyhow so it's kinda complicated. Maybe we should just call it a bugfix and be done with it. Related to rpm-software-management#1549 (cherry picked from commit dc9e816)
pmatilai
added a commit
that referenced
this issue
Sep 20, 2022
Commit 4bbeec1 "fixed" an old terminology confusion about keyid vs fingerprint, but in the process broke pgpPubkeyFingerprint() for any external callers, as it now only feeds on decoded packets whereas before it did the decoding by itself. Add the decoding step back to the public function to make it usable outside rpmpgp_internal.c again, retrieving a fingerprint seems like an useful (public) API to have. This is kind of a regression fix in that prior to commit 4bbeec1 pgpPubkeyFingerprint() returned meaningful data to the outside caller and afterwards it didn't, however that commit broke the API anyhow so it's kinda complicated. Maybe we should just call it a bugfix and be done with it. Related to #1549 (cherry picked from commit dc9e816)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Fingerprints are guaranteed to be unique, where as key IDs are not.
The text was updated successfully, but these errors were encountered: