[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

2005-01-06 Thread Bill Barker
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 38 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/bin/sh 
/usr/local/gump/public/workspace/apache-httpd/dest-06012005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-06012005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR 
-I/usr/local/gump/public/workspace/apr/dest-06012005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-06012005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-06012005/build/libtool: No 
such file or directory
make[1]: *** [jk_ajp12_worker.lo] Error 127
make[1]: Leaving directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
make: *** [all-recursive] Error 1
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2006012005, brutus:brutus-public:2006012005
Gump E-mail Identifier (unique within run) #17.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25965.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25965


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm JDBCRealm.java

2005-01-06 Thread remm
remm2005/01/06 03:33:23

  Modified:catalina/src/share/org/apache/catalina/realm JDBCRealm.java
  Log:
  - Also log the exception.
  
  Revision  ChangesPath
  1.10  +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java
  
  Index: JDBCRealm.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- JDBCRealm.java22 Nov 2004 22:42:28 -  1.9
  +++ JDBCRealm.java6 Jan 2005 11:33:22 -   1.10
  @@ -540,7 +540,7 @@
   } catch(SQLException e){
   container.getLogger().
   error(sm.getString(jdbcRealm.getPassword.exception,
  -   username));
  +   username), e);
   } finally {
   if (rs!=null) {
   try {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 32646] - Serious: Exception retrieving password for username

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32646.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32646





--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 12:35 ---
I've just added logging of the exception to get more details. This code section
doesn't access the session, so I don't see why it would fail.

I recommend migrating to the datasource realm, BTW.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 31659] - Page context not fully populated for Exception if using app-wide error page

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31659.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31659


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement
 OS/Version|Windows XP  |All
Version|5.0.28  |Unknown




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 17014] - ServletResponse.flushBuffer() no longer commits the response

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=17014.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=17014


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC|[EMAIL PROTECTED]|
   |m   |




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 32569] - ServletContextListener will not die

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32569.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32569





--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 13:14 ---
Where is applicationListeners[] array refreshed, at redeployment?

StandardContext, declaration:
/**
 * The set of application listener class names configured for this
 * application, in the order they were encountered in the web.xml file.
 */
private String applicationListeners[] = new String[0];

StandardContext:
  assign String[0], at declaration
  reassign String[0], in method destroy 
  modify array in remove/addApplicationListeners

Doing:
 cd jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina
 egrep (add|remove)ApplicationListener -r * 
 print out only declarations or calls to add, no remove

 

 


   

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-connectors/coyote build.xml

2005-01-06 Thread remm
remm2005/01/06 04:42:13

  Modified:.build.xml
   coyote   build.xml
  Log:
  - Don't create the coyote JAR for TC 5.
  
  Revision  ChangesPath
  1.220 +1 -4  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.219
  retrieving revision 1.220
  diff -u -r1.219 -r1.220
  --- build.xml 14 Oct 2004 07:40:34 -  1.219
  +++ build.xml 6 Jan 2005 12:42:13 -   1.220
  @@ -239,13 +239,10 @@
 depends=init description=Build j-t-c/coyote
   echo== Building: tomcat-coyote /echo
   
  -ant dir=${jtc.home}/coyote target=jar.tomcat5
  +ant dir=${jtc.home}/coyote target=compile.tomcat5
 property name=catalina.home value=${tomcat.build}/
 property name=build.home value=${tomcat.build}/
 property name=tomcat5.detect value=true/
  -  !--
  -  property name=tomcat-coyote.jar 
value=${tomcat.build}/server/lib/tomcat-coyote.jar /
  -  --
 property name=tomcat-util.jar
   value=${tomcat.build}/server/lib/tomcat-util.jar/
 property name=servlet.jar   value=${servlet-api.jar}/
  
  
  
  1.31  +3 -2  jakarta-tomcat-connectors/coyote/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/build.xml,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- build.xml 1 Sep 2004 10:10:48 -   1.30
  +++ build.xml 6 Jan 2005 12:42:13 -   1.31
  @@ -214,6 +214,7 @@
   
   
 target name=compile.tomcat5 if=tomcat5.detect
  +   depends=static,compile.shared
  description=Compile Tomcat 5.x Adapter
   javac  srcdir=${source.home}
  destdir=${build.home}/classes
  @@ -225,7 +226,7 @@
   /javac
 /target
   
  -  target name=jar.tomcat5 depends=static,compile.shared,compile.tomcat5 

  +  target name=jar.tomcat5 depends=compile.tomcat5 
   jar  jarfile=${tomcat-coyote.jar}
