Consider forcing Stash to use /dev/urandom not /dev/random for SecureRandom seeds to avoid slow startup on low initial entropy systems

XMLWordPrintable

      Atlassian Update – December 2017

      Hi everyone,

      We have recently reviewed this issue and the overall interest in the problem. As the issue hasn't collect votes, watchers, comments, or support cases from many customers during its lifetime, it's very low on our priority list, and will not be fixed in the foreseeable future. That's why we've decided to resolve it as Timed Out.

      Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Bitbucket Server team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Atlassian Bugfix Policy for more details.

      We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments.

      Thank you,

      Imran Khan
      Product Manager - Bitbucket Server and Data Center

      /dev/random blocks if the entropy pool is empty whereas /dev/urandom does not block. In most Linux distros /dev/urandom is always primed with 32 bytes either from the initial installation or from a hashed carryover from the previous boot which makes it unpredictable enough for non-information-theoretically secure algorithms.

      See http://security.stackexchange.com/a/7074

      This caused horrifically slow startup times for a customer's install (Tomcat's SecureRandom for session IDs was blocking for 6 minutes).

            Assignee:
            Unassigned
            Reporter:
            Michael Studman (Inactive)
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: