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

[Markus Koschany]

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20170217/3c82b843/attachment.sig>