have it be automatically included by bsd.pkg.mk if USE_PKGINSTALL is set
to "YES". This enforces the requirement that bsd.pkg.install.mk be
included at the end of a package Makefile. Idea suggested by Julio M.
Merino Vidal <jmmv at menta.net>.
tomcat makes mistaken assumptions about which revisions of java some
features became available in, and to ensure that the package works with
both jdk-1.1 and later (emulated) jdks.
We are not advancing to the 3.3 or 4.0 branches at the moment, as neither
will work with our native JDK without a lot more work.
Changes since Tomcat 3.2.3 (the last pkgsrc version):
7.1 Fixes and Enhancements in Release 3.2.4
This section highlights the bugs fixed in this release.
- Cookie name expires is a reserved token (#1114)
- Thread initialization problem in thread pool (#1745)
- AJP12 returned invalid HTTP headers when redirecting to very
long URLS (#2333)
- Fixed casting problem in JspFactoryImpl.getPageContext(). (#4260)
- Setting sesstion-timeout in web.xml did not prevent sessions from
timing out. (#4412)
- Fixed race condition in ServerSocketFactory.getDefault(). (#4418)
- Removed the restrictions on encoded spcecial characters in URLs
that was added as a security precaution in 3.2.3. The encoded
special characters are not decoded and remain the URL and
path info returned to servlets.
- Jk_nt_service now supports the ability to be restarted automatically
by the Windows 2000 service control manager if Tomcat terminates
abnormally.
- Fixed invalid servlet mapping in web.xml generated by JspC (#3474, #3499)
- Added findResource() and findResources() to AdaptiveClassLoader12
- A Date: HTTP header is now sent in responses when running stand
alone. (#345)
- Simple held on to a reference to removed objects preventing
garbage collection.
- Tomcat 3.2.4 now ships with JAXP 1.1. Prior releases used
JAXP 1.0.1. Tomcat 3.2.4 remains completely compatible with
the older version of JAXP and there is no requirement for users
to upgrade to JAXP 1.1 unless their applications require the new
version.
- Fixed NullPointerException in HttpConnectionHandler. (#4577)
7.2 Security Vulnerabilities fixed in Tomcat 3.2.4
The randomness of generated session ids has been enhanced to prevent the
generation of guessable ids.
foo-* to foo-[0-9]*. This is to cause the dependencies to match only the
packages whose base package name is "foo", and not those named "foo-bar".
A concrete example is p5-Net-* matching p5-Net-DNS as well as p5-Net. Also
change dependency examples in Packages.txt to reflect this.
* include a workers.properties which works out of the box -- this
file may be better off as part of the ap-jk package, even though it
is somewhat tomcat-specific. I'll give this possibility more thought.
* modify the apache config file fragment generator which runs on tomcat
startup to generate an Include-able apache config file fragment which
works out of the box to laod mod_jk.
Changes in the package since version 3.1.1 (the last pkgsrc version):
=====================================================================
* tomcat is now always installed under ${PREFIX}/tomcat. Making
${TOMCAT_HOME} configurable added much complexity for not real
gain.
It had been my intention to aim for a hier(7) like install for
tomcat with this version, but at this point there are way to many
hard-coded relative paths (relative to tomcat.home) in tomcat,
and in addition, all of the (quite good, really) documentation
assumes the standard install paths.
Note that the previous default value of ${TOMCAT_HOME} was
${PREFIX}/jakarta/tomcat.
* an rc.subr compatible (but not requiring) startup script is now installed
as ${PREFIX}/etc/rc.d/tomcat.
* if Sun's JSSE (Java Secure Socket Extensions) is in ${CLASSPATH} when
the pkg is built, tomcat will be built with support for SSL in the
standalone server mode. This soft dependency will be replaced by a
hard dependency as soon as I get a chance to import a JSSE package
(soon).
* likewise, I will import an ap-jk package for the new apache connector
(mod_jk) soon. ap-jserv continues to be usable for this purpose.
Changes in tomcat itself since version 3.1.1:
=============================================
New in tomcat-3.2.1:
--------------------
Tomcat 3.2.1 is a maintenance and bug fix release, based on the Tomcat 3.2
(final) code base. The following changes are included:
- Disallowed requesting JSP pages under the WEB-INF directory
(/WEB-INF/dummy.jsp). Previously, only requests for static files
were being disallowed.
- The JDBCRealm request interceptor will now log the description of any
JDBC exception that occurs, to aid in debugging.
SECURITY VULNERABILITIES FIXED IN TOMCAT 3.2.1
(note that these fixes were also made to the tomcat-3.1 branch in tomcat 3.1.1)
Protection of Resources in /WEB-INF and /META-INF Directories
The servlet specification prohibits servlet containers from serving resources
in the /WEB-INF and /META-INF directories of a web application archive directly
to clients. In Tomcat 3.2, this means that URLs like:
http://localhost:8080/examples/WEB-INF/web.xml
will return an error message, rather than the contents of your deployment
descriptor. However, there is a vulnerability in Tomcat 3.2 that exposes
this information if the client requests a URL like this instead:
http://localhost:8080/examples//WEB-INF/web.xml
(note the double slash before "WEB-INF"). This vulnerability has been
corrected in Tomcat 3.2.1.
Show Source Vulnerability
The example application delivered with Tomcat 3.2 included a mechanism to
display the source code for the JSP page examples. This mechanism could
be used to bypass the restrictions on displaying sensitive information in
the WEB-INF and META-INF directories. This vulnerability has been removed.
New in tomcat-3.2:
------------------
Tomcat 3.2 is mainly a performance tune-up release, although a few new
features have been added.
- Support for mod_jk, which is a replacement to the elderly mod_jserv, has
had several bugs fixed and has received much more testing. It is now
recommended that all users use mod_jk instead of mod_jserv.
- Support JAXP-based XML parser independence.
- New and often requested "how-to" documents covering the following topics:
- Configuring workers.properties
- IIS and Netscape configuration
- Running tomcat inside an IIS or Netscape process
- Running Tomcat as a Windows NT service
- Configuring a JDBC realm
- Configuring mod_jk
- First round of policy-based security support intended for running untrusted
code inside of Tomcat. Interested users should test this support and post
feedback to the Tomcat users mailing list.
- SSL support for standalone Tomcat. (Preliminary support first appeared in
3.1, but the support in 3.2 has received more testing and documentation
support).
- Thread reuse is now enabled by default. The thread pool support code was part
of 3.1, but not enabled since it was new.
- Support for plug-able session managers. Unfortunately, no how-to documents
that support this functionality exist (yet). For the adventurous, be aware
that the interface that allows administrators to plug session managers is
the normal Interceptor interface.
- An almost total rewrite of the HTTP request handling now results in improved
performance when running Tomcat stand-alone.
- Significantly reduced garbage collection.
- The code underwent a refactoring effort resulting in improved readability.
- And of course, hundreds of miscellaneous improvements and fixes.
a little hostile to anyone who is actually using tomcat and would prefer
to not have their apps nuked on package update.
Tomcat wipes webapps/ROOT, webapps/examples, and webapps/test directories
on install anyway, so replace the above with entries for those directories.
This allows anyone using other directories in webapps to keep their apps on
package update.
Convert most MESSAGE files to new syntax (${VARIABLE} gets replaced,
not @VARIABLE@, nor @@VARIABLE@@).
By default, substitutions are done for LOCALBASE, PKGNAME, PREFIX,
X11BASE, X11PREFIX; additional patterns can be added via MESSAGE_SUBST.
Clean up some packages while I'm there; add RCS tags to most MESSAGEs.
Remove some uninteresting MESSAGEs.
vulnerabilities file will be updated.
Changes from jakarta-tomcat-3.1:
===============================================================================
6. SECURITY VULNERABILITIES FIXED IN TOMCAT 3.1.1
6.1 Administrative Application Enabled By Default
The administrative application (at context path "/admin") was enabled by
default in Tomcat 3.1, which allowed unauthenticated remote users to add and
remove appliations from a running Tomcat 3.1 installation if it was left
installed.
To avoid such problems, the administrative application has been removed from
the binary distribution of Tomcat 3.1.1. It can be installed if desired by:
- Downloading the source distribution of Tomcat 3.1.1.
- Modifying the "build.xml" file to remove the commenting around the
logic that creates the adminstrative application.
- Running the build.sh or build.bat script.
6.2 Case Sensitive Matches on Static Resources
In Tomcat 3.1, matches against the filenames of static resources was done in a
case insensitive manner on case insensitive platforms (such as Microsoft
Windows). This can cause sensitive information to be exposed to remote users
who experiment with differently cased request URIs.
To avoid such problems, Tomcat 3.1.1 performs filename comparisons for static
resources in a case sensitive manner, even on Windows. This means that your
hyperlinks must specify the correct case, or a 404 error will be returned.
Because this can cause significant conversion problems for existing
applications deployed on Tomcat 3.1, a configuration option is provided to
temporarily turn off case sensitive matching. Edit the file "conf/web.xml"
and modify the value for the "caseSensitive" initialization parameter to the
default file-serving servlet.
WARNING: CHANGING THIS SETTING WILL RE-INTRODUCE THE SECURITY VULNERABILITY
PRESENT IN TOMCAT 3.1 -- IT IS *STRONGLY* RECOMMENDED THAT YOU CORRECT YOUR
URLS TO MATCH CORRECTLY INSTEAD OF USING THIS OPTION. Note: All later
versions of Tomcat perform filename matches in a case sensitive manner.
6.3 Snoop Servlet Mappings in Example Application
In the deployment descriptor for the example application delivered with
Tomcat 3.1, a "snoop" servlet was mapped to URL patterns "/snoop" and
"*.snp". Theses mappings (in particular the second one) could cause exposure
of sensitive information on the internal organization of your web application
(for example, when a non-existent page "foo.snp" is requested).
To avoid these problems, the offending mappings have been commented out.
6.4 Show Source Vulnerability
The example application delivered with Tomcat 3.1 included a mechanism to
display the source code for the JSP page examples. This mechanism could
be used to bypass the restrictions on displaying sensitive information in
the WEB-INF and META-INF directories. This vulnerability has been removed.
6.5 Requesting Unknown JSP Pages
In Tomcat 3.1, the error message in response to a request for an unknown JSP
page would include the absolute disk file pathname of the corresponding file
which could not be found, which exposes sensitive information about how your
application is deployed. The error message has been adjusted to include only
the context-relative path of the JSP page which could not be found.
6.6 Session ID Vulnerability
The algorithm used to calculate session identifiers for new sessions was
subject to attack by attempting to guess what the next session identifier will
be, and therefore hijack the session. In addition, the generated identifier
exposed sensitive information (the number of sessions that have been created
since this web application was started.
To avoid these problems, the session identifier generation algorithm has been
replaced by the algorithm used in Tomcat 3.2, which is not subject to these
attacks, and does not expose session count information.
6.7 Server Shutdown Vulnerability
In Tomcat 3.1, it was possible to establish a remote network connection to the
AJP12 connector and cause Tomcat to shut itself down. Now, this network
connection must be created from the same server that Tomcat is running on.
NOTE: While this is more secure than Tomcat 3.1 (and mirrors the protection
provided by Tomcat 3.2), it is still vulnerable to attack by users who can
create socket connections from the server. Suitable use of firewalls and
"TCP Wrappers" applications are suggested around the APJ12 port.
