On 17.02.2017 14:24, Allen Hadden wrote: >> That is strange. You have mentioned in your previous email that you >> downgraded tomcat7 in Wheezy to version 7.0.28-4+deb7u4. Are you sure >> that you are not comparing this version with 7.0.28-4+deb7u10? Why >> didn't you downgrade to 7.0.28-4+deb7u9 in the first place? This would >> explain the diff output because we had to make some bigger changes to >> the http parser classes in one of the previous security updates before >> +deb7u9 in Wheezy. > > We downgraded to +deb7u4 because it was the last known good version on > the system where we first noticed the problem. +deb8u9 is not available > on the security update server:
You can download previous versions of Tomcat 7 from snapshots.debian.org http://snapshot.debian.org/package/tomcat7/ Let's recapitulate: You are currently running +deb7u4 from April 2016 which is the last good version for you and you see 400 errors when you use +deb7u5 or any later version up to +deb7u10, correct? Then this is a different issue because Samuel reported that the 400 errors occurred when he upgraded from 7.0.56-3+deb8u7 to 7.0.56-3+deb8u8 in Jessie > > http://security.debian.org/pool/updates/main/t/tomcat7/ > > I guess we can distill my last email down a little. Let's focus on > PermissionCheck.class. It is definitely in the +deb7u10 package. You > can use the following steps to confirm: [...] > The find command finds shows nothing, but the official package contains > the class file. Can you explain why? Sure, the original tarball does not contain PermissionCheck.java but in order to resolve CVE-2016-6794 we had to patch Tomcat 7 again and applied this patch: https://anonscm.debian.org/cgit/pkg-java/tomcat7.git/diff/debian/patches/CVE-2016-6794.patch?h=wheezy&id=b0a66d829f152186b8e260dfcffa919b0b694cf4 This was done for +deb7u7. The class is present in debian/patches. [...] > > As I see it, these are the possibilities: > > a) The build was done from a tag other than debian/7.0.28-4+deb7u10. > b) It was done from that tag, but there were other .class files > present in the output directory (i.e. it wasn't a clean build). > > Any thoughts? I think none of the above happened and the error is not caused because of an unclean environment.
signature.asc
Description: OpenPGP digital signature
__ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use [email protected] for discussions and questions.
