Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-5479

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

    XMLWordPrintable

Details

    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

    Description

      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).

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: