Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
|
|
This is one of the things pkglint checks, so _please_ use it.
|
|
XXX need to teach pkglint to be more picky about this
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
files at the _end_ of the CLASSPATH instead of the start so that users
can override selected functionality. For example, cocoon needs to override
tomcat's own XML parsing with that from Xerces-J if you want PDF generation
from XSL Formatting Objects to work.
|
|
a fair deal.
Changes from 3.0 (the last pkgsrc version) include:
* Thread pooling and JVM load balancing
* ISAPI and NSAPI integration
* A Command line JSP to Servlet Code tool
* Automatic generation of Apache configuration files
* Automatic deployment of Web ARchive (WAR) files
* Logging
* Substantially improved documentation
* Experimental servlet reloading
* Experimental security implementation
* Minimal Admin/Deployment Tool
* Internal APIs were changed for flexibility and integration
* The source code was cleaned and reorganized
* Most non-essential code was moved out of tomcat.core
* Greater platform / JVM level coverage
* Many, many bugs were fixed.
IMHO, this is _much_ closer to being a real, usable platform than 3.0 was
(as was intender - 3.0 was more of a proof of concept), and is very close
to being something to push into production -- I'm banking on a late 3.1.X
or 3.2 for that.
|
|
Tomcat so that it works out of the box with our Apache Server config.
|
|
|
|
|
|
|
|
|
|
currently
cannot build with kaffe, which I am looking into.
|
|
Server Pages engine.
This currently runs as a standalone http server with Servlet/JSP support,
and will be usable with Apache Server if/when we have a mod_jserv package.
I will look into that next, unless someone is already.
|