Bug#854551: 400 errors caused by 7.0.28-4+deb7u10

[Allen Hadden]

> 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:

    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:

First, confirm that the system has +deb7u10:

        $ dpkg-query -W -f '${Version}\n' libtomcat7-java
        7.0.28-4+deb7u10

Next, confirm that the PermissionCheck.class file is in the 
tomcat-coyote.jar 
file:

        $ unzip -t /usr/share/tomcat7/lib/tomcat-coyote.jar | grep 
PermissionCheck
        testing: org/apache/tomcat/util/security/PermissionCheck.class OK

So I would expect the corresponding java file to be in the source repo
at that tag, but it is not:

        $ git clone https://anonscm.debian.org/git/pkg-java/tomcat7.git
       ...
       $ cd tomcat7
       $ git checkout debian/7.0.28-4+deb7u10
       ...
       $ find . -name PermissionCheck.java

The find command finds shows nothing, but the official package contains
the class file.  Can you explain why?

Now, if you checkout the "master" branch:

        $ git checkout master
       ...

And see if the PermissionCheck.java file exists:

       $ find . -name PermissionCheck.*
        ./java/org/apache/tomcat/util/security/PermissionCheck.java

So the file exists on the master branch for tomcat7, but not at the
debian/7.0.28-4+deb7u10 tag.

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?

Thanks!

Allen