On Wed, Jan 27, 2010 at 06:24:42PM -0600, Shawn Walker wrote: > On 01/27/10 06:17 PM, [email protected] wrote: > >Folks, > >The following is a short diff that addresses the traceback seen in > >14201. The fix is small enough that I didn't bother with a webrev. > > > >diff -r 4409e56754c5 -r d9d66d2f1635 > >src/modules/client/transport/transport.py > >--- a/src/modules/client/transport/transport.py Tue Jan 26 15:42:52 > >2010 +0000 > >+++ b/src/modules/client/transport/transport.py Wed Jan 27 16:14:40 > >2010 -0800 > >@@ -975,7 +975,10 @@ > > # Get publisher information from FMRI. > > pub = self.__img.get_publisher(fmri.get_publisher()) > > # Use the publisher to get the catalog and its signature > > info. > >- sigs = dict(pub.catalog.get_entry_signatures(fmri)) > >+ try: > >+ sigs = dict(pub.catalog.get_entry_signatures(fmri)) > >+ except apx.UnknownCatalogEntry: > >+ return False > > > > if sigs and "sha-1" in sigs: > > chash = sigs["sha-1"] > > This change or changing get_entry_signatures() to return None and > checking for that is perfectly fine with me.
I opted for a simpler fix, since it wasn't clear if this exception was going to be raised frequently. Your opinion was that it was unlikely to be common, and I'm fine with that assessment if you're convinced. > I remain concerned as I previously indicated that there is a larger > issue that ultimately caused this, although I still believe > transport should check for the no signature data case just in case > there is a consistency issue between origins, etc. I'm not trying to be insenstive to your concerns, but I don't have a lot of options. If the transport successfully downloads the file, but it can't get the signature data, the most conservative approach is to conclude that this file was wanted. In the 14201, the stack trace showed that this manifest was fetched out of get_manifest(), so the manifest was requested as a necessary retrieval to perform the installation. If the manifest still names valid files that exist on the server, should we really abort the installation? The verify_manifest() function just needs to determine if it can verify a manifest. If it can, it will and will throw an exception if the manifest is invalid. If we can retrieve the manifest, and it references existing content, that doesn't seem inherently invalid. I'd be comfortable making this a permanent failure if we had a per-publisher policy that states that all catalogs from a particular publisher must have signatures, and the signatures must be valid. That would also give us an opportunity to double-check this when the catalog is retrieved. That wouldn't solve the absent package case, but we could at least verify that when the catalog was downloaded it was self consistent. > If you'd be kind enough to file another entry for the first part of > the problem under api-python, it would be appreciated. I have filed this bug: 14211 Client may ask for package that is not in a publisher's catalog Please feel free to change its purpose if I incorrectly described the problem in the description. Thanks, -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
