folkslinux
/
rpm
mirror of https://github.com/rpm-software-management/rpm.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
rpm/lib/rpmvs.c

594 lines
15 KiB
C
Raw Normal View History

Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
#include "system.h"
Handle system verify level centrally and internally in rpmvs This doesn't change immediate functionality at all but needed later for consistent behavior from different callers, who don't want to deal with figuring out the system verification level separately, only want to tell the vfy thing whether to use the system policy or not.
2018-05-08 19:21:53 +08:00
#include <pthread.h>
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
#include <rpm/rpmkeyring.h>
Handle system verify level centrally and internally in rpmvs This doesn't change immediate functionality at all but needed later for consistent behavior from different callers, who don't want to deal with figuring out the system verification level separately, only want to tell the vfy thing whether to use the system policy or not.
2018-05-08 19:21:53 +08:00
#include <rpm/rpmmacro.h>
#include <rpm/rpmlog.h>
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
#include "lib/rpmvs.h"
#include "rpmio/digest.h"
#include "debug.h"
struct rpmvs_s {
struct rpmsinfo_s *sigs;
int nsigs;
Handle dynamic reallocation in rpmvsAppend() Preallocate a little but (for now) so little that reallocation always takes place so it doesn't rot while surroundings still change.
2017-05-22 17:32:32 +08:00
int nalloced;
Always honor vsflags when appending new items to verify set Remember the vsflags passed to us in rpmvsCreate(), check for disabled in rpmvsAppend() instead.
2018-04-05 19:10:37 +08:00
rpmVSFlags vsflags;
Store digest bundle handle in verify set as part of initialization Passing different digest bundles to individual rpmvsInitDigests() and rpmvsVerifyItems() calls would not make any sense, it would simply fail to perform anything meaningful. Eliminating that possibility is the only sane thing to do.
2018-04-06 19:12:48 +08:00
rpmDigestBundle bundle;
Store keyring handle in verify set as part of creation Passing different keyrings to individual calls of rpmvsVerifyItems() on the same set just would not make any sense, eliminating the possibility is the only sane thing. Part of create instead of init as keyring lifetimes are longer than verify sets.
2018-04-06 19:17:25 +08:00
rpmKeyring keyring;
Rename vslevel back to vfylevel everywhere, sigh rpmtsVSFlags() doesn't actually control what happens with the package verification that vslevel/vfylevel relates to, it controls the verification that happens on header/package read. We actually need a separate API for controlling the flags that control the operation that verify level is associated with, so to avoid total confusion as to what is what... paving way for adding rpmtsVfyFlags(), but that's not added in this commit - rename only.
2018-06-27 16:22:41 +08:00
int vfylevel;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
};
Split tag-specific information out of rpmsinfo struct Commit d809fd525228f015104bf35dfd593a8081debeb3 lumped everything into rpmsinfo but things like tag data type and count don't belong there, it's not interesting once the tag data has been validated. Whether the tag value belongs there is another question, leaving it for now at least as it's used for output in signature checking. No functional changes intended.
2017-05-11 15:40:28 +08:00
struct vfytag_s {
rpmTagVal tag;
rpmTagType tagtype;
rpm_count_t tagcount;
rpm_count_t tagsize;
};
static const struct vfytag_s rpmvfytags[] = {
{ RPMSIGTAG_SIZE, RPM_BIN_TYPE, 0, 0, },
{ RPMSIGTAG_PGP, RPM_BIN_TYPE, 0, 0, },
{ RPMSIGTAG_MD5, RPM_BIN_TYPE, 0, 16, },
{ RPMSIGTAG_GPG, RPM_BIN_TYPE, 0, 0, },
{ RPMSIGTAG_PAYLOADSIZE, RPM_INT32_TYPE, 1, 4, },
{ RPMSIGTAG_RESERVEDSPACE, RPM_BIN_TYPE, 0, 0, },
{ RPMTAG_DSAHEADER, RPM_BIN_TYPE, 0, 0, },
{ RPMTAG_RSAHEADER, RPM_BIN_TYPE, 0, 0, },
{ RPMTAG_SHA1HEADER, RPM_STRING_TYPE, 1, 41, },
{ RPMSIGTAG_LONGSIZE, RPM_INT64_TYPE, 1, 8, },
{ RPMSIGTAG_LONGARCHIVESIZE, RPM_INT64_TYPE, 1, 8, },
{ RPMTAG_SHA256HEADER, RPM_STRING_TYPE, 1, 65, },
{ RPMTAG_PAYLOADDIGEST, RPM_STRING_ARRAY_TYPE, 0, 0, },
Implement support for alternative (uncompressed) payload digest During build, also calculate a digest for the uncompressed payload data and add to packages. On verify side this is equivalent to the existing payload digest (through sharing the same disabler), which allows either one to be used for verification. This means deltarpm and similar don't need to recompress the data which is both expensive and error-prone due to minor differences in compressed stream despite the actual data being identical. Add a testcase for the basic behavior and update other test output expectations where necessary.
2019-10-03 19:58:11 +08:00
{ RPMTAG_PAYLOADDIGESTALT, RPM_STRING_ARRAY_TYPE, 0, 0, },
Split tag-specific information out of rpmsinfo struct Commit d809fd525228f015104bf35dfd593a8081debeb3 lumped everything into rpmsinfo but things like tag data type and count don't belong there, it's not interesting once the tag data has been validated. Whether the tag value belongs there is another question, leaving it for now at least as it's used for output in signature checking. No functional changes intended.
2017-05-11 15:40:28 +08:00
{ 0 } /* sentinel */
};
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
struct vfyinfo_s {
rpmTagVal tag;
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
int sigh;
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
struct rpmsinfo_s vi;
};
static const struct vfyinfo_s rpmvfyitems[] = {
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMSIGTAG_SIZE, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_OTHER_TYPE, 0,
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
(RPMSIG_HEADER|RPMSIG_PAYLOAD), 0, 0, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMSIGTAG_PGP, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_SIGNATURE_TYPE, RPMVSF_NORSA,
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
(RPMSIG_HEADER|RPMSIG_PAYLOAD), 0, PGPPUBKEYALGO_RSA, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMSIGTAG_MD5, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_DIGEST_TYPE, RPMVSF_NOMD5,
Detach rpm's hash algorithm values from PGP hash algorith values At this point this is quite literally merely a symbolic change, as values from PGP hash algo are assumed equal to RPM hash algos, but it's a necessary first step to supporting hashes not included in RFC-4880. Fixes: #1899
2022-02-24 20:26:46 +08:00
(RPMSIG_HEADER|RPMSIG_PAYLOAD), RPM_HASH_MD5, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMSIGTAG_GPG, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_SIGNATURE_TYPE, RPMVSF_NODSA,
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
(RPMSIG_HEADER|RPMSIG_PAYLOAD), 0, PGPPUBKEYALGO_DSA, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMSIGTAG_PAYLOADSIZE, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_OTHER_TYPE, 0,
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
(RPMSIG_PAYLOAD), 0, 0, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMSIGTAG_RESERVEDSPACE, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_OTHER_TYPE, 0,
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
0, 0, 0, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMTAG_DSAHEADER, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_SIGNATURE_TYPE, RPMVSF_NODSAHEADER,
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
(RPMSIG_HEADER), 0, PGPPUBKEYALGO_DSA, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMTAG_RSAHEADER, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_SIGNATURE_TYPE, RPMVSF_NORSAHEADER,
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
(RPMSIG_HEADER), 0, PGPPUBKEYALGO_RSA, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMTAG_SHA1HEADER, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_DIGEST_TYPE, RPMVSF_NOSHA1HEADER,
Detach rpm's hash algorithm values from PGP hash algorith values At this point this is quite literally merely a symbolic change, as values from PGP hash algo are assumed equal to RPM hash algos, but it's a necessary first step to supporting hashes not included in RFC-4880. Fixes: #1899
2022-02-24 20:26:46 +08:00
(RPMSIG_HEADER), RPM_HASH_SHA1, 0, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMSIGTAG_LONGSIZE, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_OTHER_TYPE, 0,
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
(RPMSIG_HEADER|RPMSIG_PAYLOAD), 0, 0, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMSIGTAG_LONGARCHIVESIZE, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_OTHER_TYPE, 0,
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
(RPMSIG_HEADER|RPMSIG_PAYLOAD), 0, 0, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMTAG_SHA256HEADER, 1,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_DIGEST_TYPE, RPMVSF_NOSHA256HEADER,
Detach rpm's hash algorithm values from PGP hash algorith values At this point this is quite literally merely a symbolic change, as values from PGP hash algo are assumed equal to RPM hash algos, but it's a necessary first step to supporting hashes not included in RFC-4880. Fixes: #1899
2022-02-24 20:26:46 +08:00
(RPMSIG_HEADER), RPM_HASH_SHA256, 0, }, },
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
{ RPMTAG_PAYLOADDIGEST, 0,
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
{ RPMSIG_DIGEST_TYPE, RPMVSF_NOPAYLOAD,
Detach rpm's hash algorithm values from PGP hash algorith values At this point this is quite literally merely a symbolic change, as values from PGP hash algo are assumed equal to RPM hash algos, but it's a necessary first step to supporting hashes not included in RFC-4880. Fixes: #1899
2022-02-24 20:26:46 +08:00
(RPMSIG_PAYLOAD), RPM_HASH_SHA256, 0, }, },
Implement support for alternative (uncompressed) payload digest During build, also calculate a digest for the uncompressed payload data and add to packages. On verify side this is equivalent to the existing payload digest (through sharing the same disabler), which allows either one to be used for verification. This means deltarpm and similar don't need to recompress the data which is both expensive and error-prone due to minor differences in compressed stream despite the actual data being identical. Add a testcase for the basic behavior and update other test output expectations where necessary.
2019-10-03 19:58:11 +08:00
{ RPMTAG_PAYLOADDIGESTALT, 0,
{ RPMSIG_DIGEST_TYPE, RPMVSF_NOPAYLOAD,
Detach rpm's hash algorithm values from PGP hash algorith values At this point this is quite literally merely a symbolic change, as values from PGP hash algo are assumed equal to RPM hash algos, but it's a necessary first step to supporting hashes not included in RFC-4880. Fixes: #1899
2022-02-24 20:26:46 +08:00
(RPMSIG_PAYLOAD), RPM_HASH_SHA256, 0, 1, }, },
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{ 0 } /* sentinel */
};
Start separating verify item description from its result Add internal API to get a textual description of signature/digest, use where appropriate for formatting the verbose messages.
2017-05-24 16:20:35 +08:00
static const char *rangeName(int range);
Separate sig/dig verify results from verbose error messages Add and use an internal helper for formatting the verbose messages from callbacks, this gives us nicer and more uniform messages for data that failed to initialize at all. It's also ends up involving more rasprintf()'s and whatnot per result but that can be tuned later.
2017-05-24 17:17:46 +08:00
static const char * rpmSigString(rpmRC res);
Remember unfinalized digest context in rpmsinfo struct Less parameters to pass around, the digest context is a rather fundamental part of the sig/dig thing anyway. More importantly this detaches the digest finalization from the actual verification, which allows us to verify later or even multiple times (eg for added keys) without rereading the actual data. No functional changes here though.
2018-04-10 16:24:19 +08:00
static void rpmVerifySignature(rpmKeyring keyring, struct rpmsinfo_s *sinfo);
Bury remaining internal signature API inside rpmvs.c
2017-05-12 18:05:20 +08:00
Change sinfoLookup() to return an index into rpmvfyitems Not supposed to change any behavior, just preparing for the next steps.
2017-05-11 15:18:00 +08:00
static int sinfoLookup(rpmTagVal tag)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
const struct vfyinfo_s *start = &rpmvfyitems[0];
Change sinfoLookup() to return an index into rpmvfyitems Not supposed to change any behavior, just preparing for the next steps.
2017-05-11 15:18:00 +08:00
int ix = -1;
Eliminate "tag" from rpmsinfo struct Signatures are signatures and digests are digests no matter where they come from, fade out the origins to the extent we can. The id for hashable items is of course still derived from the tag and can be backtraced (ditto for the disabler bits) but it's not exactly full anonymity we need either, and eg id being related to the tag could be useful for debugging.
2017-05-15 16:44:47 +08:00
for (const struct vfyinfo_s *si = start; si->tag; si++) {
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
if (tag == si->tag) {
Change sinfoLookup() to return an index into rpmvfyitems Not supposed to change any behavior, just preparing for the next steps.
2017-05-11 15:18:00 +08:00
ix = si - start;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
break;
}
}
Change sinfoLookup() to return an index into rpmvfyitems Not supposed to change any behavior, just preparing for the next steps.
2017-05-11 15:18:00 +08:00
return ix;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
Split out hex validity checking to helper function, enhance Besides testing for valid characters, also test for legal length: always divisible by two, at least sha-1 size.
2017-05-30 15:16:05 +08:00
static int validHex(const char *str, size_t slen)
{
int valid = 0; /* Assume invalid */
const char *b;
/* Our hex data is always even sized and at least sha-1 long */
if (slen % 2 || slen < 40)
goto exit;
for (b = str ; *b != '\0'; b++) {
if (strchr("0123456789abcdefABCDEF", *b) == NULL)
goto exit;
}
valid = 1;
exit:
return valid;
}
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
static void rpmsinfoInit(const struct vfyinfo_s *vinfo,
Streamline digest/signature info initialization rpmsinfoInit() never gets called with an unknown value as it's us calling it based on values in our built-in tables (it used to be different though). In fact it mostly gets called while we're walking the very same table we're then looking up again in rpmsinfoInit()... makes no sense whatsoever. Change the internal API to take the table values directly, and handle the lookup in the only case that needs it (payload digest). Not supposed to change any functionality except make things a little saner and faster too.
2018-04-05 18:58:44 +08:00
const struct vfytag_s *tinfo,
rpmtd td, const char *origin,
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
struct rpmsinfo_s *sinfo)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
rpmRC rc = RPMRC_FAIL;
const void *data = NULL;
rpm_count_t dlen = 0;
Streamline digest/signature info initialization rpmsinfoInit() never gets called with an unknown value as it's us calling it based on values in our built-in tables (it used to be different though). In fact it mostly gets called while we're walking the very same table we're then looking up again in rpmsinfoInit()... makes no sense whatsoever. Change the internal API to take the table values directly, and handle the lookup in the only case that needs it (payload digest). Not supposed to change any functionality except make things a little saner and faster too.
2018-04-05 18:58:44 +08:00
*sinfo = vinfo->vi; /* struct assignment */
Implement configurable, mandatory signature/digest verify level for rpm -K Traditionally rpm has verified whatever digests and signatures are present (unless disabled) but there hasn't been any way to *require* either type of verification, and making it all too easy to fool rpm into accepting a tampered package whose signatures and digests have just been stripped off and content modified. This commit adds support for required verification level, possible levels being "none" (for traditional behavior and default for now), "digest", "signature" and "all" (for both signatures and digests). What it means is that the specified level of validation is required for the entire package file: eg on digest level, both the header and the payload must have been validated with a digest. All digest algorithms are considered equal for this purpose to abstract out version differences: eg all valid rpm packages have *some* digest covering the entire package. Traditionally the only digest covering the payload is the md5sum, but packages built with rpm >= 4.14.0 have a separate payload digest which can be used for the purpose and md5sum disabled (which would also deny install of older packages). Similarly (and more importantly) signatures can now be also required. As a special case, the new payload digest added in 4.14.x is in the main header which, if signed, makes the payload digest signature strength too. Which would make it possible to drop V3 header+payload signatures from package signing (which would make signing much faster) and still have signature strength coverage for the entire package. It's worth noting that when a verification level is active, --nodigest and --nosignature seem to behave sort of counter-intuitively: these disablers tell rpm not to try verification of those items, but the verification level specifies what *must* be verified for a pass, so eg if signature verify level is active, rpm -K --nosignatures will *always fail* because no signatures could be verified. This only implements the "policy" for the rpm -K style signature checking path, installation is not covered yet as that's quite a different beast: we don't want to enforce this at rpmReadPackage() level because of API issues and assumptions (eg you couldn't read a package to discover what key it was signed with, in order to import the key required to successfully verify said package)
2018-04-27 18:27:02 +08:00
sinfo->wrapped = (vinfo->sigh == 0);
sinfo->strength = sinfo->type;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
Preliminaries for reporting non-present verification items Remember RPMRC_NOTFOUND results in verify set, but ignore them in actual results for now. The check for verifiable types never really belonged to rpmsinfoDisabled() as it's a different kind of check, and here we see why - we NEVER want to add non-verifiable elements to verify set, but for the next steps we'll need to handle disabled items as if they were not present - ie NOTFOUND. No functionality is supposed to change here.
2018-04-24 16:05:35 +08:00
if (td == NULL) {
rc = RPMRC_NOTFOUND;
goto exit;
}
Split tag-specific information out of rpmsinfo struct Commit d809fd525228f015104bf35dfd593a8081debeb3 lumped everything into rpmsinfo but things like tag data type and count don't belong there, it's not interesting once the tag data has been validated. Whether the tag value belongs there is another question, leaving it for now at least as it's used for output in signature checking. No functional changes intended.
2017-05-11 15:40:28 +08:00
if (tinfo->tagtype && tinfo->tagtype != td->type) {
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
rasprintf(&sinfo->msg, _("%s tag %u: invalid type %u"),
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
origin, td->tag, td->type);
goto exit;
}
Split tag-specific information out of rpmsinfo struct Commit d809fd525228f015104bf35dfd593a8081debeb3 lumped everything into rpmsinfo but things like tag data type and count don't belong there, it's not interesting once the tag data has been validated. Whether the tag value belongs there is another question, leaving it for now at least as it's used for output in signature checking. No functional changes intended.
2017-05-11 15:40:28 +08:00
if (tinfo->tagcount && tinfo->tagcount != td->count) {
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
rasprintf(&sinfo->msg, _("%s: tag %u: invalid count %u"),
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
origin, td->tag, td->count);
goto exit;
}
switch (td->type) {
case RPM_STRING_TYPE:
case RPM_STRING_ARRAY_TYPE:
data = rpmtdGetString(td);
if (data)
dlen = strlen(data);
break;
case RPM_BIN_TYPE:
data = td->data;
dlen = td->count;
break;
}
/* MD5 has data length of 16, everything else is (much) larger */
if (sinfo->hashalgo && (data == NULL || dlen < 16)) {
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
rasprintf(&sinfo->msg, _("%s tag %u: invalid data %p (%u)"),
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
origin, td->tag, data, dlen);
goto exit;
}
if (td->type == RPM_STRING_TYPE && td->size == 0)
td->size = dlen + 1;
Split tag-specific information out of rpmsinfo struct Commit d809fd525228f015104bf35dfd593a8081debeb3 lumped everything into rpmsinfo but things like tag data type and count don't belong there, it's not interesting once the tag data has been validated. Whether the tag value belongs there is another question, leaving it for now at least as it's used for output in signature checking. No functional changes intended.
2017-05-11 15:40:28 +08:00
if (tinfo->tagsize && (td->flags & RPMTD_IMMUTABLE) &&
tinfo->tagsize != td->size) {
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
rasprintf(&sinfo->msg, _("%s tag %u: invalid size %u"),
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
origin, td->tag, td->size);
goto exit;
}
if (sinfo->type == RPMSIG_SIGNATURE_TYPE) {
if (pgpPrtParams(data, dlen, PGPTAG_SIGNATURE, &sinfo->sig)) {
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
rasprintf(&sinfo->msg, _("%s tag %u: invalid OpenPGP signature"),
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
origin, td->tag);
goto exit;
}
sinfo->hashalgo = pgpDigParamsAlgo(sinfo->sig, PGPVAL_HASHALGO);
sinfo->keyid = pgpGrab(sinfo->sig->signid+4, 4);
} else if (sinfo->type == RPMSIG_DIGEST_TYPE) {
Only non-binary digests have hex strings to validate
2017-05-30 17:31:49 +08:00
if (td->type == RPM_BIN_TYPE) {
Rename pgpHexStr() to rpmhex(), but preserve ABI for now Fixup internal callers to use rpmhex(), deprecate pgpHexStr(). pgpHexStr() should be dropped at next soname bump, whenever that happens.
2022-02-24 20:50:59 +08:00
sinfo->dig = rpmhex(data, dlen);
Only non-binary digests have hex strings to validate
2017-05-30 17:31:49 +08:00
} else {
if (!validHex(data, dlen)) {
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
rasprintf(&sinfo->msg,
_("%s: tag %u: invalid hex"), origin, td->tag);
Only non-binary digests have hex strings to validate
2017-05-30 17:31:49 +08:00
goto exit;
}
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
sinfo->dig = xstrdup(data);
Only non-binary digests have hex strings to validate
2017-05-30 17:31:49 +08:00
}
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
if (sinfo->hashalgo)
Account for arrays when generating verify item id Currently we only have one digest/signature per tag but that might change, account for this in the way we generate the id number: tag goes in the high 16 bits, array index into low 16 bits. I have some trouble seeing anybody needing more than 65536 signatures on a package...
2017-05-15 16:14:18 +08:00
sinfo->id = (td->tag << 16) | rpmtdGetIndex(td);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
rc = RPMRC_OK;
exit:
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
sinfo->rc = rc;
return;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
Bury remaining internal signature API inside rpmvs.c
2017-05-12 18:05:20 +08:00
static void rpmsinfoFini(struct rpmsinfo_s *sinfo)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
if (sinfo) {
if (sinfo->type == RPMSIG_SIGNATURE_TYPE)
pgpDigParamsFree(sinfo->sig);
else if (sinfo->type == RPMSIG_DIGEST_TYPE)
free(sinfo->dig);
Remember unfinalized digest context in rpmsinfo struct Less parameters to pass around, the digest context is a rather fundamental part of the sig/dig thing anyway. More importantly this detaches the digest finalization from the actual verification, which allows us to verify later or even multiple times (eg for added keys) without rereading the actual data. No functional changes here though.
2018-04-10 16:24:19 +08:00
rpmDigestFinal(sinfo->ctx, NULL, NULL, 0);
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
free(sinfo->msg);
Start separating verify item description from its result Add internal API to get a textual description of signature/digest, use where appropriate for formatting the verbose messages.
2017-05-24 16:20:35 +08:00
free(sinfo->descr);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
memset(sinfo, 0, sizeof(*sinfo));
}
}
Bury remaining internal signature API inside rpmvs.c
2017-05-12 18:05:20 +08:00
static int rpmsinfoDisabled(const struct rpmsinfo_s *sinfo, rpmVSFlags vsflags)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
if (!(sinfo->type & RPMSIG_VERIFIABLE_TYPE))
return 1;
if (vsflags & sinfo->disabler)
return 1;
if ((vsflags & RPMVSF_NEEDPAYLOAD) && (sinfo->range & RPMSIG_PAYLOAD))
return 1;
return 0;
}
Handle dynamic reallocation in rpmvsAppend() Preallocate a little but (for now) so little that reallocation always takes place so it doesn't rot while surroundings still change.
2017-05-22 17:32:32 +08:00
static void rpmvsReserve(struct rpmvs_s *vs, int n)
{
if (vs->nsigs + n >= vs->nalloced) {
vs->nalloced = (vs->nsigs * 2) + n;
vs->sigs = xrealloc(vs->sigs, vs->nalloced * sizeof(*vs->sigs));
}
}
Start separating verify item description from its result Add internal API to get a textual description of signature/digest, use where appropriate for formatting the verbose messages.
2017-05-24 16:20:35 +08:00
const char *rpmsinfoDescr(struct rpmsinfo_s *sinfo)
{
if (sinfo->descr == NULL) {
switch (sinfo->type) {
case RPMSIG_DIGEST_TYPE:
Implement verify support for alternative digests and signatures Implements generic logic to let one digest/signature to act as an equivalent alternative to another one.
2019-10-03 19:47:59 +08:00
rasprintf(&sinfo->descr, _("%s%s%s %s"),
Start separating verify item description from its result Add internal API to get a textual description of signature/digest, use where appropriate for formatting the verbose messages.
2017-05-24 16:20:35 +08:00
rangeName(sinfo->range),
pgpValString(PGPVAL_HASHALGO, sinfo->hashalgo),
Implement verify support for alternative digests and signatures Implements generic logic to let one digest/signature to act as an equivalent alternative to another one.
2019-10-03 19:47:59 +08:00
sinfo->alt ? " ALT" : "",
Start separating verify item description from its result Add internal API to get a textual description of signature/digest, use where appropriate for formatting the verbose messages.
2017-05-24 16:20:35 +08:00
_("digest"));
break;
case RPMSIG_SIGNATURE_TYPE:
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
if (sinfo->sig) {
Plug a memory leak from commit 170bc61a337f74a3619be0357bb3da96306c2769
2018-06-06 17:44:11 +08:00
char *t = pgpIdentItem(sinfo->sig);
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
rasprintf(&sinfo->descr, _("%s%s"),
Plug a memory leak from commit 170bc61a337f74a3619be0357bb3da96306c2769
2018-06-06 17:44:11 +08:00
rangeName(sinfo->range), t);
free(t);
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
} else {
Implement verify support for alternative digests and signatures Implements generic logic to let one digest/signature to act as an equivalent alternative to another one.
2019-10-03 19:47:59 +08:00
rasprintf(&sinfo->descr, _("%s%s%s %s"),
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
rangeName(sinfo->range),
pgpValString(PGPVAL_PUBKEYALGO, sinfo->sigalgo),
Implement verify support for alternative digests and signatures Implements generic logic to let one digest/signature to act as an equivalent alternative to another one.
2019-10-03 19:47:59 +08:00
sinfo->alt ? " ALT" : "",
Identify non-present signatures too (based on their assumed algo) This is dumb, we should just call them OpenPGP signatures which is what they are, but for now lets just make do with minimum fuss.
2018-04-13 20:08:09 +08:00
_("signature"));
}
Start separating verify item description from its result Add internal API to get a textual description of signature/digest, use where appropriate for formatting the verbose messages.
2017-05-24 16:20:35 +08:00
break;
}
}
return sinfo->descr;
}
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
char *rpmsinfoMsg(struct rpmsinfo_s *sinfo)
Separate sig/dig verify results from verbose error messages Add and use an internal helper for formatting the verbose messages from callbacks, this gives us nicer and more uniform messages for data that failed to initialize at all. It's also ends up involving more rasprintf()'s and whatnot per result but that can be tuned later.
2017-05-24 17:17:46 +08:00
{
char *msg = NULL;
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
if (sinfo->msg) {
Separate sig/dig verify results from verbose error messages Add and use an internal helper for formatting the verbose messages from callbacks, this gives us nicer and more uniform messages for data that failed to initialize at all. It's also ends up involving more rasprintf()'s and whatnot per result but that can be tuned later.
2017-05-24 17:17:46 +08:00
rasprintf(&msg, "%s: %s (%s)",
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
rpmsinfoDescr(sinfo), rpmSigString(sinfo->rc), sinfo->msg);
Separate sig/dig verify results from verbose error messages Add and use an internal helper for formatting the verbose messages from callbacks, this gives us nicer and more uniform messages for data that failed to initialize at all. It's also ends up involving more rasprintf()'s and whatnot per result but that can be tuned later.
2017-05-24 17:17:46 +08:00
} else {
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
rasprintf(&msg, "%s: %s",
rpmsinfoDescr(sinfo), rpmSigString(sinfo->rc));
Separate sig/dig verify results from verbose error messages Add and use an internal helper for formatting the verbose messages from callbacks, this gives us nicer and more uniform messages for data that failed to initialize at all. It's also ends up involving more rasprintf()'s and whatnot per result but that can be tuned later.
2017-05-24 17:17:46 +08:00
}
return msg;
}
Streamline digest/signature info initialization rpmsinfoInit() never gets called with an unknown value as it's us calling it based on values in our built-in tables (it used to be different though). In fact it mostly gets called while we're walking the very same table we're then looking up again in rpmsinfoInit()... makes no sense whatsoever. Change the internal API to take the table values directly, and handle the lookup in the only case that needs it (payload digest). Not supposed to change any functionality except make things a little saner and faster too.
2018-04-05 18:58:44 +08:00
static void rpmvsAppend(struct rpmvs_s *sis, hdrblob blob,
const struct vfyinfo_s *vi, const struct vfytag_s *ti)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
Preliminaries for reporting non-present verification items Remember RPMRC_NOTFOUND results in verify set, but ignore them in actual results for now. The check for verifiable types never really belonged to rpmsinfoDisabled() as it's a different kind of check, and here we see why - we NEVER want to add non-verifiable elements to verify set, but for the next steps we'll need to handle disabled items as if they were not present - ie NOTFOUND. No functionality is supposed to change here.
2018-04-24 16:05:35 +08:00
if (!(vi->vi.type & RPMSIG_VERIFIABLE_TYPE))
Always honor vsflags when appending new items to verify set Remember the vsflags passed to us in rpmvsCreate(), check for disabled in rpmvsAppend() instead.
2018-04-05 19:10:37 +08:00
return;
Preliminaries for reporting non-present verification items Remember RPMRC_NOTFOUND results in verify set, but ignore them in actual results for now. The check for verifiable types never really belonged to rpmsinfoDisabled() as it's a different kind of check, and here we see why - we NEVER want to add non-verifiable elements to verify set, but for the next steps we'll need to handle disabled items as if they were not present - ie NOTFOUND. No functionality is supposed to change here.
2018-04-24 16:05:35 +08:00
const char *o = (blob->il > blob->ril) ? _("header") : _("package");
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
struct rpmtd_s td;
Streamline digest/signature info initialization rpmsinfoInit() never gets called with an unknown value as it's us calling it based on values in our built-in tables (it used to be different though). In fact it mostly gets called while we're walking the very same table we're then looking up again in rpmsinfoInit()... makes no sense whatsoever. Change the internal API to take the table values directly, and handle the lookup in the only case that needs it (payload digest). Not supposed to change any functionality except make things a little saner and faster too.
2018-04-05 18:58:44 +08:00
rpmRC rc = hdrblobGet(blob, vi->tag, &td);
Preliminaries for reporting non-present verification items Remember RPMRC_NOTFOUND results in verify set, but ignore them in actual results for now. The check for verifiable types never really belonged to rpmsinfoDisabled() as it's a different kind of check, and here we see why - we NEVER want to add non-verifiable elements to verify set, but for the next steps we'll need to handle disabled items as if they were not present - ie NOTFOUND. No functionality is supposed to change here.
2018-04-24 16:05:35 +08:00
int nitems = (rc == RPMRC_OK) ? rpmtdCount(&td) : 1;
Handle dynamic reallocation in rpmvsAppend() Preallocate a little but (for now) so little that reallocation always takes place so it doesn't rot while surroundings still change.
2017-05-22 17:32:32 +08:00
Preliminaries for reporting non-present verification items Remember RPMRC_NOTFOUND results in verify set, but ignore them in actual results for now. The check for verifiable types never really belonged to rpmsinfoDisabled() as it's a different kind of check, and here we see why - we NEVER want to add non-verifiable elements to verify set, but for the next steps we'll need to handle disabled items as if they were not present - ie NOTFOUND. No functionality is supposed to change here.
2018-04-24 16:05:35 +08:00
rpmvsReserve(sis, nitems);
Handle dynamic reallocation in rpmvsAppend() Preallocate a little but (for now) so little that reallocation always takes place so it doesn't rot while surroundings still change.
2017-05-22 17:32:32 +08:00
Preliminaries for reporting non-present verification items Remember RPMRC_NOTFOUND results in verify set, but ignore them in actual results for now. The check for verifiable types never really belonged to rpmsinfoDisabled() as it's a different kind of check, and here we see why - we NEVER want to add non-verifiable elements to verify set, but for the next steps we'll need to handle disabled items as if they were not present - ie NOTFOUND. No functionality is supposed to change here.
2018-04-24 16:05:35 +08:00
if (!rpmsinfoDisabled(&vi->vi, sis->vsflags) && rc == RPMRC_OK) {
while (rpmtdNext(&td) >= 0) {
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
rpmsinfoInit(vi, ti, &td, o, &sis->sigs[sis->nsigs]);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
sis->nsigs++;
}
Preliminaries for reporting non-present verification items Remember RPMRC_NOTFOUND results in verify set, but ignore them in actual results for now. The check for verifiable types never really belonged to rpmsinfoDisabled() as it's a different kind of check, and here we see why - we NEVER want to add non-verifiable elements to verify set, but for the next steps we'll need to handle disabled items as if they were not present - ie NOTFOUND. No functionality is supposed to change here.
2018-04-24 16:05:35 +08:00
} else {
rpmsinfoInit(vi, ti, NULL, o, &sis->sigs[sis->nsigs]);
sis->nsigs++;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
Preliminaries for reporting non-present verification items Remember RPMRC_NOTFOUND results in verify set, but ignore them in actual results for now. The check for verifiable types never really belonged to rpmsinfoDisabled() as it's a different kind of check, and here we see why - we NEVER want to add non-verifiable elements to verify set, but for the next steps we'll need to handle disabled items as if they were not present - ie NOTFOUND. No functionality is supposed to change here.
2018-04-24 16:05:35 +08:00
rpmtdFreeData(&td);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
Streamline digest/signature info initialization rpmsinfoInit() never gets called with an unknown value as it's us calling it based on values in our built-in tables (it used to be different though). In fact it mostly gets called while we're walking the very same table we're then looking up again in rpmsinfoInit()... makes no sense whatsoever. Change the internal API to take the table values directly, and handle the lookup in the only case that needs it (payload digest). Not supposed to change any functionality except make things a little saner and faster too.
2018-04-05 18:58:44 +08:00
void rpmvsAppendTag(struct rpmvs_s *vs, hdrblob blob, rpmTagVal tag)
{
int ix = sinfoLookup(tag);
if (ix >= 0) {
const struct vfyinfo_s *vi = &rpmvfyitems[ix];
const struct vfytag_s *ti = &rpmvfytags[ix];
rpmvsAppend(vs, blob, vi, ti);
}
}
Rename vslevel back to vfylevel everywhere, sigh rpmtsVSFlags() doesn't actually control what happens with the package verification that vslevel/vfylevel relates to, it controls the verification that happens on header/package read. We actually need a separate API for controlling the flags that control the operation that verify level is associated with, so to avoid total confusion as to what is what... paving way for adding rpmtsVfyFlags(), but that's not added in this commit - rename only.
2018-06-27 16:22:41 +08:00
struct rpmvs_s *rpmvsCreate(int vfylevel, rpmVSFlags vsflags, rpmKeyring keyring)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
struct rpmvs_s *sis = xcalloc(1, sizeof(*sis));
Always honor vsflags when appending new items to verify set Remember the vsflags passed to us in rpmvsCreate(), check for disabled in rpmvsAppend() instead.
2018-04-05 19:10:37 +08:00
sis->vsflags = vsflags;
Store keyring handle in verify set as part of creation Passing different keyrings to individual calls of rpmvsVerifyItems() on the same set just would not make any sense, eliminating the possibility is the only sane thing. Part of create instead of init as keyring lifetimes are longer than verify sets.
2018-04-06 19:17:25 +08:00
sis->keyring = rpmKeyringLink(keyring);
Rename vslevel back to vfylevel everywhere, sigh rpmtsVSFlags() doesn't actually control what happens with the package verification that vslevel/vfylevel relates to, it controls the verification that happens on header/package read. We actually need a separate API for controlling the flags that control the operation that verify level is associated with, so to avoid total confusion as to what is what... paving way for adding rpmtsVfyFlags(), but that's not added in this commit - rename only.
2018-06-27 16:22:41 +08:00
sis->vfylevel = vfylevel;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
Split verify set creation to separate allocation + init steps This seems mostly like lotsa trouble for no payback in the current code, but we'll eventually want vs sets to outlive the actual package read stage (to support post-processing of the results), which is when this starts making sense.
2018-04-06 19:03:33 +08:00
return sis;
}
Add getter for verify set vsflags, use it for the one external access It's klunky and shouldn't be needed with a saner API for processing through the data but it'll have to do for now.
2018-04-06 19:28:18 +08:00
rpmVSFlags rpmvsFlags(struct rpmvs_s *vs)
{
return vs->vsflags;
}
Store digest bundle handle in verify set as part of initialization Passing different digest bundles to individual rpmvsInitDigests() and rpmvsVerifyItems() calls would not make any sense, it would simply fail to perform anything meaningful. Eliminating that possibility is the only sane thing to do.
2018-04-06 19:12:48 +08:00
void rpmvsInit(struct rpmvs_s *vs, hdrblob blob, rpmDigestBundle bundle)
Split verify set creation to separate allocation + init steps This seems mostly like lotsa trouble for no payback in the current code, but we'll eventually want vs sets to outlive the actual package read stage (to support post-processing of the results), which is when this starts making sense.
2018-04-06 19:03:33 +08:00
{
const struct vfyinfo_s *si = &rpmvfyitems[0];
const struct vfytag_s *ti = &rpmvfytags[0];
Streamline digest/signature info initialization rpmsinfoInit() never gets called with an unknown value as it's us calling it based on values in our built-in tables (it used to be different though). In fact it mostly gets called while we're walking the very same table we're then looking up again in rpmsinfoInit()... makes no sense whatsoever. Change the internal API to take the table values directly, and handle the lookup in the only case that needs it (payload digest). Not supposed to change any functionality except make things a little saner and faster too.
2018-04-05 18:58:44 +08:00
for (; si->tag && ti->tag; si++, ti++) {
Ignore non-signature tags on rpmvsInit() This avoids tags tags that only exist in the main header from being initialized twice. Currently only RPMTAG_PAYLOADDIGEST is affected.
2018-04-13 18:35:25 +08:00
/* Ignore non-signature tags initially */
if (!si->sigh)
continue;
Split verify set creation to separate allocation + init steps This seems mostly like lotsa trouble for no payback in the current code, but we'll eventually want vs sets to outlive the actual package read stage (to support post-processing of the results), which is when this starts making sense.
2018-04-06 19:03:33 +08:00
rpmvsAppend(vs, blob, si, ti);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
Store digest bundle handle in verify set as part of initialization Passing different digest bundles to individual rpmvsInitDigests() and rpmvsVerifyItems() calls would not make any sense, it would simply fail to perform anything meaningful. Eliminating that possibility is the only sane thing to do.
2018-04-06 19:12:48 +08:00
vs->bundle = bundle;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
struct rpmvs_s *rpmvsFree(struct rpmvs_s *sis)
{
if (sis) {
Store keyring handle in verify set as part of creation Passing different keyrings to individual calls of rpmvsVerifyItems() on the same set just would not make any sense, eliminating the possibility is the only sane thing. Part of create instead of init as keyring lifetimes are longer than verify sets.
2018-04-06 19:17:25 +08:00
rpmKeyringFree(sis->keyring);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
for (int i = 0; i < sis->nsigs; i++) {
rpmsinfoFini(&sis->sigs[i]);
}
free(sis->sigs);
free(sis);
}
return NULL;
}
Separate signature/digest verification from the digest finalization Adjust the API a bit to make things clearer/saner (hopefully): we now init and finalize *ranges*, and verification is an independent, non-destructive operation that can be performed on given *types* of items, allowing separate digest and signature verification and can be performed multiple times without rereading data (for eg added keys). At least in theory... which is to say no such things are done here, this is not supposed to change any visible functionality. For now at least, sort the items in rpmvsVerifyItems() by range to preserve traditional rpm -Kv output.
2018-04-10 16:46:44 +08:00
void rpmvsInitRange(struct rpmvs_s *sis, int range)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
for (int i = 0; i < sis->nsigs; i++) {
struct rpmsinfo_s *sinfo = &sis->sigs[i];
if (sinfo->range & range) {
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
if (sinfo->rc == RPMRC_OK)
Store digest bundle handle in verify set as part of initialization Passing different digest bundles to individual rpmvsInitDigests() and rpmvsVerifyItems() calls would not make any sense, it would simply fail to perform anything meaningful. Eliminating that possibility is the only sane thing to do.
2018-04-06 19:12:48 +08:00
rpmDigestBundleAddID(sis->bundle, sinfo->hashalgo, sinfo->id, 0);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
}
}
Separate signature/digest verification from the digest finalization Adjust the API a bit to make things clearer/saner (hopefully): we now init and finalize *ranges*, and verification is an independent, non-destructive operation that can be performed on given *types* of items, allowing separate digest and signature verification and can be performed multiple times without rereading data (for eg added keys). At least in theory... which is to say no such things are done here, this is not supposed to change any visible functionality. For now at least, sort the items in rpmvsVerifyItems() by range to preserve traditional rpm -Kv output.
2018-04-10 16:46:44 +08:00
void rpmvsFiniRange(struct rpmvs_s *sis, int range)
{
for (int i = 0; i < sis->nsigs; i++) {
struct rpmsinfo_s *sinfo = &sis->sigs[i];
if (sinfo->range == range && sinfo->rc == RPMRC_OK) {
sinfo->ctx = rpmDigestBundleDupCtx(sis->bundle, sinfo->id);
Handle unsupported digests the same as disabled ones (RhBug:1652529) A digest type unsupported by the underlying crypto library (whether technically or by configuration) does not mean the digest is invalid, it just cannot be used. Which for the purposes of verification is the same as if that digest didn't exist at all, and that's exactly how we handle digests and signatures disabled by configuration. One particular case is FIPS mode which globally disables the use of MD5, which we mishandled prior to this by showing it as OK in verification despite actually not verifying it at all. The exact place for handling this case is a bit subtle: the "obvious" place for checking for supported type is in rpmvsInitRange() but this doesn't work because of rpmDigestBundleAddID() return code semantics. The other "obvious" place would be rpmvsVerify(), but by that point we have even more funny cases to consider. So for now, it's actually easiest to check for this in rpmvsFiniRange() even if it's not the most obvious place for doing so. Might want to change the rpmDigestBundleAddID() semantics later, but this makes for a nicer backport (we'll need this in 4.14.x too).
2018-11-23 18:47:27 +08:00
/* Handle unsupported digests the same as disabled ones */
if (sinfo->ctx == NULL)
sinfo->rc = RPMRC_NOTFOUND;
Separate signature/digest verification from the digest finalization Adjust the API a bit to make things clearer/saner (hopefully): we now init and finalize *ranges*, and verification is an independent, non-destructive operation that can be performed on given *types* of items, allowing separate digest and signature verification and can be performed multiple times without rereading data (for eg added keys). At least in theory... which is to say no such things are done here, this is not supposed to change any visible functionality. For now at least, sort the items in rpmvsVerifyItems() by range to preserve traditional rpm -Kv output.
2018-04-10 16:46:44 +08:00
rpmDigestBundleFinal(sis->bundle, sinfo->id, NULL, NULL, 0);
}
}
}
Only read through payload on verify if actually needed If none of our verify items ranges over the payload, then why bother? To do this, add an internal rpmvs API to get it's range, and use that to decide whether trip over the payload is needed or not. In addition, the payload digest tag needs to be grabbed outside of the condition to avoid depending on other values. The details including RPMVSF_NEEDPAYLOAD will be handled internally to rpmvs which makes it actually nicer code-wise too.
2018-12-11 19:21:47 +08:00
int rpmvsRange(struct rpmvs_s *vs)
{
int range = 0;
for (int i = 0; i < vs->nsigs; i++) {
if (rpmsinfoDisabled(&vs->sigs[i], vs->vsflags))
continue;
range |= vs->sigs[i].range;
}
return range;
}
Make verify set sorting more precise (and hopefully, more useful) Sort in rough "better first" order from algorithm POV (assuming newer is better which always isn't the case), which could perhaps be used for skipping lesser digests for example. For the rest, sort by whatever to ensure consistent order. Update test-suite expectations to match. This does not affect actual verify results in any way though.
2018-05-09 16:12:03 +08:00
static int sinfoCmp(const void *a, const void *b)
Separate signature/digest verification from the digest finalization Adjust the API a bit to make things clearer/saner (hopefully): we now init and finalize *ranges*, and verification is an independent, non-destructive operation that can be performed on given *types* of items, allowing separate digest and signature verification and can be performed multiple times without rereading data (for eg added keys). At least in theory... which is to say no such things are done here, this is not supposed to change any visible functionality. For now at least, sort the items in rpmvsVerifyItems() by range to preserve traditional rpm -Kv output.
2018-04-10 16:46:44 +08:00
{
const struct rpmsinfo_s *sa = a;
const struct rpmsinfo_s *sb = b;
Sort verify set results by type as well, signatures before digests This doesn't appear to change anything as-is, it'll only become apparent when non-present items are reported.
2018-04-24 16:23:01 +08:00
int rc = sa->range - sb->range;
/* signatures before digests */
if (rc == 0)
rc = sb->type - sa->type;
Make verify set sorting more precise (and hopefully, more useful) Sort in rough "better first" order from algorithm POV (assuming newer is better which always isn't the case), which could perhaps be used for skipping lesser digests for example. For the rest, sort by whatever to ensure consistent order. Update test-suite expectations to match. This does not affect actual verify results in any way though.
2018-05-09 16:12:03 +08:00
/* strongest (in the "newer is better" sense) algos first */
if (rc == 0)
rc = sb->sigalgo - sb->sigalgo;
if (rc == 0)
rc = sb->hashalgo - sb->hashalgo;
/* last resort, these only makes sense from consistency POV */
if (rc == 0)
rc = sb->id - sa->id;
if (rc == 0)
rc = sb->disabler - sa->disabler;
Sort verify set results by type as well, signatures before digests This doesn't appear to change anything as-is, it'll only become apparent when non-present items are reported.
2018-04-24 16:23:01 +08:00
return rc;
Separate signature/digest verification from the digest finalization Adjust the API a bit to make things clearer/saner (hopefully): we now init and finalize *ranges*, and verification is an independent, non-destructive operation that can be performed on given *types* of items, allowing separate digest and signature verification and can be performed multiple times without rereading data (for eg added keys). At least in theory... which is to say no such things are done here, this is not supposed to change any visible functionality. For now at least, sort the items in rpmvsVerifyItems() by range to preserve traditional rpm -Kv output.
2018-04-10 16:46:44 +08:00
}
Implement verify support for alternative digests and signatures Implements generic logic to let one digest/signature to act as an equivalent alternative to another one.
2019-10-03 19:47:59 +08:00
static const struct rpmsinfo_s *getAlt(const struct rpmvs_s *vs, const struct rpmsinfo_s *sinfo)
{
for (int i = 0; i < vs->nsigs; i++) {
const struct rpmsinfo_s *alt = &vs->sigs[i];
if ((sinfo->id != alt->id) && (sinfo->disabler == alt->disabler))
return alt;
}
return NULL;
}
Eliminate weirdo "usesys" argument from rpmvsVerify() Pass the desired verifylevel (whether system or not is well known at the call site) to rpmvsCreate() and remember it there, this seems far less bizarre API-wise. No functional changes though.
2018-06-19 15:15:37 +08:00
int rpmvsVerify(struct rpmvs_s *sis, int type,
Store keyring handle in verify set as part of creation Passing different keyrings to individual calls of rpmvsVerifyItems() on the same set just would not make any sense, eliminating the possibility is the only sane thing. Part of create instead of init as keyring lifetimes are longer than verify sets.
2018-04-06 19:17:25 +08:00
rpmsinfoCb cb, void *cbdata)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
int failed = 0;
Allow verification callbacks to signal stopping, document the callback Move the rc code from return value to a parameter, change to a pointer to allow modification from the callback. Make the message modifiable from callback too if only for consistency. Change the parameter names on all callback users to force all relevant places to be updated. With all this, a verification callback now force verification to abort by returning 0. No actual behavior is changed in this commit though.
2018-03-08 19:22:49 +08:00
int cont = 1;
Header signatures alone are not sufficient This fixes how RPM handles packages that contain a header signature, but neither header+payload signature nor payload digests. Such packages are obviously not properly signed, but RPM previously accepted them. This could be used to confuse both ‘rpmkeys -K’ and old versions of DNF. Both would report that the package has been properly signed even when it has not. The included regression tests demonstrates the change in behavior.
2021-03-17 10:12:05 +08:00
int range = 0, vfylevel = sis->vfylevel;
Implement configurable, mandatory signature/digest verify level for rpm -K Traditionally rpm has verified whatever digests and signatures are present (unless disabled) but there hasn't been any way to *require* either type of verification, and making it all too easy to fool rpm into accepting a tampered package whose signatures and digests have just been stripped off and content modified. This commit adds support for required verification level, possible levels being "none" (for traditional behavior and default for now), "digest", "signature" and "all" (for both signatures and digests). What it means is that the specified level of validation is required for the entire package file: eg on digest level, both the header and the payload must have been validated with a digest. All digest algorithms are considered equal for this purpose to abstract out version differences: eg all valid rpm packages have *some* digest covering the entire package. Traditionally the only digest covering the payload is the md5sum, but packages built with rpm >= 4.14.0 have a separate payload digest which can be used for the purpose and md5sum disabled (which would also deny install of older packages). Similarly (and more importantly) signatures can now be also required. As a special case, the new payload digest added in 4.14.x is in the main header which, if signed, makes the payload digest signature strength too. Which would make it possible to drop V3 header+payload signatures from package signing (which would make signing much faster) and still have signature strength coverage for the entire package. It's worth noting that when a verification level is active, --nodigest and --nosignature seem to behave sort of counter-intuitively: these disablers tell rpm not to try verification of those items, but the verification level specifies what *must* be verified for a pass, so eg if signature verify level is active, rpm -K --nosignatures will *always fail* because no signatures could be verified. This only implements the "policy" for the rpm -K style signature checking path, installation is not covered yet as that's quite a different beast: we don't want to enforce this at rpmReadPackage() level because of API issues and assumptions (eg you couldn't read a package to discover what key it was signed with, in order to import the key required to successfully verify said package)
2018-04-27 18:27:02 +08:00
int verified[3] = { 0, 0, 0 };
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
Make verify set sorting more precise (and hopefully, more useful) Sort in rough "better first" order from algorithm POV (assuming newer is better which always isn't the case), which could perhaps be used for skipping lesser digests for example. For the rest, sort by whatever to ensure consistent order. Update test-suite expectations to match. This does not affect actual verify results in any way though.
2018-05-09 16:12:03 +08:00
/* sort for consistency and rough "better comes first" semantics*/
qsort(sis->sigs, sis->nsigs, sizeof(*sis->sigs), sinfoCmp);
Separate signature/digest verification from the digest finalization Adjust the API a bit to make things clearer/saner (hopefully): we now init and finalize *ranges*, and verification is an independent, non-destructive operation that can be performed on given *types* of items, allowing separate digest and signature verification and can be performed multiple times without rereading data (for eg added keys). At least in theory... which is to say no such things are done here, this is not supposed to change any visible functionality. For now at least, sort the items in rpmvsVerifyItems() by range to preserve traditional rpm -Kv output.
2018-04-10 16:46:44 +08:00
Allow verification callbacks to signal stopping, document the callback Move the rc code from return value to a parameter, change to a pointer to allow modification from the callback. Make the message modifiable from callback too if only for consistency. Change the parameter names on all callback users to force all relevant places to be updated. With all this, a verification callback now force verification to abort by returning 0. No actual behavior is changed in this commit though.
2018-03-08 19:22:49 +08:00
for (int i = 0; i < sis->nsigs && cont; i++) {
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
struct rpmsinfo_s *sinfo = &sis->sigs[i];
Separate signature/digest verification from the digest finalization Adjust the API a bit to make things clearer/saner (hopefully): we now init and finalize *ranges*, and verification is an independent, non-destructive operation that can be performed on given *types* of items, allowing separate digest and signature verification and can be performed multiple times without rereading data (for eg added keys). At least in theory... which is to say no such things are done here, this is not supposed to change any visible functionality. For now at least, sort the items in rpmvsVerifyItems() by range to preserve traditional rpm -Kv output.
2018-04-10 16:46:44 +08:00
if (type & sinfo->type) {
Implement configurable, mandatory signature/digest verify level for rpm -K Traditionally rpm has verified whatever digests and signatures are present (unless disabled) but there hasn't been any way to *require* either type of verification, and making it all too easy to fool rpm into accepting a tampered package whose signatures and digests have just been stripped off and content modified. This commit adds support for required verification level, possible levels being "none" (for traditional behavior and default for now), "digest", "signature" and "all" (for both signatures and digests). What it means is that the specified level of validation is required for the entire package file: eg on digest level, both the header and the payload must have been validated with a digest. All digest algorithms are considered equal for this purpose to abstract out version differences: eg all valid rpm packages have *some* digest covering the entire package. Traditionally the only digest covering the payload is the md5sum, but packages built with rpm >= 4.14.0 have a separate payload digest which can be used for the purpose and md5sum disabled (which would also deny install of older packages). Similarly (and more importantly) signatures can now be also required. As a special case, the new payload digest added in 4.14.x is in the main header which, if signed, makes the payload digest signature strength too. Which would make it possible to drop V3 header+payload signatures from package signing (which would make signing much faster) and still have signature strength coverage for the entire package. It's worth noting that when a verification level is active, --nodigest and --nosignature seem to behave sort of counter-intuitively: these disablers tell rpm not to try verification of those items, but the verification level specifies what *must* be verified for a pass, so eg if signature verify level is active, rpm -K --nosignatures will *always fail* because no signatures could be verified. This only implements the "policy" for the rpm -K style signature checking path, installation is not covered yet as that's quite a different beast: we don't want to enforce this at rpmReadPackage() level because of API issues and assumptions (eg you couldn't read a package to discover what key it was signed with, in order to import the key required to successfully verify said package)
2018-04-27 18:27:02 +08:00
/* Digests in signed header are signature strength */
if (sinfo->wrapped) {
if (verified[RPMSIG_SIGNATURE_TYPE] & RPMSIG_HEADER)
sinfo->strength = RPMSIG_SIGNATURE_TYPE;
}
if (sinfo->ctx) {
Remember unfinalized digest context in rpmsinfo struct Less parameters to pass around, the digest context is a rather fundamental part of the sig/dig thing anyway. More importantly this detaches the digest finalization from the actual verification, which allows us to verify later or even multiple times (eg for added keys) without rereading the actual data. No functional changes here though.
2018-04-10 16:24:19 +08:00
rpmVerifySignature(sis->keyring, sinfo);
Implement configurable, mandatory signature/digest verify level for rpm -K Traditionally rpm has verified whatever digests and signatures are present (unless disabled) but there hasn't been any way to *require* either type of verification, and making it all too easy to fool rpm into accepting a tampered package whose signatures and digests have just been stripped off and content modified. This commit adds support for required verification level, possible levels being "none" (for traditional behavior and default for now), "digest", "signature" and "all" (for both signatures and digests). What it means is that the specified level of validation is required for the entire package file: eg on digest level, both the header and the payload must have been validated with a digest. All digest algorithms are considered equal for this purpose to abstract out version differences: eg all valid rpm packages have *some* digest covering the entire package. Traditionally the only digest covering the payload is the md5sum, but packages built with rpm >= 4.14.0 have a separate payload digest which can be used for the purpose and md5sum disabled (which would also deny install of older packages). Similarly (and more importantly) signatures can now be also required. As a special case, the new payload digest added in 4.14.x is in the main header which, if signed, makes the payload digest signature strength too. Which would make it possible to drop V3 header+payload signatures from package signing (which would make signing much faster) and still have signature strength coverage for the entire package. It's worth noting that when a verification level is active, --nodigest and --nosignature seem to behave sort of counter-intuitively: these disablers tell rpm not to try verification of those items, but the verification level specifies what *must* be verified for a pass, so eg if signature verify level is active, rpm -K --nosignatures will *always fail* because no signatures could be verified. This only implements the "policy" for the rpm -K style signature checking path, installation is not covered yet as that's quite a different beast: we don't want to enforce this at rpmReadPackage() level because of API issues and assumptions (eg you couldn't read a package to discover what key it was signed with, in order to import the key required to successfully verify said package)
2018-04-27 18:27:02 +08:00
if (sinfo->rc == RPMRC_OK) {
verified[sinfo->type] |= sinfo->range;
verified[sinfo->strength] |= sinfo->range;
}
}
range |= sinfo->range;
}
}
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
Header signatures alone are not sufficient This fixes how RPM handles packages that contain a header signature, but neither header+payload signature nor payload digests. Such packages are obviously not properly signed, but RPM previously accepted them. This could be used to confuse both ‘rpmkeys -K’ and old versions of DNF. Both would report that the package has been properly signed even when it has not. The included regression tests demonstrates the change in behavior.
2021-03-17 10:12:05 +08:00
/* Unconditionally reject partially signed packages */
if (verified[RPMSIG_SIGNATURE_TYPE])
vfylevel |= RPMSIG_SIGNATURE_TYPE;
/* Cannot verify payload if RPMVSF_NEEDPAYLOAD is set */
if (sis->vsflags & RPMVSF_NEEDPAYLOAD)
range &= ~RPMSIG_PAYLOAD;
Implement configurable, mandatory signature/digest verify level for rpm -K Traditionally rpm has verified whatever digests and signatures are present (unless disabled) but there hasn't been any way to *require* either type of verification, and making it all too easy to fool rpm into accepting a tampered package whose signatures and digests have just been stripped off and content modified. This commit adds support for required verification level, possible levels being "none" (for traditional behavior and default for now), "digest", "signature" and "all" (for both signatures and digests). What it means is that the specified level of validation is required for the entire package file: eg on digest level, both the header and the payload must have been validated with a digest. All digest algorithms are considered equal for this purpose to abstract out version differences: eg all valid rpm packages have *some* digest covering the entire package. Traditionally the only digest covering the payload is the md5sum, but packages built with rpm >= 4.14.0 have a separate payload digest which can be used for the purpose and md5sum disabled (which would also deny install of older packages). Similarly (and more importantly) signatures can now be also required. As a special case, the new payload digest added in 4.14.x is in the main header which, if signed, makes the payload digest signature strength too. Which would make it possible to drop V3 header+payload signatures from package signing (which would make signing much faster) and still have signature strength coverage for the entire package. It's worth noting that when a verification level is active, --nodigest and --nosignature seem to behave sort of counter-intuitively: these disablers tell rpm not to try verification of those items, but the verification level specifies what *must* be verified for a pass, so eg if signature verify level is active, rpm -K --nosignatures will *always fail* because no signatures could be verified. This only implements the "policy" for the rpm -K style signature checking path, installation is not covered yet as that's quite a different beast: we don't want to enforce this at rpmReadPackage() level because of API issues and assumptions (eg you couldn't read a package to discover what key it was signed with, in order to import the key required to successfully verify said package)
2018-04-27 18:27:02 +08:00
for (int i = 0; i < sis->nsigs && cont; i++) {
struct rpmsinfo_s *sinfo = &sis->sigs[i];
int strength = (sinfo->type | sinfo->strength);
int required = 0;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
Implement verify support for alternative digests and signatures Implements generic logic to let one digest/signature to act as an equivalent alternative to another one.
2019-10-03 19:47:59 +08:00
/* Ignore failure if an alternative exists and verifies ok */
if (sinfo->rc == RPMRC_FAIL) {
const struct rpmsinfo_s * alt = getAlt(sis, sinfo);
if (alt && alt->rc == RPMRC_OK)
sinfo->rc = RPMRC_NOTFOUND;
}
Header signatures alone are not sufficient This fixes how RPM handles packages that contain a header signature, but neither header+payload signature nor payload digests. Such packages are obviously not properly signed, but RPM previously accepted them. This could be used to confuse both ‘rpmkeys -K’ and old versions of DNF. Both would report that the package has been properly signed even when it has not. The included regression tests demonstrates the change in behavior.
2021-03-17 10:12:05 +08:00
if (vfylevel & strength & RPMSIG_DIGEST_TYPE) {
Implement configurable, mandatory signature/digest verify level for rpm -K Traditionally rpm has verified whatever digests and signatures are present (unless disabled) but there hasn't been any way to *require* either type of verification, and making it all too easy to fool rpm into accepting a tampered package whose signatures and digests have just been stripped off and content modified. This commit adds support for required verification level, possible levels being "none" (for traditional behavior and default for now), "digest", "signature" and "all" (for both signatures and digests). What it means is that the specified level of validation is required for the entire package file: eg on digest level, both the header and the payload must have been validated with a digest. All digest algorithms are considered equal for this purpose to abstract out version differences: eg all valid rpm packages have *some* digest covering the entire package. Traditionally the only digest covering the payload is the md5sum, but packages built with rpm >= 4.14.0 have a separate payload digest which can be used for the purpose and md5sum disabled (which would also deny install of older packages). Similarly (and more importantly) signatures can now be also required. As a special case, the new payload digest added in 4.14.x is in the main header which, if signed, makes the payload digest signature strength too. Which would make it possible to drop V3 header+payload signatures from package signing (which would make signing much faster) and still have signature strength coverage for the entire package. It's worth noting that when a verification level is active, --nodigest and --nosignature seem to behave sort of counter-intuitively: these disablers tell rpm not to try verification of those items, but the verification level specifies what *must* be verified for a pass, so eg if signature verify level is active, rpm -K --nosignatures will *always fail* because no signatures could be verified. This only implements the "policy" for the rpm -K style signature checking path, installation is not covered yet as that's quite a different beast: we don't want to enforce this at rpmReadPackage() level because of API issues and assumptions (eg you couldn't read a package to discover what key it was signed with, in order to import the key required to successfully verify said package)
2018-04-27 18:27:02 +08:00
int missing = (range & ~verified[RPMSIG_DIGEST_TYPE]);
required |= (missing & sinfo->range);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
Header signatures alone are not sufficient This fixes how RPM handles packages that contain a header signature, but neither header+payload signature nor payload digests. Such packages are obviously not properly signed, but RPM previously accepted them. This could be used to confuse both ‘rpmkeys -K’ and old versions of DNF. Both would report that the package has been properly signed even when it has not. The included regression tests demonstrates the change in behavior.
2021-03-17 10:12:05 +08:00
if (vfylevel & strength & RPMSIG_SIGNATURE_TYPE) {
Implement configurable, mandatory signature/digest verify level for rpm -K Traditionally rpm has verified whatever digests and signatures are present (unless disabled) but there hasn't been any way to *require* either type of verification, and making it all too easy to fool rpm into accepting a tampered package whose signatures and digests have just been stripped off and content modified. This commit adds support for required verification level, possible levels being "none" (for traditional behavior and default for now), "digest", "signature" and "all" (for both signatures and digests). What it means is that the specified level of validation is required for the entire package file: eg on digest level, both the header and the payload must have been validated with a digest. All digest algorithms are considered equal for this purpose to abstract out version differences: eg all valid rpm packages have *some* digest covering the entire package. Traditionally the only digest covering the payload is the md5sum, but packages built with rpm >= 4.14.0 have a separate payload digest which can be used for the purpose and md5sum disabled (which would also deny install of older packages). Similarly (and more importantly) signatures can now be also required. As a special case, the new payload digest added in 4.14.x is in the main header which, if signed, makes the payload digest signature strength too. Which would make it possible to drop V3 header+payload signatures from package signing (which would make signing much faster) and still have signature strength coverage for the entire package. It's worth noting that when a verification level is active, --nodigest and --nosignature seem to behave sort of counter-intuitively: these disablers tell rpm not to try verification of those items, but the verification level specifies what *must* be verified for a pass, so eg if signature verify level is active, rpm -K --nosignatures will *always fail* because no signatures could be verified. This only implements the "policy" for the rpm -K style signature checking path, installation is not covered yet as that's quite a different beast: we don't want to enforce this at rpmReadPackage() level because of API issues and assumptions (eg you couldn't read a package to discover what key it was signed with, in order to import the key required to successfully verify said package)
2018-04-27 18:27:02 +08:00
int missing = (range & ~verified[RPMSIG_SIGNATURE_TYPE]);
required |= (missing & sinfo->range);
}
if (!required && sinfo->rc == RPMRC_NOTFOUND)
continue;
if (cb)
cont = cb(sinfo, cbdata);
if (sinfo->rc != RPMRC_OK)
failed = 1;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
return failed;
}
static const char * rpmSigString(rpmRC res)
{
const char * str;
switch (res) {
case RPMRC_OK: str = "OK"; break;
case RPMRC_FAIL: str = "BAD"; break;
case RPMRC_NOKEY: str = "NOKEY"; break;
case RPMRC_NOTTRUSTED: str = "NOTTRUSTED"; break;
Preliminaries for reporting non-present verification items Remember RPMRC_NOTFOUND results in verify set, but ignore them in actual results for now. The check for verifiable types never really belonged to rpmsinfoDisabled() as it's a different kind of check, and here we see why - we NEVER want to add non-verifiable elements to verify set, but for the next steps we'll need to handle disabled items as if they were not present - ie NOTFOUND. No functionality is supposed to change here.
2018-04-24 16:05:35 +08:00
case RPMRC_NOTFOUND: str = "NOTFOUND"; break;
default: str = "UNKNOWN"; break;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
return str;
}
static const char *rangeName(int range)
{
switch (range) {
case RPMSIG_HEADER: return _("Header ");
case RPMSIG_PAYLOAD: return _("Payload ");
}
/* trad. output for (RPMSIG_HEADER|RPMSIG_PAYLOAD) range is "" */
return "";
}
Remember unfinalized digest context in rpmsinfo struct Less parameters to pass around, the digest context is a rather fundamental part of the sig/dig thing anyway. More importantly this detaches the digest finalization from the actual verification, which allows us to verify later or even multiple times (eg for added keys) without rereading the actual data. No functional changes here though.
2018-04-10 16:24:19 +08:00
static rpmRC verifyDigest(struct rpmsinfo_s *sinfo)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
rpmRC res = RPMRC_FAIL; /* assume failure */
char * dig = NULL;
size_t diglen = 0;
Remember unfinalized digest context in rpmsinfo struct Less parameters to pass around, the digest context is a rather fundamental part of the sig/dig thing anyway. More importantly this detaches the digest finalization from the actual verification, which allows us to verify later or even multiple times (eg for added keys) without rereading the actual data. No functional changes here though.
2018-04-10 16:24:19 +08:00
DIGEST_CTX ctx = rpmDigestDup(sinfo->ctx);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
Format verbose message strings centrally in rpmVerifySignature() Another step towards separating descriptions from result messages, handle formatting centrally. This also drops the strange "BAD PARAMETERS" message which now fits in even less than it did before: it didn't really know whether it was "uhhuh, s*** happened" internal error or actual validation error. rpmVerifySignature() only gets called for known, pre-validated data now so let it think everything is just a validation failure.
2017-05-24 16:23:48 +08:00
if (rpmDigestFinal(ctx, (void **)&dig, &diglen, 1) || diglen == 0)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
goto exit;
if (strcasecmp(sinfo->dig, dig) == 0) {
res = RPMRC_OK;
} else {
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
rasprintf(&sinfo->msg, "Expected %s != %s", sinfo->dig, dig);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}
exit:
free(dig);
return res;
}
/**
* Verify DSA/RSA signature.
* @param keyring pubkey keyring
* @param sinfo OpenPGP signature parameters
* @return RPMRC_OK on success
*/
static rpmRC
Remember unfinalized digest context in rpmsinfo struct Less parameters to pass around, the digest context is a rather fundamental part of the sig/dig thing anyway. More importantly this detaches the digest finalization from the actual verification, which allows us to verify later or even multiple times (eg for added keys) without rereading the actual data. No functional changes here though.
2018-04-10 16:24:19 +08:00
verifySignature(rpmKeyring keyring, struct rpmsinfo_s *sinfo)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
verifySignature(): package signatures must be PGPSIGTYPE_BINARY RPM packages are binary documents and must be signed as such. To avoid having to access the fields of pgpDigParams() directly, this adds a new accessor function, pgpSignatureType(). pgpSignatureType() returns the type of a signature, or -1 if the PGP data is NULL or is not a signature. Prior to commit b5e8bc74b2b05aa557f663fe227b94d2bc64fbd8 this was kind of checked inside the parser but incorrectly.
2021-05-07 08:03:10 +08:00
rpmRC res = RPMRC_FAIL;
if (pgpSignatureType(sinfo->sig) == PGPSIGTYPE_BINARY)
res = rpmKeyringVerifySig(keyring, sinfo->sig, sinfo->ctx);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
return res;
}
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
static void
Remember unfinalized digest context in rpmsinfo struct Less parameters to pass around, the digest context is a rather fundamental part of the sig/dig thing anyway. More importantly this detaches the digest finalization from the actual verification, which allows us to verify later or even multiple times (eg for added keys) without rereading the actual data. No functional changes here though.
2018-04-10 16:24:19 +08:00
rpmVerifySignature(rpmKeyring keyring, struct rpmsinfo_s *sinfo)
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
{
if (sinfo->type == RPMSIG_DIGEST_TYPE)
Remember unfinalized digest context in rpmsinfo struct Less parameters to pass around, the digest context is a rather fundamental part of the sig/dig thing anyway. More importantly this detaches the digest finalization from the actual verification, which allows us to verify later or even multiple times (eg for added keys) without rereading the actual data. No functional changes here though.
2018-04-10 16:24:19 +08:00
sinfo->rc = verifyDigest(sinfo);
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
else if (sinfo->type == RPMSIG_SIGNATURE_TYPE)
Remember unfinalized digest context in rpmsinfo struct Less parameters to pass around, the digest context is a rather fundamental part of the sig/dig thing anyway. More importantly this detaches the digest finalization from the actual verification, which allows us to verify later or even multiple times (eg for added keys) without rereading the actual data. No functional changes here though.
2018-04-10 16:24:19 +08:00
sinfo->rc = verifySignature(keyring, sinfo);
Store digest/signature verify results in the sinfo struct directly Makes all sorts of things a whole lotta simple and saner. No actual functional changes here, apart from the internal API changes.
2018-04-05 19:46:36 +08:00
else
sinfo->rc = RPMRC_FAIL;
Lift all the new signature stuff into new rpmvs.[ch] source + header Looks large but this is just moving things around, except for a couple of things changing scope: rpmvsInitDigests() and VerifyItems() become non-static, rpmvfyitems array and rpmvs_s struct details become hidden inside rpmvs.c. signature.[ch] is now merely the largely obsoletish functions for reading and writing a signature header, all the verification business is in rpmvs.
2017-04-28 15:32:24 +08:00
}