You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2017/05/05 05:29:03 UTC

[Bug 61072] New: SessionIdGeneratorBase will not use platform default SecureRandom algorithm for empty secureRandomAlgorithm attribute

https://bz.apache.org/bugzilla/show_bug.cgi?id=61072

            Bug ID: 61072
           Summary: SessionIdGeneratorBase will not use platform default
                    SecureRandom algorithm for empty secureRandomAlgorithm
                    attribute
           Product: Tomcat 9
           Version: 9.0.0.M20
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: simon.bjorner@gmail.com
  Target Milestone: -----

Setting secureRandomAlgorithm to an empty string and not specifying
secureRandomProvider still seems to lead to SessionIdGeneratorBase creating its
SecureRandom instance using SecureRandom.getInstance("SHA1PRNG"), which is
contrary to the wording in the documentation saying "To specify that the
platform default should be used, do not set the secureRandomProvider attribute
and set this attribute to the empty string.". See the implementation of
SessionIdGeneratorBase.createSecureRandom(), where the "result = new
SecureRandom()" line doesn't seem to be triggered for this case
(secureRandomProvider=null, secureRandomAlgorithm="").

Getting the platform default SecureRandom algorithm is wanted on Linux systems
where /dev/random blocks or is slow, either due to misconfiguration or
exhaustion. See the latest comment on
http://bugs.java.com/view_bug.do?bug_id=4705093 for a description of the
current SecureRandom behavior. Regardless of that problem, and the motivation
it provides for being able to easily get a default algorithm SecureRandom, I
believe the former paragraph describes either a documentation or implementation
bug in itself, so unless requested I don't think it's necessary to prove in
this bug entry that Tomcat hangs on such a system. (Though it could be argued
that platform default SecureRandom would be a better default to make Tomcat
never block on /dev/random out-of-the-box.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 61072] SessionIdGeneratorBase will not use platform default SecureRandom algorithm for empty secureRandomAlgorithm attribute

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61072

--- Comment #1 from Remy Maucherat <re...@apache.org> ---
I agree it should do what the specification says. I made a change to only use
the hardcoding if there is an error.
It will be in 9.0.0.M22, and it will be backported once the current release
cycle is complete.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 61072] SessionIdGeneratorBase will not use platform default SecureRandom algorithm for empty secureRandomAlgorithm attribute

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61072

Remy Maucherat <re...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Remy Maucherat <re...@apache.org> ---
This should be fixed. 8.5.16, 8.0.44 and 7.0.78 will have the fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org