index=true
basedir=${build.home}/classes
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

2005-01-06 Thread remm
remm2005/01/06 04:43:15

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  - Content length should be ignored if there is chunking.
  
  Revision  ChangesPath
  1.117 +8 -8  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.116
  retrieving revision 1.117
  diff -u -r1.116 -r1.117
  --- Http11Processor.java  10 Dec 2004 00:00:00 -  1.116
  +++ Http11Processor.java  6 Jan 2005 12:43:15 -   1.117
  @@ -1222,14 +1222,6 @@
   // Input filter setup
   InputFilter[] inputFilters = inputBuffer.getFilters();
   
  -// Parse content-length header
  -long contentLength = request.getContentLengthLong();
  -if (contentLength = 0) {
  -inputBuffer.addActiveFilter
  -(inputFilters[Constants.IDENTITY_FILTER]);
  -contentDelimitation = true;
  -}
  -
   // Parse transfer-encoding header
   MessageBytes transferEncodingValueMB = null;
   if (http11)
  @@ -1260,6 +1252,14 @@
   // 501 - Unimplemented
   response.setStatus(501);
   }
  +}
  +
  +// Parse content-length header
  +long contentLength = request.getContentLengthLong();
  +if (contentLength = 0  !contentDelimitation) {
  +inputBuffer.addActiveFilter
  +(inputFilters[Constants.IDENTITY_FILTER]);
  +contentDelimitation = true;
   }
   
   MessageBytes valueMB = headers.getValue(host);
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 32963] New: - lb setAttribute() spews bogus errors

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32963.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32963

   Summary: lb setAttribute() spews bogus errors
   Product: Tomcat 4
   Version: 4.1.31
  Platform: Macintosh
OS/Version: All
Status: NEW
  Severity: trivial
  Priority: P2
 Component: Connector:Coyote JK 2 (deprecated)
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Because necessary return JK_OKs are missing all over the place in 
setAttribute(), setting any attribute 
other than worker ends up with a bogus error message like the following:

[Thu Jan 06 22:06:31 2005] [notice] config.setAttribute() Error setting lb: 
stickySession 1
[Thu Jan 06 22:06:31 2005] [notice] config.update(): done lb:


else if (strcmp(name, attempts) == 0) {
lb_priv-attempts = atoi(value);
 return JK_OK SHOULD HAVE BEEN HERE 
}
return JK_ERR;
}

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 32963] - lb setAttribute() spews bogus errors

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32963.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32963


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 14:16 ---
JK2 is deprecated.
http://jakarta.apache.org/tomcat/connectors-doc/news/20041100.html#20041115.1

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



дºËÍ´óÀñ£¬Ïí·­Òë·þÎñµÃ10%¾ªÏ²»ØÀ¡

2005-01-06 Thread ²ÜÕæ
13126577889

--10%
[EMAIL PROTECTED] ([EMAIL PROTECTED]
[EMAIL PROTECTED])





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] JK 1.2.8 Stability

2005-01-06 Thread Remy Maucherat
Remy Maucherat wrote:
Mladen Turk wrote:
Jess Holle wrote:
For those of us lurking waiting for the outcome of this vote, it 
would seem to be extraordinarily slow

Yes. Seems like seasons time :).

I didn't vote because I didn't test it at all. Maybe I will tomorrow.
Question: would it be possible to provide mod_jk binaries for Apache 2.0 
on Windows ?

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: DO NOT REPLY [Bug 3534] - FileUpload doesn't work with Apache, mod_webapp and tomcat 4.0 RC1

2005-01-06 Thread Sander Temme
On Jan 5, 2005, at 9:04 PM, [EMAIL PROTECTED] wrote:

Bugzilla ran a sanity check last night, which caused some old mails to 
get sent. I don't know whether Bugzilla was correct about not having 
sent these, but this should not happen again.

My apologies for the inconvenience.
S.
--
[EMAIL PROTECTED]  http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF


smime.p7s
Description: S/MIME cryptographic signature


