https://bz.apache.org/bugzilla/show_bug.cgi?id=60963
--- Comment #12 from Thomas Meyer <tho...@m3y3r.de> --- (In reply to Konstantin Kolinko from comment #11) > (In reply to Thomas Meyer from comment #8) > > > > Theoretically we want those bytes to be counted, but the ZipInputStream > > doesn't read anything in it's construction phase, that's why the whole "fast > > forward skipping works at all". > > And yes this is a somewhat hackish solution but it works. > > > > 1. I do not know whether this is a concern (I have not looked at the patch), > but note the behaviour that was recently reported as bug 60940: > > JarInputStream constructor does read MANIFEST.MF and META-INF/ directory > entry that may precede it. Yes, I saw this and it's still done after the patch. What I didn't finish to understand is the validation of the signed MANIFEST.MF entries. Is it really enough to just read through the whole JAR file with a JarInputStream with getNextJarEntry() and everything is automagically checked for correctness? Do we care that a WAR file contains only correct signed JAR files? I never really was involved in the topic signed war files and/or containing jar files inside a war file. > > 2. Zip* and Jar* APIs differ in their handling of i18n filenames. JAR > specification uses UTF-8 for file names, Zip uses platform encoding by > default. That is an important hint, I think we should really go for an minimal functional ZIP "PK entry" parser to extract the offset of each "PK entry start", to fast forward in the jar file inside the war file. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
