Darren J Moffat wrote:
Shawn Walker wrote:
However, a recent conversation with Stephen led me to believe that in
light of manifest signing, this may be problematic. In particular, my
understanding was that "Company A" may sign a manifest and be the
initial "publisher" of a package. Later on, they may give that
package to Sun to redistribute, and so "sun.com" would be the
publisher and the last signer of the package instead since they are
the "immediate provider" of the package.
Yes and then the local admin could republish into their local repoistory
again with their local company signature.
Or the second signature might remove the first. For example ON handing
off its IPS packages to RE.
Both cases are valid and accounted for in the signed manifest proposal.
I didn't see anything in the original manifest signing proposal that
indicated that multiple signatures would affect the perceived
'publisher' of a package; only an indication of its approval chain. I
also didn't see anything that mentioned a timestamp so that we would in
which order they were signed.
With that said, I had already discussed this option of using signature
actions for publisher identity with someone else, but it has some
challenges:
1) it would mean we can't deliver identity information until we have
signature actions, which would could affect my project delivery date;
I'd have to determine where the need for this lies and see if there is
an alternative
2) old clients don't understand signature actions, and at the moment, my
current belief is that the addition of signature actions to new
manifests will render those new manifests unparseable to old clients
3) If a local admin republishes into their local repository with the
company signature, there is an inherent assumption that they want the
packages to show up as being published by them as opposed to 'sun.com'.
Will they care about this? If they're only pre-qualifying select
packages provided by Sun, doesn't this mean that they will end up having
to have their publisher and Sun's on each client system and ensure that
theirs is ranking higher, etc.? In short, is there a use case for
signing that indicates that an entity has validated the package but
isn't taking ownership (publisher-ship :)) ?
4) Semantically, and in other ways, a set action is the only action that
fits with setting arbitrary values (such as pkg.fmri) currently.
* To workaround the multiple signers issues, should signature actions
omit the "set pkg.fmri" from their evaluation of the manifest contents?
What about if the fmri was part of the signature action itself eg:
signature type=x.509 hashtype=sha-256 sigtype=rsa-pkcs public_key=<hash>
[public_key=<hash>] ... value=<hash> ...
pkg.fmri=pkg://pkg.opensolaris.org/....
Not sure if that will help you solve 8217 and 2762 though. It might
also be a problem with some other cases too, say if we want the same
signed package at more than one FMRI but with the same signature - would
that make sense to have ?
As far as I'm aware, other than the publisher, there should only be one
FMRI for each package. I don't believe it is desirable to have multiple
namespace resolutions for a single package.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