DO NOT REPLY [Bug 32967] New: - Session Id changing

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32967.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32967

   Summary: Session Id changing
   Product: Tomcat 5
   Version: 5.0.28
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Running an application on Tomcat and when I access the servlet, it seems that 
the session Id is changing for each new request coming in (same client).

I added a system.out to display my session Id and we get a different one each 
time.

here is the exact sys out:
System.out.println(ControllerUtil:  aRequest.getSession().getId():   + 
aRequest.getSession().getId());

We need to maintain the same session in order to retrieve the error codes that 
might be writtent to the session.

How does one have to go about to maintain the session info?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 32968] New: - [connectors][PATCH] Documentation fixes

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32968.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32968

   Summary: [connectors][PATCH] Documentation fixes
   Product: Tomcat 5
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:AJP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I'll attach patches for Jakarta Tomcat Connectors docs that fixes the following
problems:
- Corrected links that were dead
- Corrected spelling
- Revised the doccontrib document

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 32968] - [connectors][PATCH] Documentation fixes

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32968.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32968





--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 17:48 ---
Created an attachment (id=13911)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=13911action=view)
Documentation patches


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 32969] New: - [connectors] Remaining problems with documentation

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32969.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32969

   Summary: [connectors] Remaining problems with documentation
   Product: Tomcat 5
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:AJP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Here are some issues with the Jakarta Tomcat Connectors documentation that needs
to be discussed and corrected in some way.
 
There does not seem to be any links to the document
  /jk/xdocs/common/tools.xml
Should it be removed?
  
Directives for mod_jk are available in both
  /jk/xdocs/config/apache.xml
and
  /jk/xdocs/howto/apache.xml
They should be in one place to make it easier to maintain.

Building instructions are available in both
  /jk/xdocs/howto/apache.xml
and
  /jk/xdocs/install/apache1.xml and apache2.xml
They should be in one place to make it easier to maintain.

Change the sections in
  /jk/xdocs/changelog.xml
from
  Changes from JK 1.2.7
  Changes from JK 1.2.6
to
  Changes in JK 1.2.8
  Changes in JK 1.2.7
To make it more understandable.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 32967] - Session Id changing

2005-01-06 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32967.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32967


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 18:17 ---
Bugzilla is NOT a support forum.

Please ask questions like this on the tomcat-user mailing list

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java

2005-01-06 Thread pero
pero2005/01/06 12:15:23

  Modified:catalina/src/share/org/apache/catalina/realm Tag: TOMCAT_5_0
