Hash: SHA256


On 8/21/19 08:40, Olaf Kock wrote:
> On 20.08.19 21:43, Christopher Schultz wrote:
>> Olaf,
>> On 8/19/19 09:55, Olaf Kock wrote:
>>> If nothing changed since I looked at it last time, ubuntu
>>> didn't update to a new version, but at most backported some
>>> fixes while staying on roughly the same version. At least
>>> typically.
>>> I'm looking at the currently available information on the 
>>> "tomcat9" package in ubuntu 18.04, and I'm seeing version info 
>>> like "9.0.16-3~18.04.1".
>>> If you want to be on the latest and greatest tomcat version,
>>> you should rather maintain it for yourself. If you want the 
>>> distribution to maintain your tomcat, you're likely not on the
>>> very latest version.
>> While these two points are entirely accurate, we have two members
>> of the Tomcat community who are either package maintainers or who
>> can influence those maintainers.
>> We have Coty from RedHat who rolls some releases for RHEL/CentOS
>> and is pretty much up-to-date with all the releases. IIRC, the
>> yum repo tracks the "actual" version numbers from ASF while some
>> other package maintainers tend to back-port patches...
>> ... such as Debian (apt), where Emmanuel is (?) the package
>> manager
> Hi Chris,
> Thank you for the reminder - and thank you to the package
> maintainers for keeping the versions up to date - one way or
> another. The quoted Ubuntu version led me (repeatedly) down the
> track of assuming that this is how it's (still) everywhere, but I'm
> happy to be corrected.
> Old habits die slowly, and once you (well, me) have firmly
> established a habit, it's hard to revert. I'll work on it - after
> all, I like the perspective of not needing to think about most of
> my installation myself.
> Promising to go more pro-distro in the future.

I'm a proponent of distro-provided packages simply because their
auto-update (or at least auto-notify) capabilities. Having an
up-to-date system is essential to having a secure one.

That said, I still install my own Tomcat packages for the exact reason
you laid out above: package-maintained distributions are necessarily
"behind" those available from ASF and, often, the version numbering is
hard to decode. Whe you download 9.0.15 tom ASF, you know exactly what
you are getting. If your package-manager-installed version of the
apache-tomcat-9.0 reports "9.0.15" when you start, it may be "9.0.15
plus back-ports of high-priority security issues up through
2019-07-09" or something like that.

Debian is a *very* conservative distribution and I completely
understand why they only pack-port security-related items and not
features, optimizations, etc. that may be shipped in each
point-release of Tomcat.

That said, it would be nice if it were more obvious as to what is
included in each release. This is what I can see when I run "apt-get
changelog tomcat8". The most recent version available is shown here:

> tomcat8 (8.5.14-1+deb9u3) stretch-security; urgency=high
> [ Emmanuel Bourg ] * Fixed CVE-2018-1304: Security constraints
> mapped to context root are ignored. The URL pattern of "" (the
> empty string) which exactly maps to the context root was not
> correctly handled when used as part of a security constraint
> definition. This caused the constraint to be ignored. It was, 
> therefore, possible for unauthorised users to gain access to web 
> application resources that should have been protected. Only
> security constraints with a URL pattern of the empty string were
> affected. * Fixed CVE-2018-1305: Security constraint annotations
> applied too late. Security constraints defined by annotations of
> Servlets were only applied once a Servlet had been loaded. Because
> security constraints defined in this way apply to the URL pattern
> and any URLs below that point, it was possible - depending on the
> order Servlets were loaded - for some security constraints not to
> be applied. This could have exposed resources to users who were not
> authorised to access them. * Changed the Class-Path manifest entry
> of tomcat8-jasper.jar to use the specification jars from
> libtomcat8-java instead of libservlet3.1-java (Closes: #867247)
> [ Markus Koschany ] * Fix CVE-2018-1336: An improper handing of
> overflow in the UTF-8 decoder with supplementary characters can
> lead to an infinite loop in the decoder causing a Denial of
> Service. * Fix CVE-2018-8034: The host name verification when using
> TLS with the WebSocket client was missing. It is now enabled by
> default. * Fix CVE-2018-8037: If an async request was completed by
> the application at the same time as the container triggered the
> async timeout, a race condition existed that could result in a user
> seeing a response intended for a different user. An additional
> issue was present in the NIO and NIO2 connectors that did not
> correctly track the closure of the connection when an async request
> was completed by the application and timed out by the container at
> the same time. This could also result in a user seeing a response
> intended for another user.
> -- Markus Koschany <a...@debian.org>  Fri, 24 Aug 2018 21:44:12
> +0200

The first thing you'll notice is that the "current" version is 8.5.14.
That official version was released on 2017-04-18, but the Debian
version is "8.5.14-1+deb9u3". Obviously, there's "more" in there than
just 8.5.14.

I haven't downloaded the files, but it appears that you can grab
everything Debian uses to package Tomcat from here:

There is an "orig" file which is smaller than the stock ASF
distribution of the source code. Perhaps some stuff is just removed
from the distribution completely. Debian has separate packages,
example, for the common files, documentation, admin webapps, examples,

There is another file which looks like their collection of patches,
which are probably just the various commits which fix a particular
CVE, plus maybe a few tweaks necessary to get those patches to work

The changelog lists which CVEs have been fixed in this release, which
appears to have been from 2018-08-24, about a year ago. I can find
several "important" security notices since then that appear to not
have been been applied. I haven't read enough about the dependencies
to know whether those additional fixes were for things added/broken
AFTER 8.5.14 was released.

Debian wants to make sure that, without upgrading to a new major
release of Debian, that nobody gets "surprised" by anything coming
from upstream. This is a *very desirable feature* for administrators
who need to be able to rely on the fact that "apt-get update ; apt-get
upgrade" isn't going to break their system. Reliability fosters trust,
and trust improves security for everyone.

I'd love to have Emmanuel come to an ApacheCon and tell us "how the
sausage is made" (I hope that phrase is understandable to everyone,
here [1]). Coty gave a similar presentation in Miami that was very

For comparison:

$ yum list tomcat8
Loaded plugins: priorities, update-motd, upgrade-helper
Available Packages

So Amazon's yum repo contains 8.5.42 plus some patches, I guess, which
is only a single point-release behind. I can't figure out how to get
"yum changelog" to give me any output for the "tomcat8" package.

- -chris

[1] https://en.wiktionary.org/wiki/how_the_sausage_gets_made
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to