Garrett D'Amore wrote: > Bart Smaalders wrote: >> Stephen Hahn wrote: >> >>> I am having difficulty formulating a use case where nested or multiply >>> signed packages are needed, and in which the consumer makes different >>> decisions when distinct subsets of the signing entities cannot be >>> independently verified. Maybe someone has an example? >> >> Multiply signed packages are useful, as others have pointed out, to >> permit systems to require multiple signatures, or permit alternate >> signatures. >> >> The easiest way to do this is to omit all signatures from the >> hash; adding a new signature would then not invalidate previous ones. >> >> - Bart >> > The concern was that the meta data that would be added was also signed. > > Certainly the *contents*, as well as critical portions of meta data > (dependencies and anything else that might impact how the software is > installed or behavior) probably could be covered by a single hash. > > Other meta data (yes, OurBigEnterprise-IT-Dept blesses this package, on > Jun 5, 2020...) may also need a separate signature, covering the meta > data, and the aforementioned hash. > > (So it sounds like we might want to classify meta-data somewhat. Those > that don't change after a package is created, and those that do.) > > - Garrett >
I don't understand. What is wrong with simply allowing multiple signature by the simple expedient of not including signatures in the hash. This is a very natural thing to do, since it simply requires removing all signatures from the manifest and then computing the hash. Doing otherwise means that a hierarchal manifest of arbitrary nesting depth is required; this complexity doesn't seem to be justified by any real requirements. There's plenty of track to be laid on this project w/o adding more for the use of invisible trains. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird."
