[Bug 51966] Tomcat does not support ssha hashed passwords in all contexts

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51966

--- Comment #20 from Gabriel  ---
(In reply to Gabriel from comment #19)
> 
> Hashing on the client side has its merits as long as you also hash on the
> server side and you don't use the same salt on the client as you do on the
> server.  In particular, if your client code fetches the salt corresponding
> to a username, that lets an attacker know if they have a valid username (if
> they receive a salt from the server to do hashing on the client side).  If
> you use a random salt generated for a client session or even a constant
> client-side salt, it is best to also hash on the server side with an
> independent user-specific hash.  
> 
Oops... random salt generated for a client session wouldn't work, would it?  It
would either have to be constant or user specific.  I suppose constant is best
on the client side.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 51966] Tomcat does not support ssha hashed passwords in all contexts

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51966

--- Comment #19 from Gabriel  ---
(In reply to S from comment #17)
> (In reply to Christopher Schultz from comment #16)
> > This is awful security. When the client is involved in authentication,
> > that's called not being authenticated.
> I don't understand. It's the same Tomcat does out-of-the-box (send data to
> j_security_check and wait for the result), but with more hashing.
> 
> > In production, we salt-hash 75000 times by default, and should probably do
> > more. 10k times isn't nearly enough.
> I'll test how long a client takes for 100K and if its acceptable (which I
> assume) I'll change.
> 
> > > This way there is never send a unhashed password (even not when you are 
> > > not
> > > using https, which you shouldn't) 
> > Shouldn't use HTTPS, or shouldn't send otherwise-unencrypted passwords over
> > HTTPS? Both of those sound like bad advice.
> I meant: You should use https. I can't see the problem generated by sending
> a (salted, many-round) hash (with the exception of rainbow table attacks).

Hashing on the client side has its merits as long as you also hash on the
server side and you don't use the same salt on the client as you do on the
server.  In particular, if your client code fetches the salt corresponding to a
username, that lets an attacker know if they have a valid username (if they
receive a salt from the server to do hashing on the client side).  If you use a
random salt generated for a client session or even a constant client-side salt,
it is best to also hash on the server side with an independent user-specific
hash.  

If you hash on the client side but not the server side, and an attacker steals
the password table, they essentially have all the passwords they need to get
into your site.  They don't need to know the cleartext passwords... they can
modify the javascript on the client side to send the stolen hash (and not hash
again) and the server will let them in.  This is why strong hashing on the
server side is necessary.

> 
> > Nobody should be using SHA-1 anymore for authentication.
> > Realistically, nobody should be using crypto hashing for password hashing,
> > anyway.
> The second Tomcat supports SCrypt or BCrypt I'll change. What's your
> suggestion for the time being?
> Besides changing Tomcat yourself like in
> http://stackoverflow.com/questions/12285604/writing-a-custom-tomcat-realm-
> using-bcrypt, which I really don't want to do.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 51966] Tomcat does not support ssha hashed passwords in all contexts

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51966

--- Comment #18 from Gabriel  ---
The only advantage I see of hashing in the client side is not storing a String
with the cleartext password in memory.  Strings are immutable objects, so they
cannot be cleared once password processing is completed.  If no references
point to it, then the garbage collector should eventually do the job.  I've
seen that careful password authentication implementations use a char array for
this reason.  Char arrays are mutable, so as soon as password processing is
complete, all of the array elements are zeroed out, reducing the time an
attacker might have to read the password off memory.  Tomcat's password
authentication methods should follow this best practice and be changed to do
the handling with char[].  

A risk of receiving the cleartext password is that someone with access to the
server may write code to store passwords, and if users use the same password
for other web accounts, then bad things can happen.  Hashing might make it just
a bit less easy for an insider to do that.  They can still do brute force and
dictionary attacks, of course.  So it doesn't go a long way at all.  

Hashing on the server is necessary to protect passwords in the event a
malicious person obtains access to the password table, even if hashing was done
on the client side.  Client side hashing by itself would make no difference
here.

And of course, no kind of hashing protects from weak passwords or stolen
passwords from the clients via key loggers and whatnot.  

Should we change the meta data of this thread to reflect the direction the
discussion has taken?  Is this still a Tomcat 6 issue, or should we say it is a
proposed new feature for Tomcat 8 revisions?  Or do you think that all versions
of Tomcat should be updated?

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 51966] Tomcat does not support ssha hashed passwords in all contexts

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51966

--- Comment #17 from S  ---
(In reply to Christopher Schultz from comment #16)
> This is awful security. When the client is involved in authentication,
> that's called not being authenticated.
I don't understand. It's the same Tomcat does out-of-the-box (send data to
j_security_check and wait for the result), but with more hashing.

> In production, we salt-hash 75000 times by default, and should probably do
> more. 10k times isn't nearly enough.
I'll test how long a client takes for 100K and if its acceptable (which I
assume) I'll change.

> > This way there is never send a unhashed password (even not when you are not
> > using https, which you shouldn't) 
> Shouldn't use HTTPS, or shouldn't send otherwise-unencrypted passwords over
> HTTPS? Both of those sound like bad advice.
I meant: You should use https. I can't see the problem generated by sending a
(salted, many-round) hash (with the exception of rainbow table attacks).

> Nobody should be using SHA-1 anymore for authentication.
> Realistically, nobody should be using crypto hashing for password hashing,
> anyway.
The second Tomcat supports SCrypt or BCrypt I'll change. What's your suggestion
for the time being?
Besides changing Tomcat yourself like in
http://stackoverflow.com/questions/12285604/writing-a-custom-tomcat-realm-using-bcrypt,
which I really don't want to do.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 51966] Tomcat does not support ssha hashed passwords in all contexts

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51966

--- Comment #16 from Christopher Schultz  ---
(In reply to S from comment #15)
> Hi,
> 
> what I'm doing is to hash the user-entered password 999x on the client with
> a salt (visible in the JS code) on the OK-Click in my login form. Then I
> send it to Tomcat and have it compared to the stored hash (1000x hashed with
> the same salt).

This is awful security. When the client is involved in authentication, that's
called not being authenticated.

In production, we salt-hash 75000 times by default, and should probably do
more. 10k times isn't nearly enough.

> This way there is never send a unhashed password (even not when you are not
> using https, which you shouldn't) and you can configure the number of
> pre-hashing to your needs (to be safe against generating rainbow tables for
> your salt). This might be useful in times of modern GPUs executing billions
> of SHA1-hashes per second (2300M/s SHA1 hashes in 2009).

Shouldn't use HTTPS, or shouldn't send otherwise-unencrypted passwords over
HTTPS? Both of those sound like bad advice.

Nobody should be using SHA-1 anymore for authentication.

Realistically, nobody should be using crypto hashing for password hashing,
anyway.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: support for salted passwords

[Christopher Schultz]

Gabriel,

On 2/4/14, 3:29 PM, "Gabriel E. Sánchez Martínez" wrote:
> 
> On 02/04/2014 12:20 PM, Christopher Schultz wrote:
>> Nick,
>>
>> On 2/2/14, 2:51 AM, Nick Williams wrote:
>>> On Feb 2, 2014, at 1:23 AM, Gabriel E. Sánchez Martínez wrote:
 I am very new to Tomcat but am already getting my feet wet with a
 web application.  A requirement for this application is form-based
 password authentication, and I would like to store passwords in a
 database using salted SHA-512 digests
>>> I can't speak to most of this email, but don't do this. SHA-x is a
>>> *fast* hashing algorithm. It's not designed for passwords. The
>>> problem with fast hashing algorithms is that they are *very*
>>> susceptible to rainbow table attacks. Modern password-hacking systems
>>> with 24 GPUs can calculate billions of MD5 and SHA-x hash attacks per
>>> second.
>>>
>>> I strongly recommend you use a *slow* hashing algorithm such as
>>> bcrypt, which is designed specifically for hashing passwords. These
>>> algorithms use more than just CPU/GPU operations (such as memory).
>>> Password hacking systems can only calculate thousands of these per
>>> second instead of millions. It's much better protection in case your
>>> password database is ever stolen.
>> While you are completely correct in your assessment (crypto hashes don't
>> make good password hashes), the fact that Tomcat supports only the
>> former is a somewhat tacit affirmation that simply using crypto hashing
>> for passwords is good security.
>>
>> I've been tossing-around some upgrades in my mind for the realm
>> implementations that would allow for better pluggability for things like
>> this. Right now, the only way to implement, say, bcrypt, would be to
>> write your own Realm. That's silly: all you need to do is implement two
>> methods: mutatePassword() and verifyMutatedPassword().
>>
>> That opens the door for all kinds of things like bcrypt/scrypt/etc. with
>> a trivial pluggable interface.
>>
>> Since it sounds like there's a bit of appetite for this, I may spend
>> some more time on this (that is, some at all).
>>
>> -chris
>>
> 
> Bravo!  I agree on a need for more pluggability.  And I believe that out
> of the box it should offer stronger protection.  Ideally hashes designed
> for password storage, but if not at least it should support salting.

Well, out of the box would require two things: salting and iterating.
Password-hashing algorithms are better than just adding salt and
stirring SHD-512 or whatever.

I'd love to be able to directly-support things like bcrypt and scrypt,
but I'm not sure about their licensing and adding an external dependency
isn't a great idea. I think the best we can hope for would be to add
support at the code level for pluggable interfaces, and then put some
samples on the Wiki for how to write a wrapper around something specific
like bcrypt.

-chris



signature.asc
Description: OpenPGP digital signature

Re: Improvement fo org.apache.tomcat.util.net.jsse.JSSESupport class

[sebb]

On 5 February 2014 15:14, Mark Thomas  wrote:
> On 05/02/2014 14:56, Maxim Kirilov wrote:
>> Hi,
>>
>> I've noticed that some code inside *handshake()* method can be omitted.
>> After executing the
>> call to: *ssl.startHandshake()*, according to SSLSocket
>> javadoc,
>> after returning from this call the negotiated handshake is complete. So the
>> following code that tries to read bytes from the socket
>> is useless since errors during handshake process would be thrown earlier.
>>
>> Am I missing something?
>
> Look at the history of that file in svn to see why the code is there.
> Once you know why that code was written, you can make an informed
> decision as to whether or not it should still be there.

If the svn log is necessary to understand the code, it seems to me
that the code needs to be commented with the relevant information.

After all, the ASF releases source, and that does not include the svn history.

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

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

buildbot success in ASF Buildbot on tomcat-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-trunk while 
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/tomcat-trunk/builds/5477

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-vm_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch tomcat/trunk] 1564746
Blamelist: kkolinko

Build succeeded!

sincerely,
 -The Buildbot

Re: svn commit: r1564668 - /tomcat/jk/trunk/native/common/jk_connect.c

[Ognjen Blagojevic]

On 5.2.2014 16:51, Mladen Turk wrote:

On 02/05/2014 03:12 PM, Ognjen Blagojevic wrote:

Mladen,

On 5.2.2014 14:34, Mladen Turk wrote:

On 02/05/2014 12:42 PM, Rainer Jung wrote:

I think as soon as you are confident, that you IP6 changes are
stable we
should make the overdue release.



Yep, that's the plan. Definitively this month.


Any chance to include patch for EECDH support [1]?



This about mod_jk not tomcat native.


Sorry, my mistake.

-Ognjen


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

Re: svn commit: r1564668 - /tomcat/jk/trunk/native/common/jk_connect.c

[Mladen Turk]

On 02/05/2014 03:12 PM, Ognjen Blagojevic wrote:

Mladen,

On 5.2.2014 14:34, Mladen Turk wrote:

On 02/05/2014 12:42 PM, Rainer Jung wrote:

I think as soon as you are confident, that you IP6 changes are stable we
should make the overdue release.



Yep, that's the plan. Definitively this month.


Any chance to include patch for EECDH support [1]?



This about mod_jk not tomcat native.


Regards
--
^TM

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

[Bug 50685] Big memory leak

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=50685

--- Comment #6 from Konstantin Kolinko  ---
1. This page has links:
http://tomcat.apache.org/bugreport.html#Bugzilla_is_not_a_support_forum

2. I added a comment on the original issue to the FAQ page here:
http://wiki.apache.org/tomcat/OutOfMemory

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: Improvement fo org.apache.tomcat.util.net.jsse.JSSESupport class

[Mark Thomas]

On 05/02/2014 14:56, Maxim Kirilov wrote:
> Hi,
> 
> I've noticed that some code inside *handshake()* method can be omitted.
> After executing the
> call to: *ssl.startHandshake()*, according to SSLSocket
> javadoc,
> after returning from this call the negotiated handshake is complete. So the
> following code that tries to read bytes from the socket
> is useless since errors during handshake process would be thrown earlier.
> 
> Am I missing something?

Look at the history of that file in svn to see why the code is there.
Once you know why that code was written, you can make an informed
decision as to whether or not it should still be there.

Mark


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

[Bug 50685] Big memory leak

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=50685

--- Comment #5 from Daniel Baktiar  ---
@Z, you should send email to users-subscr...@tomcat.apache.org to subscribe.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Improvement fo org.apache.tomcat.util.net.jsse.JSSESupport class

[Maxim Kirilov]

Hi,

I've noticed that some code inside *handshake()* method can be omitted.
After executing the
call to: *ssl.startHandshake()*, according to SSLSocket
javadoc,
after returning from this call the negotiated handshake is complete. So the
following code that tries to read bytes from the socket
is useless since errors during handshake process would be thrown earlier.

Am I missing something?

BR,
Maxim Kirilov.

[Tomcat Wiki] Update of "OutOfMemory" by KonstantinKolinko

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The "OutOfMemory" page has been changed by KonstantinKolinko:
https://wiki.apache.org/tomcat/OutOfMemory?action=diff&rev1=12&rev2=13

Comment:
Add section on HTTP sessions

   1. Trace the GC roots of this object to find out what is holding on to a 
reference to that object that shouldn't be. That will be the source of the leak.
  
  
+ 
+ = HTTP sessions =
+ 
+ (In response to 
[[https://issues.apache.org/bugzilla/show_bug.cgi?id=50685|[1]]], 
[[http://marc.info/?t=13913627931&r=1&w=2|[2]]])
+ 
+ Please remember that a JSP page, even one that simply prints out “OK”, will 
create a session.  This is by design and if you do not want it to create a 
session you need to explicitly indicate that in your JSP. For example:
+ 
+ {{{
+   <%@ page session="false" %>
+ }}}
+ 
+ This is important in scenarios where you are doing load testing and using 
custom HTTP clients, because these clients may not be handling sessions 
correctly and thus end up creating a new session every time they access the 
page.
+ 
+ One known category of misbehaving clients are web bots. To deal with them you 
can configure a 
[[http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Crawler_Session_Manager_Valve|CrawlerSessionManagerValve]].
+ 
+ It is also possible to limit the number of active sessions by setting 
'''maxActiveSessions''' attribute on a 
[[http://tomcat.apache.org/tomcat-8.0-doc/config/manager.html|Manager]] 
element, e.g.
+ 
+ {{{
+ 
+ 
+ 
+ }}}
+ 
+ 
+ 
  [[CategoryFAQ]]
  

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

buildbot failure in ASF Buildbot on tomcat-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-trunk while building 
ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/tomcat-trunk/builds/5476

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-vm_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch tomcat/trunk] 1564742
Blamelist: kkolinko

BUILD FAILED: failed compile_1

sincerely,
 -The Buildbot

Re: svn commit: r1564668 - /tomcat/jk/trunk/native/common/jk_connect.c

[Ognjen Blagojevic]

Mladen,

On 5.2.2014 14:34, Mladen Turk wrote:

On 02/05/2014 12:42 PM, Rainer Jung wrote:

I think as soon as you are confident, that you IP6 changes are stable we
should make the overdue release.



Yep, that's the plan. Definitively this month.


Any chance to include patch for EECDH support [1]?

-Ognjen

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=55915


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

[Tomcat Wiki] Trivial Update of "OutOfMemory" by KonstantinKolinko

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The "OutOfMemory" page has been changed by KonstantinKolinko:
https://wiki.apache.org/tomcat/OutOfMemory?action=diff&rev1=11&rev2=12

Comment:
Add TOC, remove dead link

  #format wiki
  #language en
+ 
+ <>
  
  = How to Deal With Out Of Memory Errors =
  
@@ -18, +20 @@

  An Out Of Memory can be thrown by several causes:
  
   * A servlet trying to load a several GBytes file into memory will surely 
kill the server. These kind of errors must be considered a simple bug in our 
program.
-  * To compensate for the data your servlet tries to load, you increase the 
heap size so that there is no room to create the stack size for the threads 
that need to be created.  The memory required by each thread will vary by OS 
but can be as high as 2M by default and in some OS's (like Debian Sarge) is not 
reducible with the -Xss parameter. 
[[http://goobsoft.homeip.net/Wiki.jsp?page=JavaDebianTuning|1]]  Rule of Thumb, 
use no more than 1G for heap space in a 32-bit web application.
+  * To compensate for the data your servlet tries to load, you increase the 
heap size so that there is no room to create the stack size for the threads 
that need to be created.  The memory required by each thread will vary by OS 
but can be as high as 2M by default and in some OS's (like Debian Sarge) is not 
reducible with the -Xss parameter. Rule of Thumb, use no more than 1G for heap 
space in a 32-bit web application.
   * Deep recursive algorithms can also lead to Out Of Memory problems. In this 
case, the only fixes are increasing the thread stack size ({{{-Xss}}}), or 
refactoring the algorithms to reduce the depth, or the local data size per call.
   * A webapp that uses lots of libraries with many dependencies, or a server 
maintaining lots of webapps could exhauste the JVM PermGen space. This space is 
where the VM stores the classes and methods data. In those cases, the fix is to 
increase this size. The Sun VM has the flag {{{-XX:MaxPermSize}}} that allows 
to set its size (the default value is 64M)
   * Hard references to classes can prevent the garbage collector from 
reclaiming the memory allocated for them when a ClassLoader is discarded. This 
will occur on JSP recompilations, and webapps reloads. If these operations are 
common in a webapp having these kinds of problems, it will be a matter of time, 
until the PermGen space gets full and an Out Of Memory is thrown.

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

Re: svn commit: r1564668 - /tomcat/jk/trunk/native/common/jk_connect.c

[Mladen Turk]

On 02/05/2014 12:42 PM, Rainer Jung wrote:

Hi Mladen,

I think as soon as you are confident, that you IP6 changes are stable we
should make the overdue release.



Yep, that's the plan. Definitively this month.

Regards
--
^TM

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

svn commit: r1564755 - in /tomcat/site/trunk: docs/bugreport.html xdocs/bugreport.xml

[kkolinko]

Author: kkolinko
Date: Wed Feb  5 12:58:05 2014
New Revision: 1564755

URL: http://svn.apache.org/r1564755
Log:
Add target anchor to a link to the users list

Modified:
tomcat/site/trunk/docs/bugreport.html
tomcat/site/trunk/xdocs/bugreport.xml

Modified: tomcat/site/trunk/docs/bugreport.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/bugreport.html?rev=1564755&r1=1564754&r2=1564755&view=diff
==
--- tomcat/site/trunk/docs/bugreport.html (original)
+++ tomcat/site/trunk/docs/bugreport.html Wed Feb  5 12:58:05 2014
@@ -299,7 +299,7 @@ resolve the problem you are having.
 Bugzilla is not a place to ask questions on how to configure your
 own system, or how to interpret some error message or behaviour that you
 do not understand. If you have questions, please ask on the users
-mailing list.
+mailing list.
   
 
   

Modified: tomcat/site/trunk/xdocs/bugreport.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/bugreport.xml?rev=1564755&r1=1564754&r2=1564755&view=diff
==
--- tomcat/site/trunk/xdocs/bugreport.xml (original)
+++ tomcat/site/trunk/xdocs/bugreport.xml Wed Feb  5 12:58:05 2014
@@ -44,7 +44,7 @@ resolve the problem you are having.
   Bugzilla is not a place to ask questions on how to configure your
 own system, or how to interpret some error message or behaviour that you
 do not understand. If you have questions, please ask on the users
-mailing list.
+mailing list.
   
 
   When you have gathered enough information to diagnose your problem,



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

svn commit: r1564751 - in /tomcat/site/trunk: docs/bugreport.html xdocs/bugreport.xml

[kkolinko]

Author: kkolinko
Date: Wed Feb  5 12:53:13 2014
New Revision: 1564751

URL: http://svn.apache.org/r1564751
Log:
Add target anchor to a link to the users list

Modified:
tomcat/site/trunk/docs/bugreport.html
tomcat/site/trunk/xdocs/bugreport.xml

Modified: tomcat/site/trunk/docs/bugreport.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/bugreport.html?rev=1564751&r1=1564750&r2=1564751&view=diff
==
--- tomcat/site/trunk/docs/bugreport.html (original)
+++ tomcat/site/trunk/docs/bugreport.html Wed Feb  5 12:53:13 2014
@@ -276,7 +276,7 @@ operating system, etc.
 
   
 If you need help, ask on the users
-   mailing list.
+   mailing list.
 
 
 

Modified: tomcat/site/trunk/xdocs/bugreport.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/bugreport.xml?rev=1564751&r1=1564750&r2=1564751&view=diff
==
--- tomcat/site/trunk/xdocs/bugreport.xml (original)
+++ tomcat/site/trunk/xdocs/bugreport.xml Wed Feb  5 12:53:13 2014
@@ -28,7 +28,7 @@ operating system, etc.
   yourself.
 
   If you need help, ask on the users
-   mailing list.
+   mailing list.
 
 
 The remainder of this document points you toward resources you can use to



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

svn commit: r1564747 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/core/ java/org/apache/jasper/ java/org/apache/jasper/compiler/ test/org/apache/catalina/core/ webapps/docs/ webapps/docs/co

[kkolinko]

Author: kkolinko
Date: Wed Feb  5 12:43:49 2014
New Revision: 1564747

URL: http://svn.apache.org/r1564747
Log:
Merged revisions r1562597,r1564742-r1564746 from tomcat/trunk:
Make the xmlBlockExternal option in Catalina and Jasper to be true by default.

Modified:
tomcat/tc7.0.x/trunk/   (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspC.java

tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java
tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/JspConfig.java
tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/JspDocumentParser.java
tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/TagPluginManager.java
tomcat/tc7.0.x/trunk/java/org/apache/jasper/compiler/TldLocationsCache.java
tomcat/tc7.0.x/trunk/test/org/apache/catalina/core/TesterContext.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/context.xml
tomcat/tc7.0.x/trunk/webapps/docs/security-howto.xml

Propchange: tomcat/tc7.0.x/trunk/
--
  Merged /tomcat/trunk:r1562597,1564742-1564746

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java?rev=1564747&r1=1564746&r2=1564747&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java 
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java 
Wed Feb  5 12:43:49 2014
@@ -325,9 +325,7 @@ public class ApplicationContext
 return "true";
 }
 if (Globals.JASPER_XML_BLOCK_EXTERNAL_INIT_PARAM.equals(name)) {
-if (context.getXmlBlockExternal()) {
-return "true";
-} else if (Globals.IS_SECURITY_ENABLED) {
+if (!context.getXmlBlockExternal()) {
 // System admin has explicitly changed the default
 return "false";
 }
@@ -349,7 +347,7 @@ public class ApplicationContext
 if (context.getTldValidation()) {
 names.add(Globals.JASPER_XML_VALIDATION_TLD_INIT_PARAM);
 }
-if (context.getXmlBlockExternal() || Globals.IS_SECURITY_ENABLED) {
+if (!context.getXmlBlockExternal()) {
 names.add(Globals.JASPER_XML_BLOCK_EXTERNAL_INIT_PARAM);
 }
 return Collections.enumeration(names);

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java?rev=1564747&r1=1564746&r2=1564747&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java 
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java Wed 
Feb  5 12:43:49 2014
@@ -700,7 +700,7 @@ public class StandardContext extends Con
 /**
  * Attribute used to turn on/off the use of external entities.
  */
-private boolean xmlBlockExternal = Globals.IS_SECURITY_ENABLED;
+private boolean xmlBlockExternal = true;
 
 
 /**

Modified: tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspC.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspC.java?rev=1564747&r1=1564746&r2=1564747&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspC.java (original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspC.java Wed Feb  5 12:43:49 
2014
@@ -128,6 +128,7 @@ public class JspC extends Task implement
 protected static final String SWITCH_DUMP_SMAP = "-dumpsmap";
 protected static final String SWITCH_VALIDATE_TLD = "-validateTld";
 protected static final String SWITCH_BLOCK_EXTERNAL = "-blockExternal";
+protected static final String SWITCH_NO_BLOCK_EXTERNAL = 
"-no-blockExternal";
 protected static final String SHOW_SUCCESS ="-s";
 protected static final String LIST_ERRORS = "-l";
 protected static final int INC_WEBXML = 10;
@@ -159,7 +160,7 @@ public class JspC extends Task implement
 protected boolean trimSpaces = false;
 protected boolean genStringAsCharArray = false;
 protected boolean validateTld;
-protected boolean blockExternal;
+protected boolean blockExternal = true;
 protected boolean xpoweredBy;
 protected boolean mappedFile = false;
 protected boolean poolingEnabled = true;
@@ -371,6 +372,8 @@ public class JspC extends Task im

svn commit: r1564746 - in /tomcat/trunk: java/org/apache/catalina/core/ApplicationContext.java webapps/docs/changelog.xml

[kkolinko]

Author: kkolinko
Date: Wed Feb  5 12:34:28 2014
New Revision: 1564746

URL: http://svn.apache.org/r1564746
Log:
Followup to r1562597
xmlBlockExternal is now true by default. It is the false value that now needs 
to be passed explicitly.

Modified:
tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java?rev=1564746&r1=1564745&r2=1564746&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/ApplicationContext.java Wed Feb  
5 12:34:28 2014
@@ -309,9 +309,7 @@ public class ApplicationContext
 return "true";
 }
 if (Globals.JASPER_XML_BLOCK_EXTERNAL_INIT_PARAM.equals(name)) {
-if (context.getXmlBlockExternal()) {
-return "true";
-} else if (Globals.IS_SECURITY_ENABLED) {
+if (!context.getXmlBlockExternal()) {
 // System admin has explicitly changed the default
 return "false";
 }
@@ -333,7 +331,7 @@ public class ApplicationContext
 if (context.getTldValidation()) {
 names.add(Globals.JASPER_XML_VALIDATION_TLD_INIT_PARAM);
 }
-if (context.getXmlBlockExternal() || Globals.IS_SECURITY_ENABLED) {
+if (!context.getXmlBlockExternal()) {
 names.add(Globals.JASPER_XML_BLOCK_EXTERNAL_INIT_PARAM);
 }
 return Collections.enumeration(names);

Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1564746&r1=1564745&r2=1564746&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Wed Feb  5 12:34:28 2014
@@ -74,6 +74,10 @@
 deployment descriptor and with annotation then the one specified in the
 web deployment descriptor is with priority. (violetagg)
   
+  
+Fix passing the value of false for xmlBlockExternal option
+of Context to Jasper, as the default was changed in 8.0.1. (kkolinko)
+  
 
   
   



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

svn commit: r1564742 - /tomcat/trunk/test/org/apache/catalina/core/TesterContext.java

[kkolinko]

Author: kkolinko
Date: Wed Feb  5 12:23:52 2014
New Revision: 1564742

URL: http://svn.apache.org/r1564742
Log:
Followup to r1562597
Align return value in stub class with the default one in StandardContext

Modified:
tomcat/trunk/test/org/apache/catalina/core/TesterContext.java

Modified: tomcat/trunk/test/org/apache/catalina/core/TesterContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/TesterContext.java?rev=1564742&r1=1564741&r2=1564742&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/core/TesterContext.java (original)
+++ tomcat/trunk/test/org/apache/catalina/core/TesterContext.java Wed Feb  5 
12:23:52 2014
@@ -645,7 +645,7 @@ public class TesterContext implements Co
 
 @Override
 public boolean getXmlBlockExternal() {
-return false;
+return true;
 }
 
 @Override



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

Re: svn commit: r1564668 - /tomcat/jk/trunk/native/common/jk_connect.c

[Rainer Jung]

Hi Mladen,

On 05.02.2014 09:18, mt...@apache.org wrote:
> Author: mturk
> Date: Wed Feb  5 08:18:47 2014
> New Revision: 1564668
> 
> URL: http://svn.apache.org/r1564668
> Log:
> Ensure proper HAVE_IPV6 define is used

I think as soon as you are confident, that you IP6 changes are stable we
should make the overdue release.

Regards,

Rainer

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

Re: support for salted passwords

[Ognjen Blagojevic]

On 4.2.2014 21:29, "Gabriel E. Sánchez Martínez" wrote:

I've been tossing-around some upgrades in my mind for the realm
implementations that would allow for better pluggability for things like
this. Right now, the only way to implement, say, bcrypt, would be to
write your own Realm. That's silly: all you need to do is implement two
methods: mutatePassword() and verifyMutatedPassword().

That opens the door for all kinds of things like bcrypt/scrypt/etc. with
a trivial pluggable interface.

...

-chris


...

Bravo!  I agree on a need for more pluggability.  And I believe that out
of the box it should offer stronger protection.  Ideally hashes designed
for password storage, but if not at least it should support salting.


IMO, it would be great if Tomcat could support:

1. plain text passwords
2. hashed passwords using crypto hash functions
3. option 2 with salt
4. password-based key derivation functions (e.g. bcrypt, scrypt, pbkdf2)

I also think that if the user selects anything other then option 4, 
Tomcat should log a gentle warning during startup with suggestion that 
there is a more secure solution for storing passwords.


Tomcat already suggests that APR is superior connector, why wouldn't it 
also suggest what is the best practice for other things like passwords?


For option number 4, in order to avoid adding new dependecies to Tomcat, 
it would be just fine to add step-by-step guide how to enable particular 
KDF.


At the moment options 1 and 2 are supported. There is already some work 
done to support options 3 and 4 on this thread, as well as on issues:


  https://issues.apache.org/bugzilla/show_bug.cgi?id=53785
  https://issues.apache.org/bugzilla/show_bug.cgi?id=51966

I am also willing to contribute some effort to implement those options.

-Ognjen

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

[Bug 50685] Big memory leak

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=50685

--- Comment #4 from Z@  ---
(In reply to Mark Thomas from comment #3)
> The bug was resolved as invalid because there is no bug here. If you do not
> understand why this bug is invalid, please ask on the users mailing list.
Hello,
How can I ask on the users mailing list? If I send email to
dev@tomcat.apache.org system answer me that email cannot be delivered. I send
it from email, which I used for registration on the issues.apache.org. I could
not found on this website, how to subscribe on the users mailing list.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Time for 7.0.51

[Violeta Georgieva]

Hi,

I want to start the release procedure for Tomcat 7.0.51.
If you would like to add something to this release please respond to this
mail.

Regards
Violeta

[Bug 50685] Big memory leak

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=50685

--- Comment #3 from Mark Thomas  ---
The bug was resolved as invalid because there is no bug here. If you do not
understand why this bug is invalid, please ask on the users mailing list.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 50685] Big memory leak

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=50685

Z@  changed:

   What|Removed |Added

 CC||zlelik2...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 50685] Big memory leak

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=50685

--- Comment #2 from Z@  ---
(In reply to Mark Thomas from comment #1)
> Please use the users mailing list if you require further advice.

Hello,
Could you please explain why this bug is resolved or maybe it was moved to
another place? If so, please give me a link to correct one.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

svn commit: r1564668 - /tomcat/jk/trunk/native/common/jk_connect.c

[mturk]

Author: mturk
Date: Wed Feb  5 08:18:47 2014
New Revision: 1564668

URL: http://svn.apache.org/r1564668
Log:
Ensure proper HAVE_IPV6 define is used

Modified:
tomcat/jk/trunk/native/common/jk_connect.c

Modified: tomcat/jk/trunk/native/common/jk_connect.c
URL: 
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_connect.c?rev=1564668&r1=1564667&r2=1564668&view=diff
==
--- tomcat/jk/trunk/native/common/jk_connect.c (original)
+++ tomcat/jk/trunk/native/common/jk_connect.c Wed Feb  5 08:18:47 2014
@@ -1194,7 +1194,7 @@ char *jk_dump_hinfo(jk_sockaddr_t *saddr
 if (saddr->family == JK_INET) {
 inet_ntop4(saddr->ipaddr_ptr, buf, 16);
 }
-#if APR_HAVE_IPV6
+#if JK_HAVE_IPV6
 else {
 inet_ntop6(saddr->ipaddr_ptr, buf, 64);
 }
@@ -1222,7 +1222,7 @@ char *jk_dump_sinfo(jk_sock_t sd, char *
 inet_ntop4((unsigned char *)&sa->sin_addr,  buf, 16);
 sprintf(pb, ":%d", (unsigned int)htons(sa->sin_port));
 }
-#if APR_HAVE_IPV6
+#if JK_HAVE_IPV6
 else {
 struct sockaddr_in6 *sa = (struct sockaddr_in6 *)&lsaddr;
 inet_ntop6((unsigned char *)&sa->sin6_addr, buf, 64);
@@ -1237,7 +1237,7 @@ char *jk_dump_sinfo(jk_sock_t sd, char *
 inet_ntop4((unsigned char *)&sa->sin_addr,  buf + ps, 16);
 sprintf(pb, ":%d", (unsigned int)htons(sa->sin_port));
 }
-#if APR_HAVE_IPV6
+#if JK_HAVE_IPV6
 else {
 struct sockaddr_in6 *sa = (struct sockaddr_in6 *)&rsaddr;
 inet_ntop6((unsigned char *)&sa->sin6_addr, buf + ps, 64);



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