John Plocher wrote:
> Stephen Hahn wrote:
>> I am having difficulty formulating a use case where nested or multiply
>> signed packages are needed,
>
> Imagine that IT Sets up a depot of their own, and fills it with a
> "mirror"
> of the official packages. Furthermore, because the upstream repo they
> are mirroring has lots of versions of things in it, they wish to add
> metadata
> to selected packages that says "Recommended by your local IT department".
>
> To do this, they would take a version of (say) the "Official" Mozilla
> package
> and add their own metadata to it.
>
> In this use case, adding metadata to a package does not necessarily
> invalidate
> its authenticity.
>
> -John
Right. And furthermore, for many people in the organization, if they
don't have the original IT dept's root cert, they can at least still
validate that bits properly came from some trusted (Sun, or wherever)
source.
The other thing is that Sun (or some other support organization) might
insist on verifying that the bits installed were the same bits they
delivered. Having the IT department break the thing apart and resign it
(thus invalidating the original signatures) might compromise the ability
of different support organizations to be confident in the delivered bits.
The only time I would have a concern is if the metadata could somehow
change the behavior of a package, where IT's "tagging" somehow could
alter the behavior of the package. In that case, I'd worry more. I've
not heard that the meta data involved can do this, but perhaps I'm
missing something.
-- Garrett
