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

[Allen Hadden]

> Thanks for confirming that the last revision is not working as expected.
> Now we are back at the beginning. Could you apply this patch [1] and
> report back if it resolves your issue please?

Yes!  That fixed it for us.

Sorry again for the run around.

Allen

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Allen Hadden]

First off, thanks for your patience.  The thing I was missing was that the 
build procedure for Debian includes applying patches to the code.  I was 
following the build instructions from the BUILDING.txt file, which doesn't 
include the Debian-specific instructions.  That completely explains what I 
was seeing with inconsistent JAR file contents.

I will test each version from +deb7u5 until the problem occurs again and 
report my results.

Thanks!

Allen

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Allen Hadden]

> 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

I just ran through the various 7.0.28-4+deb7 versions from u4 through u10 
(it's a 
quick test to run so I just went through them sequentially). 

The only one that fails is 7.0.28-4+deb7u10.  All other builds work for 
us.

So at least Samuel's and my results are consistent (+deb8u8 and +deb7u10 
both
include the "infinite loop patch").

Allen


__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Allen Hadden]

The plot thickens!  I created a local build from git using the 
7.0.28-4+deb7u10 tag.  Interestingly when I did that I was unable to 
reproduce the problem.  Originally I suspected that there was something 
wrong with my build.  But after some digging, I'm starting to suspect the 
official build.  Here's why...

Note that I have 7.0.28-4+deb7u10 installed on my system:

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

Also that tomcat-coyote.jar is from that package:

$ dpkg-query -L libtomcat7-java | grep tomcat-coyote.jar
/usr/share/java/tomcat-coyote.jar
/usr/share/tomcat7/lib/tomcat-coyote.jar

(The first one is a symlink to the second one.)

I have attached two files, dist-tomcat-coyote-contents.txt and 
built-tomcat-coyote-contents.txt.  These files just contain the output of 
"unzip -t tomcat-coyote.jar".  Note that I chose that file because it 
contains the AbstractInputBuffer class.  I expected there to be no 
differences.  However, a diff of those files shows this:

$ diff dist-tomcat-coyote-contents.txt built-tomcat-coyote-contents.txt
1c1
< Archive:  /usr/share/tomcat7/lib/tomcat-coyote.jar
---
> Archive:  built-tomcat7-7.0.28-4+deb7u10/tomcat-coyote.jar
18,20d17
< testing: org/apache/tomcat/util/codec/   OK
< testing: org/apache/tomcat/util/codec/binary/   OK
< testing: org/apache/tomcat/util/collections/   OK
37d33
< testing: org/apache/tomcat/util/security/   OK
122d117
< testing: org/apache/coyote/http11/filters/LocalStrings.properties OK
270,280d264
< testing: org/apache/tomcat/util/codec/BinaryDecoder.class   OK
< testing: org/apache/tomcat/util/codec/BinaryEncoder.class   OK
< testing: org/apache/tomcat/util/codec/Decoder.class   OK
< testing: org/apache/tomcat/util/codec/DecoderException.class   OK
< testing: org/apache/tomcat/util/codec/Encoder.class   OK
< testing: org/apache/tomcat/util/codec/EncoderException.class   OK
< testing: org/apache/tomcat/util/codec/binary/Base64.class   OK
< testing: 
org/apache/tomcat/util/codec/binary/BaseNCodec$Context.class   OK
< testing: org/apache/tomcat/util/codec/binary/BaseNCodec.class   OK
< testing: org/apache/tomcat/util/codec/binary/StringUtils.class   OK
< testing: org/apache/tomcat/util/collections/ConcurrentCache.class OK
381c365,370
< testing: 
org/apache/tomcat/util/http/parser/HttpParser$SkipConstantResult.class OK
---
> testing: org/apache/tomcat/util/http/parser/AstAttribute.class   OK
> testing: org/apache/tomcat/util/http/parser/AstMediaType.class   OK
> testing: org/apache/tomcat/util/http/parser/AstParameter.class   OK
> testing: org/apache/tomcat/util/http/parser/AstSubType.class   OK
> testing: org/apache/tomcat/util/http/parser/AstType.class   OK
> testing: org/apache/tomcat/util/http/parser/AstValue.class   OK
383,384c372,381
< testing: org/apache/tomcat/util/http/parser/MediaType.class   OK
< testing: org/apache/tomcat/util/http/parser/MediaTypeCache.class OK
---
> testing: 
org/apache/tomcat/util/http/parser/HttpParserConstants.class   OK
> testing: 
org/apache/tomcat/util/http/parser/HttpParserTokenManager.class   OK
> testing: 
org/apache/tomcat/util/http/parser/HttpParserTreeConstants.class   OK
> testing: org/apache/tomcat/util/http/parser/JJTHttpParserState.class 
  OK
> testing: org/apache/tomcat/util/http/parser/Node.class   OK
> testing: org/apache/tomcat/util/http/parser/ParseException.class OK
> testing: org/apache/tomcat/util/http/parser/SimpleCharStream.class 
OK
> testing: org/apache/tomcat/util/http/parser/SimpleNode.class   OK
> testing: org/apache/tomcat/util/http/parser/Token.class   OK
> testing: org/apache/tomcat/util/http/parser/TokenMgrError.class   OK
482,484d478
< testing: org/apache/tomcat/util/security/PermissionCheck.class   OK
< testing: org/apache/tomcat/util/security/PrivilegedGetTccl.class OK
< testing: org/apache/tomcat/util/security/PrivilegedSetTccl.class OK
498c492
< No errors detected in compressed data of 
/usr/share/tomcat7/lib/tomcat-coyote.jar.
---
> No errors detected in compressed data of 
built-tomcat7-7.0.28-4+deb7u10/tomcat-coyote.jar.

The interesting thing about this to me is that some of those class files 
are supposed to be only in Tomcat 8 and not in Tomcat 7 (or only in Tomcat 
7 and not in Tomcat 8).

Is it possible that the build wasn't "clean" in that it contained some 
Tomcat 8 class files?  It certainly smells like that.

Thanks,
Allen




Archive:  /usr/share/tomcat7/lib/tomcat-coyote.jar
testing: META-INF/OK
testing: META-INF/MANIFEST.MF OK
testing: org/ OK
testing: org/apache/  OK
testing: org/apache/coyote/   OK
testing: org/apache/coyote/ajp/   OK
testing: org/apache/coyote/http11/   OK
testing: org/apache/coyote/http11/filters/   OK
testing: org/apache/coyote/http11/upgrade/   OK
testing: 

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

[Allen Hadden]

We are seeing the same thing that Samuel Wolf described, but from our web 
UI and with 7.0.28-4+deb7u10.  We get seemingly random 400 HTTP returns.

We downgraded to 7.0.28-4+deb7u4 and that problem went away.

Unfortunately in our environment the Tomcat-side Java exception is not 
being logged, so we have some more digging to do.  We do see the 400 error 
in the access log though.


__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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


__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.