On 07/26/10 20:39, Brock Pytlik wrote:
Greetings, while doing more testing this evening, I discovered that
there was a bug in the current wad for manifest signing that I have out
for review and I could use some advice about which of the two options to
resolve the problem I can think of is preferred.
The problem happens when a signed package contains variant tagged
actions. When signing, the signature covers all actions (ie, both sparc
and x86 for variant.arch). However, during install or image-update, when
we load the manifest from disk, we set the excludes during the Manifest
object creation such that only the actions pertinent to the image's
variant are stored in memory. This causes signature verification to fail
because an action it was expecting was missing.
The simplest option, from a code perspective, is to have the bit that
does the check of the signatures in pkgplan reload the manifest from
disk, making sure that the in memory copy now has all actions, using
that to verify the signature, then throwing the newly created manifest
away. If that was somewhat vague, here's a diff which illustrates this
idea by changing modules/client/pkgplan:
@@ -152,10 +155,11 @@
signature_policy.check_cas(dest_pub,
self.image.trust_anchors)
try:
+ dmfst = self.image.get_manifest(self.destination_fmri, all_variants=True)
signature_policy.process_signatures(
- self.__destination_mfst.gen_actions_by_type(
+ dmfst.gen_actions_by_type(
"signature", new_excludes),
- self.__destination_mfst.gen_actions(),
+ dmfst.gen_actions(),
dest_pub)
except apx.SigningException, e:
e.pfmri = self.destination_fmri
This does have the downside that the manifest object whose contents are
being verified isn't the manifest object whose contents are used to
perform the install, which seems less than ideal on the surface. On the
other hand perhaps the argument is that if someone has the ability to
switch good and bad manifests in and out of the /var/pkg/pkg directory
at will, then you're already hosed because they could as easily replace
your pkg binary with whatever they wanted.
The alternative is to change imageplan so that when it proposes a
pkgplan, the manifest(s) it creates the pkgplan with are variant
agnostic, and when non-signing uses are made of the manifests, the
excludes parameter is set appropriately. This has the advantage that the
in memory object whose actions are verified against a signature is the
same in-memory object that's used to make the changes to the image. It
has the downside of (probably) a much larger scope of change to the
existing code, as well as causing a bump in our memory usage. I believe
memory use reduction was the original reason that the exclusion was
added in the first place.
This cannot work; imagine the case where dependencies are tagged w/
variants. Imageplans are image-specific.
The variant and facet tags within express the subsets defined by the
publisher; the signature covers the entire manifest and implicitly
signs all combinations of facets and variants; including facet and
variants in the manifest (as opposed to client-side filtering)
was an explicit design choice.
Loading the entire manifest from disk, checking the signature, and
then excluding those portions not wanted is fine.
-= Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
