Hi Leif -- I just found this old email in my drafts folder, whoops!
What's going on with the signing stuff? Have you discovered anything interesting recently? Antique comments from original mail inline... On Tue, 14 Jan 2003, at 16:20 [+0900], Leif Mortenson ([EMAIL PROTECTED]: > Gary Shea wrote: > > >Hey Leif -- > > > >I have been through the same exercise recently. I suspect that Sun > >decided that problem is in WebStart, but I'm not sure. That was my > >take on it, but I didn't realize that an earlier version of jarsigner > >actually 'signed' the directory entries. That doesn't make a lot of > >sense to me... how do you compute a digest on a directory? Anyway, I > >went through all the bugs at WebStart, didn't find a corresponding one, > >so I added it. It appears to still be in the internal review phase. > > > Looking at the two signed versions, it looks like they both sign the > directories. As you > say, what exactly they are computing the digest on, I am not sure. > > What is the bug that you added? > > >As a short-term fix, I ran some tests with all the non-file entries > >stripped out of xml-api.jar's manifest, and as I recall it worked. > >That was using merlin, though, not phoenix. > > > >Hardly a satisfactory solution... > > > I don't think that this has anything to do with Phoenix at all. Phyre > simply has a block > which resoponds to requests for the individual jar files used by the > WebStart and > then sends them to the client as is. The security error is happening > within WebStart. Right. What I'm saying is that when I removed that troublesome entry from the xml-api manifest, my code still worked fine. But I only tested it with merlin. I'm assuming that neither merlin nor phoenix need that entry in the manifest, but since I know nothing about phoenix, I could be wrong! I found the troublesome entries by removing every entry (I thought that I found several but maybe that's wrong...) which had no evidence of being signed. > > I am attaching the manifest.mf files from the original xml-api.jar, the > xml-api.jar signed > using v1.3.1_03 and the version signed using v1.4.1_01 > > It was a $%$@! to figure out what the differences were because they go > and write > the resulting manifests in completely different orders, but the problem > appears to be > the following entry in the original file: > > --- > Name: org/apache/xmlcommons/Version > Implementation-Vendor: Apache Software Foundation > Implementation-URL: http://xml.apache.org/commons/ > Comment: XmlCommons for http://xml.apache.org/ subproject's use > Implementation-Title: org.apache.xmlcommons.Version > Implementation-Version: 1.0.b2 > --- > > In the version signed by 1.4.1_01 it looks as follows: > (Unmodified other than order) > --- > Name: org/apache/xmlcommons/Version > Implementation-Title: org.apache.xmlcommons.Version > Comment: XmlCommons for http://xml.apache.org/ subproject's use > Implementation-Version: 1.0.b2 > Implementation-Vendor: Apache Software Foundation > Implementation-URL: http://xml.apache.org/commons/ > --- > > But in the 1.3.1_03 file this entry was completely ommitted. > > I have not checked to make sure there are no other changes, but that makes > up for the 7 line difference in the two files' sizes. > > > Now. Looking in the actual xml-api.jar file. There is not a directory > with that name. > There is a single class in the parent directory called: > org/apache/xmlcommons/Version.class > > This makes me wonder if this is a bug in the original manifest in the > xml-api.jar file? > > Cheers, > Leif A similar situation came up where I had an entry in one of my jar manifests for a file that did not exist (it was my mistake of course). jarsigner did not sign it, and of course web start freaked out. Exactly the kind of problem we're having with that So... it sounds like that old jarsigner or jar program stripped out manifest entries for non-existant paths. Apparently this turned out to be problematic behaviour, as they pulled it out again. Too bad for us! Gary --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
