Shawn Walker wrote:
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.
There isn't any mention of a timestamp in that proposal because in
general there is no need for it. I just suggested that as a possibility
in this thread so you could determine which was the last signature.
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'.
I don't know if "published" is the word they would actually use what
they are really doing in this case is "blessing" them through their
company approval system.
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.?
That is how I assume this would be deployed.
> 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 :)) ?
Yes that is basically what they are doing.
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.
That makes sense to me too and I was just checking I wasn't missing
something.
It some how feels "wrong" at the moment to me to have the pkg.fmri
omitted from the signature. I can't yet articulate what it is that is
making me feel it is "wrong" and it might well be okay. I'll think
about it for a bit and get back to you.
--
Darren J Moffat
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
