> Been thinking about this on and off. While ideally a signature is something
> you can verify without parsing the signed contents first, we'll always need
> to parse the signature header no matter what [*]. So I've been pondering
> something along the lines of
>
> * collect the tags numbers to be signed into an int32 array in the signature
> header
> * hash that array, and then the actual tag intros and data for the tags in
> the array, in the order specified by that array
> * ...and sign/verify the result
>
> It's a relatively complicated procedure but AFAICS it would allow signing the
> signature header contents in a way that is still verifiable post-install too
> (think rpm -V). There are no doubt other ways to sign+verify the signature
> header itself (mask select parts with zeros or something), but those wouldn't
> work post-install where we no longer have the signature header available as a
> whole.
>
> @nwalfield @simo5 @DemiMarie - does that seem totally crazy? đ
>
> Of course now that we support multiple signatures, we need'd to do the same
> for the signature-signature too. Ie anytime we add a signature, we'd add one
> for the signature header and one for the header, in a similar structure.
>
> [*] ignoring external signatures: it's not a solution, it's just a different
> set of problems
Itâs better than nothing, but I would prefer if there was a single signature of
both main and signature headers and if all of the entries in the signature
header (other than the signature entry itself) had to be signed. RPMv6 is not
released yet so there are no backwards compatibility concerns here.
>From a cryptographic perspective, the best solution would be for the signature
>header to be _only_ signatures on the rest of the data, and for e.g. IMA and
>fsverity signing to just recreate the main header. Since the IMA and fsverity
>signatures are part of what gets installed, they really ought to be treated as
>part of the package, not as something separate.
> If you still wanted to sign headers then the proper solution would require
> multistage signing:
>
> 1. you would need a way to tell rpm what signatures you are planning to use,
> so that you can lay out the headers with all the data save the actual
> signature bytes, those would be skipped or set to an array of zeros.
> 2. you would then apply each signature in turn, and finally you would fill
> the zeroed arrays with the signatures produced. Verification would need to
> zero out all signature fields before feeding the data to the verification
> function.
Multistage signing is definitely the best way to go if possible.
> I think this is needlessly complicated and will prevent adding additional
> features by 3rd parties a feature I think has significant promise.
Itâs not needlessly complicated IMO. What do you mean by âwill prevent adding
additional features by 3rd partiesâ? Packages should not be able to be altered
with after signing without invalidating the signature; thatâs the whole point
of digital signatures.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2224#issuecomment-2512778416
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2224/2512778...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
