I should clear up some things on this thread.
There is a big difference between Apache and Tomcat here.
The original question here was about Apache:
"We have just been informed that there is a security vulnerability
in our production version of Apache. Is it possible to upgrade just
the Apache version in place? Any known pitfalls? Thanks in advance!"
whereas David is quoting a thread about Tomcat below.
I can't be certain which the original question intended to address --
only what it addressed literally.
As far as Apache is concerned:
* PTC supports other versions than those supplied by PTC. The
documentation includes instructions on applying a configuration
file overlay on top of a non-PTC Apache so that it can be
configured in a manner consistent with a PTC Apache. There are
plenty of details to get right here, e.g. the non-PTC supplied
Apache must supply all the modules PTC uses, must be of at least a
given minimum version, must be in the standard Apache layout, and
so on. Overall, it is far more work to get right than the PTC
supplied Apache, but it is an option if you really need it.
* PTC supplies the later versions of Apache in most every MOR.
Essentially each new Apache version is added to the MOR under
development at the time. Also, one can use Apaches from later
MORs with earlier MOR levels of Windchill.
* PTC also makes later Apache versions available on an expedited
basis via an early access page on the support site. These
releases are provided prior to the extensive testing that would
take place in an MOR cycle -- and thus are available sooner but
are less tested.
* Many Apache security issues do not apply to out-of-the-box use of
Apache by Windchill as many issues are in modules which are not
used by Windchill out-of-the-box. Some are quite applicable,
however, and PTC endeavors to make Apache updates available on a
timely basis.
As far as Tomcat is concerned:
* PTC does *not* support other versions that those supplied by PTC.
There are numerrous reasons for this, but the biggest are (1)
Apache is native code with various build options there are some
use cases for using one's own special Apache, whereas Tomcat is
Java code with standard cross-platform binaries for a given
version and (2) version (and patch) changes in Tomcat have a
bigger impact on Windchill behavior than version changes in Apache.
* New Tomcat versions occur fairly infrequently. PTC incorporates
these in MORs where this is deemed worthwhile (whether due to
security, performance, stability, or robustness fixes). As with
Apache, one can use Tomcats from later MORs with earlier MOR
levels of Windchill.
* Since Windchill deployments of Tomcat are behind a web server
(Apache or IIS), it is fairly infrequent to have a new Tomcat
version containing a security issue that applies to Windchill
deployments. It is rarer still for such an issue to be serious
(rather than a minor reduction in security-through-obscurity
through exposing JSP source code, for instance*).
--
Jess Holle
* I count exposure of JSP source code as a minor issue because no one
should ever put sensitive information, e.g. passwords, in JSP source
code. To the best of my knowledge no JSP in the product does anything
of the sort. If you believe you have such JSPs, then JSP source code
exposure is much more serious. If you have no such JSPs, then this
hiding JSP source is simply security-through-obscurity, which provides
little to no additional security.