RealmBase.java
  Log:
  Hups a strange typo..
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.33.2.4  +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java
  
  Index: RealmBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
  retrieving revision 1.33.2.3
  retrieving revision 1.33.2.4
  diff -u -r1.33.2.3 -r1.33.2.4
  --- RealmBase.java9 Dec 2004 13:52:59 -   1.33.2.3
  +++ RealmBase.java6 Jan 2005 20:15:23 -   1.33.2.4
  @@ -1094,7 +1094,7 @@
   
   byte[] digest = null;
   // Bugzilla 32137
  -synchornized(md5Helper) {
  +synchronized(md5Helper) {
   digest = md5Helper.digest(valueBytes);
   }
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Pluggable mechanism for loading context config files

2005-01-06 Thread Roytman, Alex
Dear Tomcat developers,

I would like to implement context config file encryption. It is a pretty useful 
feature since passwords to various resources are stored in those files
Unfortunately the way how context config files are read is hard coded 
(InputSource for Digester is created from FileInputStream) and does not let me 
do so. 

It would be great if tomcat 5.5 provided some pluggable ConfigFileLoader in 
HostConfig (and may be on Engine level as well) to return InputStream for a 
given config file name (or decorator for FileInputStream ).
It would be also great if it were possible to register context config file 
extensions other then *.xml - it would allow to use *.exml for encrypted XML 
config files (will save us a test of the file to se if it is encrypted or plain 
text)

If it is not possible to make this enhancement may be you could re-factor 
ContextConfig class so it can be effectively subclassed and its input stream 
logic altered

All you would need to do is to factor out

    protected void processContextConfig(InputStream) {
    
    } 


from

    protected void processContextConfig(File file) {
    
    if (log.isDebugEnabled())
    log.debug(Processing context [ + context.getName() + ] 
configuration file  + file);
    
    // Add as watched resource so that cascade reload occurs if a default
    // config file is modified/added/removed
    context.addWatchedResource(file.getAbsolutePath());

    InputSource source = null;
    InputStream stream = null;
    try {
    if (file.exists()) {
    stream = new FileInputStream(file);
    source =
    new InputSource(file:// + file.getAbsolutePath());
    } else if (log.isDebugEnabled()) {
    log.debug(Context [ + context.getName() + ] configuration 
file  + file +  not found);
    }
    } catch (Exception e) {
    log.error(sm.getString(contextConfig.defaultMissing) + file);
    }
    if (source == null)
    return;
    if (contextDigester == null){
    contextDigester = createContextDigester();
    }
    synchronized (contextDigester) {
    try {
    source.setByteStream(stream);

.

If processContextConfig(InputStream) is available, we can override this method, 
read from encrypted stream, decrypt create decrypted stream in memory and pass 
it to the original (superclass)  processContextConfig(InputStream)


Thank you very much for your assistance

Alex Roytman
[EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JNDI resources available to auth realms?

2005-01-06 Thread Ian Flanigan
On Wed, 5 Jan 2005 18:54:08 -0500, Andrew Jaquith
[EMAIL PROTECTED] wrote:
 Greetings,
 
 A while back I did some patch work on the catalina.realm.JAASRealm
 class. I learned a lot in the process.

Thanks for your patches -- I've been using them!  In my JAAS
LoginModule, I also tried to use JNDI resources, but gave it up for
other reasons.  I would be very interested in any headway that you
make in this area.  Also, it seems that JNDI *should* work from within
the LoginModule since it's documented (by example) in the API docs:

http://jakarta.apache.org/tomcat/tomcat-5.0-doc/catalina/docs/api/org/apache/catalina/realm/JAASRealm.html

Speaking of the JAASRealm, I tried to get my LoginModule to load from
my webapp's classpath, but with no success.  So, what does the
useContextClassLoader do, exactly?

Thanks,

Ian Flanigan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Pluggable mechanism for loading context config files

2005-01-06 Thread Mark Thomas
Alex,
I would vote '-1' for any such addition Tomcat.
Let me explain why by way of a simple example. Let us assume that Tomcat
requires a plain text user name and password to connect to a database. 
First of all, consider the security risks if the information is stored 
in an unencrypted file somewhere on the server. Assuming that this file 
is not publicaly available, only users with access to the machine can 
access the file. With a little more configuration and possibly some 
network security only users with physical access to the machine can 
access the file and read the password.

If one or more 'untrusted' users has physical access to the machine it 
is pretty much game over from a security point of view. With physical 
access there are a whole host of potential attacks I can think of that 
would enable an attacker to gain access to the file.

Therefore, all we are trying to do is protect the contents of a file 
from a group of users all of whom are authorised to see it. What is the 
point?

Looking at it from another perspective, lets say we do encrypt the file. 
How does Tomcat decrypt it? Tomcat needs access to the decryption key. 
If this is in a file, the file needs to be protected. How do you do 
this? This is the same problem we had before. We have just added another 
layer. It is a chicken and egg situation with no solution. The same 
applies to providing the password via some 'service'. How does the 
Tomcat process authenticate to this service to retrieve the password? It 
needs some credentials. Where are these stored? In a file... and so we 
start all over again...

One thing that could work is not placing the password in a file at all 
but requiring it to be entered at start up. However, this exchanges a 
confidentiality security problem for an availability one - if the system 
fails it can only be restarted when there is someone present who knows 
the password. Also, people being people, there is a strong chance this 
password will get written down and your security has just got worse 
rather than better.

Ultimately, the best thing you can do is leave the password unencrypted 
in a file and make sure the machine is electronically and physically 
secured with the right policies and procedures to ensure that it remains 
secure.

Regards,
Mark
Roytman, Alex wrote:
Dear Tomcat developers,
I would like to implement context config file encryption. It is a pretty useful feature since passwords to various resources are stored in those files
Unfortunately the way how context config files are read is hard coded (InputSource for Digester is created from FileInputStream) and does not let me do so. 

It would be great if tomcat 5.5 provided some pluggable ConfigFileLoader in 
HostConfig (and may be on Engine level as well) to return InputStream for a 
given config file name (or decorator for FileInputStream ).
It would be also great if it were possible to register context config file 
extensions other then *.xml - it would allow to use *.exml for encrypted XML 
config files (will save us a test of the file to se if it is encrypted or plain 
text)
If it is not possible to make this enhancement may be you could re-factor 
ContextConfig class so it can be effectively subclassed and its input stream 
logic altered
All you would need to do is to factor out
protected void processContextConfig(InputStream) {

} 

from
protected void processContextConfig(File file) {

if (log.isDebugEnabled())
log.debug(Processing context [ + context.getName() + ] configuration file  + file);

// Add as watched resource so that cascade reload occurs if a default
// config file is modified/added/removed
context.addWatchedResource(file.getAbsolutePath());

InputSource source = null;
InputStream stream = null;
try {
if (file.exists()) {
stream = new FileInputStream(file);
source =
new InputSource(file:// + file.getAbsolutePath());
} else if (log.isDebugEnabled()) {
log.debug(Context [ + context.getName() + ] configuration file  + 
file +  not found);
}
} catch (Exception e) {
log.error(sm.getString(contextConfig.defaultMissing) + file);
}
if (source == null)
return;
if (contextDigester == null){
contextDigester = createContextDigester();
}
synchronized (contextDigester) {
try {
source.setByteStream(stream);
.
If processContextConfig(InputStream) is available, we can override this method, 
read from encrypted stream, decrypt create decrypted stream in memory and pass 
it to the original (superclass)  processContextConfig(InputStream)
Thank you very much for your assistance
Alex Roytman
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL 

RE: Pluggable mechanism for loading context config files

2005-01-06 Thread Durfee, Bernard
Mark,
 I disagree, I have always felt it would be a good idea to have the
database passwords and such encrypted when in the context files. Those
context files fly all around stuffed in WAR files and stored in CVS
repositories and 'Hey Bob, does this context file look right?'. That's
an awful lot of chances for someone to 'see' a plain-text password,
whether by malicious activity or a simple 'over the shoulder' accidental
glance.

 If the password was encrypted using a method where the encrypted string
can only be decrypted by Tomcat using a key stored safely on the Tomcat
server. A key which can sit on the server and does not ever need to
leave the server. The key can be used to encrypt passwords, which can
then be put in the context files. Now the risk of someone 'seeing' the
password in the context file is not as damaging, because the encrypted
password won't be useful. In fact this could be used to encrypt the
password, username, SID, etc. so that these details would be obscured as
the context files go from the developer's workstation to home to their
laptop to the test environment, etc.

This is at best a strategy of obfuscation, but I think it is a worthy
feature.

Bernard Durfee

-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 06, 2005 5:25 PM
To: Tomcat Developers List
Subject: Re: Pluggable mechanism for loading context config files


Alex,

I would vote '-1' for any such addition Tomcat.

Let me explain why by way of a simple example. Let us assume that Tomcat
requires a plain text user name and password to connect to a database. 
First of all, consider the security risks if the information is stored 
in an unencrypted file somewhere on the server. Assuming that this file 
is not publicaly available, only users with access to the machine can 
access the file. With a little more configuration and possibly some 
network security only users with physical access to the machine can 
access the file and read the password.

If one or more 'untrusted' users has physical access to the machine it 
is pretty much game over from a security point of view. With physical 
access there are a whole host of potential attacks I can think of that 
would enable an attacker to gain access to the file.

Therefore, all we are trying to do is protect the contents of a file 
from a group of users all of whom are authorised to see it. What is the 
point?

Looking at it from another perspective, lets say we do encrypt the file.

How does Tomcat decrypt it? Tomcat needs access to the decryption key. 
If this is in a file, the file needs to be protected. How do you do 
this? This is the same problem we had before. We have just added another

layer. It is a chicken and egg situation with no solution. The same 
applies to providing the password via some 'service'. How does the 
Tomcat process authenticate to this service to retrieve the password? It

needs some credentials. Where are these stored? In a file... and so we 
start all over again...

One thing that could work is not placing the password in a file at all 
but requiring it to be entered at start up. However, this exchanges a 
confidentiality security problem for an availability one - if the system

fails it can only be restarted when there is someone present who knows 
the password. Also, people being people, there is a strong chance this 
password will get written down and your security has just got worse 
rather than better.

Ultimately, the best thing you can do is leave the password unencrypted 
in a file and make sure the machine is electronically and physically 
secured with the right policies and procedures to ensure that it remains

secure.

Regards,

Mark

Roytman, Alex wrote:
 Dear Tomcat developers,
 
 I would like to implement context config file encryption. It is a 
 pretty useful feature since passwords to various resources are stored 
 in those files Unfortunately the way how context config files are read

 is hard coded (InputSource for Digester is created from 
 FileInputStream) and does not let me do so.
 
 It would be great if tomcat 5.5 provided some pluggable 
 ConfigFileLoader in HostConfig (and may be on Engine level as well) to

 return InputStream for a given config file name (or decorator for 
 FileInputStream ). It would be also great if it were possible to 
 register context config file extensions other then *.xml - it would 
 allow to use *.exml for encrypted XML config files (will save us a 
 test of the file to se if it is encrypted or plain text)
 
 If it is not possible to make this enhancement may be you could 
 re-factor ContextConfig class so it can be effectively subclassed and 
 its input stream logic altered
 
 All you would need to do is to factor out
 
 protected void processContextConfig(InputStream) {
 
 }
 
 
 from
 
 protected void processContextConfig(File file) {
 
 if (log.isDebugEnabled())
 log.debug(Processing context [ + 

RE: Pluggable mechanism for loading context config files

2005-01-06 Thread Roytman, Alex
Mark, Bernard,

I think you make a good point here. I would like to clarify my purpose.
I do not need to hide my passwords from people who maintain the servers - in 
fact they enter passwords into plain text config files which are encrypted on 
tomcat startup and stay encrypted. I need to make sure that if the server is 
compromised no password info should be gathered from its config files

I would like to add that there could be two levels of security

1. Naïve - key is stored on tomcat server and therefore context file can be 
decrypted by the hacker. While it is naïve and can be broken (if hacker finds 
key in one of java classes) it is zero maintenance and can be used by people 
who accept this level of security

2. Better one - key is stored on removable media (USB disk, Smart Card ) 
which is required to be present for tomcat to start

From management prospective it is a royal pain to encrypt each password so I 
prefer to encrypt entire file. I have this setup working but there is one weak 
link - I can not integrate well with tomcat. I am forced to have Host listener 
which decrypt all files on start, let contexts start and then delete decrypted 
copies. Not good - there is window of vulnerability, there is small chance 
encrypted file will get stuck on tomcat crash (although it will be cleaned up 
on next restart) plus deleted files can be recovered :-( 

Anyway I am looking for second line of defense here not an absolute solution. 
If I could only integrate with tomcat tightly I would be happy :-)

PS: I am not asking tomcat developers to develop encryption - just open up file 
loading process. This pluggable config file loading can be useful for other 
things besides encryption (eg custom XML entity resolver which able to read 
some bits of XML from shared repositories (e.g. LDAP)for big installs with many 
similar configurations) 

Thanks again

Alex


Date: Thu, 06 Jan 2005 17:46:00 -0500
From: Durfee, Bernard [EMAIL PROTECTED]
Subject: Pluggable mechanism for loading context config files
Content-type: text/plain; charset=us-ascii

Mark,
 I disagree, I have always felt it would be a good idea to have the
database passwords and such encrypted when in the context files. Those
context files fly all around stuffed in WAR files and stored in CVS
repositories and 'Hey Bob, does this context file look right?'. That's
an awful lot of chances for someone to 'see' a plain-text password,
whether by malicious activity or a simple 'over the shoulder' accidental
glance.

 If the password was encrypted using a method where the encrypted string
can only be decrypted by Tomcat using a key stored safely on the Tomcat
server. A key which can sit on the server and does not ever need to
leave the server. The key can be used to encrypt passwords, which can
then be put in the context files. Now the risk of someone 'seeing' the
password in the context file is not as damaging, because the encrypted
password won't be useful. In fact this could be used to encrypt the
password, username, SID, etc. so that these details would be obscured as
the context files go from the developer's workstation to home to their
laptop to the test environment, etc.

This is at best a strategy of obfuscation, but I think it is a worthy
feature.

Bernard Durfee

-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 06, 2005 5:25 PM
To: Tomcat Developers List
Subject: Re: Pluggable mechanism for loading context config files


Alex,

I would vote '-1' for any such addition Tomcat.

Let me explain why by way of a simple example. Let us assume that Tomcat
requires a plain text user name and password to connect to a database. 
First of all, consider the security risks if the information is stored 
in an unencrypted file somewhere on the server. Assuming that this file 
is not publicaly available, only users with access to the machine can 
access the file. With a little more configuration and possibly some 
network security only users with physical access to the machine can 
access the file and read the password.

If one or more 'untrusted' users has physical access to the machine it 
is pretty much game over from a security point of view. With physical 
access there are a whole host of potential attacks I can think of that 
would enable an attacker to gain access to the file.

Therefore, all we are trying to do is protect the contents of a file 
from a group of users all of whom are authorised to see it. What is the 
point?

Looking at it from another perspective, lets say we do encrypt the file.

How does Tomcat decrypt it? Tomcat needs access to the decryption key. 
If this is in a file, the file needs to be protected. How do you do 
this? This is the same problem we had before. We have just added another

layer. It is a chicken and egg situation with no solution. The same 
applies to providing the password via some 'service'. How does the 
Tomcat process authenticate to this service to retrieve the 

Safely accessing Web Context info from JNDI factories

2005-01-06 Thread Roytman, Alex
Dear Tomcat developers,

I have a need to access web context info (such as name, physical path)
from my various JNDI object factories. I was going through Tomcat 5.5
code and found that you publish repository info under comp:env/Resources
and it has all required information. Could you please tell me if it is a
right way to access web context info from classes which know nothing
about web context (such as JNDI object factories) or should I use some
other method.

With tomcat 4 I could not find any way to do it so I had to use a
context listener to build context info and publish it as context
Environment entry to be looked up by whoever is interested. I hope there
is a better way of doing it with tomcat 5.5 Please advice


Thank you very much for your assistance

Alex Roytman

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Pluggable mechanism for loading context config files

2005-01-06 Thread Remy Maucherat
Roytman, Alex wrote:
Dear Tomcat developers,
I would like to implement context config file encryption. It is a pretty useful feature since passwords to various resources are stored in those files
Unfortunately the way how context config files are read is hard coded (InputSource for Digester is created from FileInputStream) and does not let me do so. 

It would be great if tomcat 5.5 provided some pluggable ConfigFileLoader in 
HostConfig (and may be on Engine level as well) to return InputStream for a 
given config file name (or decorator for FileInputStream ).
It would be also great if it were possible to register context config file 
extensions other then *.xml - it would allow to use *.exml for encrypted XML 
config files (will save us a test of the file to se if it is encrypted or plain 
text)
If it is not possible to make this enhancement may be you could re-factor 
ContextConfig class so it can be effectively subclassed and its input stream 
logic altered
All you would need to do is to factor out
protected void processContextConfig(InputStream) {

} 

from
protected void processContextConfig(File file) {

if (log.isDebugEnabled())
log.debug(Processing context [ + context.getName() + ] configuration file  + file);

// Add as watched resource so that cascade reload occurs if a default
// config file is modified/added/removed
context.addWatchedResource(file.getAbsolutePath());

InputSource source = null;
InputStream stream = null;
try {
if (file.exists()) {
stream = new FileInputStream(file);
source =
new InputSource(file:// + file.getAbsolutePath());
} else if (log.isDebugEnabled()) {
log.debug(Context [ + context.getName() + ] configuration file  + 
file +  not found);
}
} catch (Exception e) {
log.error(sm.getString(contextConfig.defaultMissing) + file);
}
if (source == null)
return;
if (contextDigester == null){
contextDigester = createContextDigester();
}
synchronized (contextDigester) {
try {
source.setByteStream(stream);
.
If processContextConfig(InputStream) is available, we can override this method, read from encrypted stream, decrypt create decrypted stream in memory and pass it to the original (superclass)  processContextConfig(InputStream)
You should be able to easily plug your own Host or Context listener for 
configuration.

Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Pluggable mechanism for loading context config files

2005-01-06 Thread Mark Thomas
Alex,
Thanks for the clarification of the requirement. I think I still need
some convincing ;).
I view the naive level as, at best, security by obscurity. Whilst it
might make people feel secure, it doesn't add much, if anything in terms
of real security.
On first impression the second option is more promising but if the
machine is compromised a hacker doesn't need the password, they just
need to supply a modified class/jar that exposes the password somehow
and then sit back and wait for the machine to reboot. You could prevent
this by digitally signing all of the 'approved' Java and using a security
manager but then you have to protect the security policy file from
compromise and you are back to square one. :)
So the second option is really no more than a more complex security by
obscurity.
Stepping back from this a bit, have you done a full security audit of the
system? Is this really the highest security risk you need to mitigate?
It is possible that this is the case but I would be surprised.
Bernard makes an interesting point about keeping production settings 
separate from the development environment but my own view is that 
procedure rather than technology is the way to handle this.

Mark
Roytman, Alex wrote:
Mark, Bernard,
I think you make a good point here. I would like to clarify my purpose.
I do not need to hide my passwords from people who maintain the servers - in 
fact they enter passwords into plain text config files which are encrypted on 
tomcat startup and stay encrypted. I need to make sure that if the server is 
compromised no password info should be gathered from its config files
I would like to add that there could be two levels of security
1. Naïve - key is stored on tomcat server and therefore context file can be 
decrypted by the hacker. While it is naïve and can be broken (if hacker finds 
key in one of java classes) it is zero maintenance and can be used by people 
who accept this level of security
2. Better one - key is stored on removable media (USB disk, Smart Card ) 
which is required to be present for tomcat to start
From management prospective it is a royal pain to encrypt each password so I prefer to encrypt entire file. I have this setup working but there is one weak link - I can not integrate well with tomcat. I am forced to have Host listener which decrypt all files on start, let contexts start and then delete decrypted copies. Not good - there is window of vulnerability, there is small chance encrypted file will get stuck on tomcat crash (although it will be cleaned up on next restart) plus deleted files can be recovered :-( 
Anyway I am looking for second line of defense here not an absolute 
solution. If I could only integrate with tomcat tightly I would be happy :-)
PS: I am not asking tomcat developers to develop encryption - just open up file loading process. This pluggable config file loading can be useful for other things besides encryption (eg custom XML entity resolver which able to read some bits of XML from shared repositories (e.g. LDAP)for big installs with many similar configurations) 

Thanks again
Alex
Date: Thu, 06 Jan 2005 17:46:00 -0500
From: Durfee, Bernard [EMAIL PROTECTED]
Subject: Pluggable mechanism for loading context config files
Content-type: text/plain; charset=us-ascii
Mark,
 I disagree, I have always felt it would be a good idea to have the
database passwords and such encrypted when in the context files. Those
context files fly all around stuffed in WAR files and stored in CVS
repositories and 'Hey Bob, does this context file look right?'. That's
an awful lot of chances for someone to 'see' a plain-text password,
whether by malicious activity or a simple 'over the shoulder' accidental
glance.
 If the password was encrypted using a method where the encrypted string
can only be decrypted by Tomcat using a key stored safely on the Tomcat
server. A key which can sit on the server and does not ever need to
leave the server. The key can be used to encrypt passwords, which can
then be put in the context files. Now the risk of someone 'seeing' the
password in the context file is not as damaging, because the encrypted
password won't be useful. In fact this could be used to encrypt the
password, username, SID, etc. so that these details would be obscured as
the context files go from the developer's workstation to home to their
laptop to the test environment, etc.
This is at best a strategy of obfuscation, but I think it is a worthy
feature.
Bernard Durfee
-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 06, 2005 5:25 PM
To: Tomcat Developers List
Subject: Re: Pluggable mechanism for loading context config files

Alex,
I would vote '-1' for any such addition Tomcat.
Let me explain why by way of a simple example. Let us assume that Tomcat
requires a plain text user name and password to connect to a database. 
First of all, consider the security risks if the information is stored 
in an unencrypted 

RE: Pluggable mechanism for loading context config files

2005-01-06 Thread Roytman, Alex

Rémy,

I do not think that adding a Context listener will do me any good. I need to 
plug in my own ContextConfig. I know I can plug in my own ContextConfig but I 
would like to extend tomcat's one with minimum of changes or I will be running 
risk of being incompatible with next version of tomcat. That's why I am asking 
if existing ContextConfig could be refactored slightly to permit easy extension 

Thank you for your help

Alex





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]