On Tue, Sep 01, 2009 at 03:50:05PM -0700, [email protected] wrote: > >>>> manifest.py: > >>>> particular, it doesn't look like we take any action beyond raising > >>>> an exception if verification fails. Bug 6011 details the need to > >>>> re-download corrupt manifests. If we're able to determine that a > >>>> manifest isn't valid, the transport needs to know that it encoutered > >>>> an error while downloading the manifest, and we should re-download > >>>> the manifest's content; however, I don't see either of these things > >>>> happening here. Is this part of Phase III? > >>> Yes and no. For the client to get the manifest signature data, the > >>> server has to provide v1 catalogs. So the completion of the plumbing > >>> work will be done in Phase III, but I will be opening a bug for > >>> another enterprising soul to take advantage of the new aqueduct :) > >> > >> Yes, however the step that catches either a MalformedActionError or a > >> MyManifestDidntVerify error ought to be generic. I would suggest that > >> since we're going to the trouble of adding manifest signatures and > >> catalog signatures, we should verify them both too. I'm willing to do > >> the transport side of the work for both of these, but I think we need to > >> be in agreement that this is part of the Phase III deliverables in order > >> for that to happen. > > > > My current schedule demands don't allow me to personally be the party to > > deliver those, so I'll have to pass. I'm putting all the plumbing in > > place because it is so inter-twined with the existing work I'm doing, > > but I really don't have the time to do the extra work on top of that. > > I disagree with writing code that's not going to be put into use. We > saw what happened to the rename code that didn't get used. It got > broken, and then lingered in a twilight of non-existence, and eventually > had to be removed since it no longer fulfilled its intended purpose. > > I'm not asking you to do all of the work and I'm offering to help. I > don't think it makes sense to putback code that's going to be used at > some future indeterminate time. In particular, it would be bad if we > discovered that the eventual verification method didn't return correct > results when applied to historical manifest versions that contain these > signatures. In order to ensure that this code works when it's putback, > and continues to work, we should verify the manifests against their > attached signatures.
Just to put this to rest, Shawn and I talked offline. The consensus was that the manifest verification code should be able to be used by the transport, provided the v1 catalog contains the signatures. I'll try to get this included in my portion of the transport work for phase III. If that's somehow not feasibile, I'll put it back in a later fix. The project that focuses on having trusted entities sign manifests for later verfication is separate from this work. This is mostly just verifying that the content wasn't corrupted during transfer. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
