Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-20108

SSH slaves can block for a long time in NativePRNG

      Have encountered some reports of slow slave performance on a Unix master using many slaves where the thread dumps show all but one slave connection thread waiting for a single lock, which is held by a thread that looks like this:

      "Pipe writer thread: ..." - Thread ...
         java.lang.Thread.State: RUNNABLE
          at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:255)
          - locked <598aec0c> (a java.lang.Object)
          at sun.security.provider.NativePRNG$RandomIO.access$200(NativePRNG.java:108)
          at sun.security.provider.NativePRNG.engineNextBytes(NativePRNG.java:97)
          at java.security.SecureRandom.nextBytes(SecureRandom.java:433)
          - locked <329129da> (a java.security.SecureRandom)
          at java.security.SecureRandom.next(SecureRandom.java:455)
          at java.util.Random.nextInt(Random.java:189)
          at com.trilead.ssh2.transport.TransportConnection.sendMessage(TransportConnection.java:154)
      

      From what I can tell neither the Jenkins SSH Slaves plugin nor the Trilead SSH library are to blame, as they produce a different SecureRandom instance for each slave. Rather it is NativePRNG (the default implementation on typical Linux installations among others) which uses a global lock, to synchronize access to /dev/random and /dev/urandom; and random can block waiting for sufficient entropy to accumulate.

      It might help for the SSH Slaves plugin to offer a java.security.SecureRandom based on sun.security.provider.SecureRandom, which does not acquire a global lock to process connection data. (It may take longer to set up a connection, since it needs to seed the random-number generator based on thread activity.)

      Unconfirmed workarounds:

      • Edit the JRE's $JAVA_HOME/lib/security/java.security to comment out the line securerandom.source=file:/dev/urandom (should switch back to the generic implementation)
      • Running -Djava.security.egd=file:/dev/./urandom (should force use of urandom which is supposed to be nonblocking)

          [JENKINS-20108] SSH slaves can block for a long time in NativePRNG

          gatrot added a comment -

          I just noticed this as well using 1.525. I pushed haveged to all of my Linux slaves and the Jenkins master. This seemed to help drastically and didn't require JAVA_OPTS modifications.

          gatrot added a comment - I just noticed this as well using 1.525. I pushed haveged to all of my Linux slaves and the Jenkins master. This seemed to help drastically and didn't require JAVA_OPTS modifications.

          Greg horvath added a comment -

          Just ran in to the same issue. Wonder if we can get this moving, as the ticket is almost a year old.

          Greg horvath added a comment - Just ran in to the same issue. Wonder if we can get this moving, as the ticket is almost a year old.

          There are some pretty important dots missing here.

          NativePRNG$RandomIO.implNextBytes() does unfortunately use a global lock, and this method gets called every time SecureRandom is used to generate more bytes. So one can imagine if lots of threads want to do this, the lock gets contended and slows down.

          But NativePRNG$RandomIO.implNextBytes() doesn't use /dev/random by itself. It delegates to sun.security.provider.SecureRandom#engineNextBytes() (which is what getMixRandom() returns), then it reads from /dev/urandom (happen in ensureBufferValid) and XOR bytes.

          // get pseudo random bytes
          // read from /dev/urandom and XOR with bytes generated by the
          // mixing SHA1PRNG
          private void implNextBytes(byte[] data) {
              synchronized (LOCK_GET_BYTES) {
                  try {
                      getMixRandom().engineNextBytes(data);
                      int len = data.length;
                      int ofs = 0;
                      while (len > 0) {
                          ensureBufferValid();
                          int bufferOfs = urandomBuffer.length - buffered;
                          while ((len > 0) && (buffered > 0)) {
                              data[ofs++] ^= urandomBuffer[bufferOfs++];
                              len--;
                              buffered--;
                          }
                      }
                  } catch (IOException e) {
                      throw new ProviderException("nextBytes() failed", e);
                  }
              }
          }
          

          And sun.security.provider.SecureRandom#engineNextBytes() only uses seeder.engineNextBytes() once to create the initial hidden state, which means in the call path of NativePRNG.engineNextBytes() this only happens once in JVM. The rest is just SHA1 digest computation:

          /**
           * Generates a user-specified number of random bytes.
           *
           * @param bytes the array to be filled in with random bytes.
           */
          public synchronized void engineNextBytes(byte[] result) {
              int index = 0;
              int todo;
              byte[] output = remainder;
          
              if (state == null) {
                  byte[] seed = new byte[DIGEST_SIZE];
                  SeederHolder.seeder.engineNextBytes(seed);
                  state = digest.digest(seed);
              }
          
              ...
          }
          

          So whatever that seeder does (such as possibly accessing /dev/random and blocking), it can't impact the overall performance once!

          What seems to be actually happening is that the -Djava.security.egd=file:/dev/./urandom property causes SecureRandomSpi to switch to the instance of sun.security.provider.SecureRandom, not sun.security.provider.NativePRNG, which entirely bypasses reading /dev/urandom and just go straight to SHA1 computation. This happens in sun.security.provider.SunEntries

          static void putEntries(Map<Object, Object> map) {
          
              /*
               * SecureRandom
               *
               * Register these first to speed up "new SecureRandom()",
               * which iterates through the list of algorithms
               */
              // register the native PRNG, if available
              // if user selected /dev/urandom, we put it before SHA1PRNG,
              // otherwise after it
              boolean nativeAvailable = NativePRNG.isAvailable();
              boolean useUrandom = seedSource.equals(URL_DEV_URANDOM);
              if (nativeAvailable && useUrandom) {
                  map.put("SecureRandom.NativePRNG",
                      "sun.security.provider.NativePRNG");
              }
              map.put("SecureRandom.SHA1PRNG",
                   "sun.security.provider.SecureRandom");
              if (nativeAvailable && !useUrandom) {
                  map.put("SecureRandom.NativePRNG",
                      "sun.security.provider.NativePRNG");
              }
          

          You can see the effect of this in the following simple program:

          public class Foo {
              public static void main(String[] args) throws Exception {
                  SecureRandom s = new SecureRandom();
                  System.out.println(s.getProvider());
          
                  Field f = s.getClass().getDeclaredField("secureRandomSpi");
                  f.setAccessible(true);
                  Object spi = f.get(s);
                  System.out.println(spi);
              }
          }
          
          java.security.egd=file:/dev/./urandom
          SUN version 1.6
          sun.security.provider.SecureRandom@398020cc
          
          java.security.egd=null
          SUN version 1.6
          sun.security.provider.NativePRNG@2bf14ceb
          

          All this is doing is to bypass a global lock (and stop using /dev/urandom altogether), and yes, I can definitely see why that is a boon to the performance, but this has nothing to do with /dev/random blocking. The switch doesn't cause JVM to use /dev/urandom instead of /dev/random. It just bypasses both.

          Kohsuke Kawaguchi added a comment - There are some pretty important dots missing here. NativePRNG$RandomIO.implNextBytes() does unfortunately use a global lock, and this method gets called every time SecureRandom is used to generate more bytes. So one can imagine if lots of threads want to do this, the lock gets contended and slows down. But NativePRNG$RandomIO.implNextBytes() doesn't use /dev/random by itself. It delegates to sun.security.provider.SecureRandom#engineNextBytes() (which is what getMixRandom() returns), then it reads from /dev/urandom (happen in ensureBufferValid ) and XOR bytes. // get pseudo random bytes // read from /dev/urandom and XOR with bytes generated by the // mixing SHA1PRNG private void implNextBytes( byte [] data) { synchronized (LOCK_GET_BYTES) { try { getMixRandom().engineNextBytes(data); int len = data.length; int ofs = 0; while (len > 0) { ensureBufferValid(); int bufferOfs = urandomBuffer.length - buffered; while ((len > 0) && (buffered > 0)) { data[ofs++] ^= urandomBuffer[bufferOfs++]; len--; buffered--; } } } catch (IOException e) { throw new ProviderException( "nextBytes() failed" , e); } } } And sun.security.provider.SecureRandom#engineNextBytes() only uses seeder.engineNextBytes() once to create the initial hidden state, which means in the call path of NativePRNG.engineNextBytes() this only happens once in JVM. The rest is just SHA1 digest computation: /** * Generates a user-specified number of random bytes. * * @param bytes the array to be filled in with random bytes. */ public synchronized void engineNextBytes( byte [] result) { int index = 0; int todo; byte [] output = remainder; if (state == null ) { byte [] seed = new byte [DIGEST_SIZE]; SeederHolder.seeder.engineNextBytes(seed); state = digest.digest(seed); } ... } So whatever that seeder does (such as possibly accessing /dev/random and blocking), it can't impact the overall performance once! What seems to be actually happening is that the -Djava.security.egd= file:/dev/./urandom property causes SecureRandomSpi to switch to the instance of sun.security.provider.SecureRandom , not sun.security.provider.NativePRNG , which entirely bypasses reading /dev/urandom and just go straight to SHA1 computation. This happens in sun.security.provider.SunEntries static void putEntries(Map< Object , Object > map) { /* * SecureRandom * * Register these first to speed up " new SecureRandom()" , * which iterates through the list of algorithms */ // register the native PRNG, if available // if user selected /dev/urandom, we put it before SHA1PRNG, // otherwise after it boolean nativeAvailable = NativePRNG.isAvailable(); boolean useUrandom = seedSource.equals(URL_DEV_URANDOM); if (nativeAvailable && useUrandom) { map.put( "SecureRandom.NativePRNG" , "sun.security.provider.NativePRNG" ); } map.put( "SecureRandom.SHA1PRNG" , "sun.security.provider.SecureRandom" ); if (nativeAvailable && !useUrandom) { map.put( "SecureRandom.NativePRNG" , "sun.security.provider.NativePRNG" ); } You can see the effect of this in the following simple program: public class Foo { public static void main( String [] args) throws Exception { SecureRandom s = new SecureRandom(); System .out.println(s.getProvider()); Field f = s.getClass().getDeclaredField( "secureRandomSpi" ); f.setAccessible( true ); Object spi = f.get(s); System .out.println(spi); } } java.security.egd=file:/dev/./urandom SUN version 1.6 sun.security.provider.SecureRandom@398020cc java.security.egd=null SUN version 1.6 sun.security.provider.NativePRNG@2bf14ceb All this is doing is to bypass a global lock (and stop using /dev/urandom altogether), and yes, I can definitely see why that is a boon to the performance, but this has nothing to do with /dev/random blocking. The switch doesn't cause JVM to use /dev/urandom instead of /dev/random . It just bypasses both.

          Among other things, this means the suggestion to increase entropy of the system (such as the likes of haveged) is likely irrelevant.

          Kohsuke Kawaguchi added a comment - Among other things, this means the suggestion to increase entropy of the system (such as the likes of haveged ) is likely irrelevant.

          I've done microbenchmark of SecureRandom to test this.

          The CPU was Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz, 2 core, 4 threads. OS is Linux 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux.

          The test instantiates one SecureRandom per thread and generate 1MB of random numbers, while measuring the time to do this. This run gets repeated 100 times to measure the variance of each run. Unit of measurement is ns.

          In multi-threaded tests, the above gets run concurrently. The usual warm-up runs and post-measurement is inserted to make sure all the threads measure their performances while all the other threads are fully running.

          The first one uses new SecureRandom() which selects NativePRNG:

          single thread, 1 instance
          Provider=SUN version 1.6, SPI=sun.security.provider.NativePRNG@2626d4f1
          average=125,274,140, stddev=4,173,778
          average=123,310,918, stddev=1,378,205
          average=123,572,870, stddev=1,193,628
          
          2 threads, 2 instances
          Provider=SUN version 1.6, SPI=sun.security.provider.NativePRNG@37e893df
          average=279,906,854, stddev=152,013,543
          average=297,470,998, stddev=141,156,000
          
          4 threads, 4 instances
          Provider=SUN version 1.6, SPI=sun.security.provider.NativePRNG@67386000
          average=481,466,668, stddev=0
          average=548,326,932, stddev=0
          average=618,292,518, stddev=0
          average=698,000,865, stddev=185,175,894
          

          It clearly shows the effect of contended global lock, even at 2 threads. CPU usage monitor also clearly indicates that the program fails to keep CPU pegged at 100%.

          This next one uses SecureRandom.getInstance("SHA1PRNG)

          1 thread
          Provider=SUN version 1.6, SPI=sun.security.provider.SecureRandom@13d4c61c
          average=20,976,505, stddev=1,052,441
          
          2 threads, 2 instances
          Provider=SUN version 1.6, SPI=sun.security.provider.SecureRandom@12b82368
          average=29,316,610, stddev=7,856,792
          average=29,675,002, stddev=7,529,021
          
          4 threads, 4 instances
          Provider=SUN version 1.6, SPI=sun.security.provider.SecureRandom@2cb0ce8f
          average=42,3804,33, stddev=4,039,875
          average=42,866,789, stddev=4,043,125
          average=42,205,430, stddev=5,275,983
          average=45,091,333, stddev=4,840,461
          

          Here, not only the execution is considerably faster, but it scales much better. All 4 cores are kept 100% busy during the 4 thread test.

          In search of other faster CRPRNG, I've also tried AESCountingRNG:

          1 thread, AESCounterRNG
          average=18,537,563, stddev=1,545,647
          
          2 threads, 2 instances
          average=24,666,657, stddev=2,966,315
          average=24,755,655, stddev=2,946,206
          
          4 threads, 4 instances
          average=32,876,768, stddev=3,681,410
          average=36,600,687, stddev=3,410,178
          average=37,669,234, stddev=3,579,337
          average=37,598,152, stddev=3,536,743
          

          This is somewhat faster than SHA1PRNG. All 4 cores are kept busy during the 4 thread test.

          Finally, what about the performance of /dev/urandom? I've used the following shell script to measure:

          while true; do time dd if=/dev/urandom of=/dev/null bs=1MB count=1000; done
          

          Single threaded:

          1000000000 bytes (1.0 GB) copied, 71.471 s, 14.0 MB/s
          dd if=/dev/urandom of=/dev/null bs=1MB count=1000  0.00s user 71.50s system 100% cpu 1:11.47 total
          1000000000 bytes (1.0 GB) copied, 71.3007 s, 14.0 MB/s
          dd if=/dev/urandom of=/dev/null bs=1MB count=1000  0.00s user 71.36s system 100% cpu 1:11.30 total
          1000000000 bytes (1.0 GB) copied, 71.1508 s, 14.1 MB/s
          dd if=/dev/urandom of=/dev/null bs=1MB count=1000  0.00s user 71.21s system 100% cpu 1:11.15 total
          

          2 threads:

          1000000000 bytes (1.0 GB) copied, 133.55 s, 7.5 MB/s
          dd if=/dev/urandom of=/dev/null bs=1MB count=1000  0.01s user 133.64s system 100% cpu 2:13.55 total
          1000000000 bytes (1.0 GB) copied, 133.243 s, 7.5 MB/s
          dd if=/dev/urandom of=/dev/null bs=1MB count=1000  0.00s user 133.33s system 100% cpu 2:13.24 total
          1000000000 bytes (1.0 GB) copied, 134.352 s, 7.4 MB/s
          dd if=/dev/urandom of=/dev/null bs=1MB count=1000  0.00s user 134.43s system 100% cpu 2:14.35 total
          

          4 threads:

          1000000000 bytes (1.0 GB) copied, 353.65 s, 2.8 MB/s
          dd if=/dev/urandom of=/dev/null bs=1MB count=1000  0.00s user 348.54s system 98% cpu 5:53.65 total
          1000000000 bytes (1.0 GB) copied, 354.961 s, 2.8 MB/s
          dd if=/dev/urandom of=/dev/null bs=1MB count=1000  0.00s user 348.84s system 98% cpu 5:54.97 total
          

          14MB/sec translates to about 70,000,000ns per MB. So this is already considerably slower than SHA1PRNG. It is also obvious that /dev/urandom doesn't scale, although it is worth noting that CPUs are kept 100% busy during this experiment.

          Based on this, I think we should just change trilead code to use SHA1PRNG by default.

          Kohsuke Kawaguchi added a comment - I've done microbenchmark of SecureRandom to test this. The CPU was Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz, 2 core, 4 threads . OS is Linux 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux . The test instantiates one SecureRandom per thread and generate 1MB of random numbers, while measuring the time to do this. This run gets repeated 100 times to measure the variance of each run. Unit of measurement is ns. In multi-threaded tests, the above gets run concurrently. The usual warm-up runs and post-measurement is inserted to make sure all the threads measure their performances while all the other threads are fully running. The first one uses new SecureRandom() which selects NativePRNG : single thread, 1 instance Provider=SUN version 1.6, SPI=sun.security.provider.NativePRNG@2626d4f1 average=125,274,140, stddev=4,173,778 average=123,310,918, stddev=1,378,205 average=123,572,870, stddev=1,193,628 2 threads, 2 instances Provider=SUN version 1.6, SPI=sun.security.provider.NativePRNG@37e893df average=279,906,854, stddev=152,013,543 average=297,470,998, stddev=141,156,000 4 threads, 4 instances Provider=SUN version 1.6, SPI=sun.security.provider.NativePRNG@67386000 average=481,466,668, stddev=0 average=548,326,932, stddev=0 average=618,292,518, stddev=0 average=698,000,865, stddev=185,175,894 It clearly shows the effect of contended global lock, even at 2 threads. CPU usage monitor also clearly indicates that the program fails to keep CPU pegged at 100%. This next one uses SecureRandom.getInstance("SHA1PRNG) 1 thread Provider=SUN version 1.6, SPI=sun.security.provider.SecureRandom@13d4c61c average=20,976,505, stddev=1,052,441 2 threads, 2 instances Provider=SUN version 1.6, SPI=sun.security.provider.SecureRandom@12b82368 average=29,316,610, stddev=7,856,792 average=29,675,002, stddev=7,529,021 4 threads, 4 instances Provider=SUN version 1.6, SPI=sun.security.provider.SecureRandom@2cb0ce8f average=42,3804,33, stddev=4,039,875 average=42,866,789, stddev=4,043,125 average=42,205,430, stddev=5,275,983 average=45,091,333, stddev=4,840,461 Here, not only the execution is considerably faster, but it scales much better. All 4 cores are kept 100% busy during the 4 thread test. In search of other faster CRPRNG, I've also tried AESCountingRNG : 1 thread, AESCounterRNG average=18,537,563, stddev=1,545,647 2 threads, 2 instances average=24,666,657, stddev=2,966,315 average=24,755,655, stddev=2,946,206 4 threads, 4 instances average=32,876,768, stddev=3,681,410 average=36,600,687, stddev=3,410,178 average=37,669,234, stddev=3,579,337 average=37,598,152, stddev=3,536,743 This is somewhat faster than SHA1PRNG. All 4 cores are kept busy during the 4 thread test. Finally, what about the performance of /dev/urandom ? I've used the following shell script to measure: while true; do time dd if=/dev/urandom of=/dev/null bs=1MB count=1000; done Single threaded: 1000000000 bytes (1.0 GB) copied, 71.471 s, 14.0 MB/s dd if=/dev/urandom of=/dev/null bs=1MB count=1000 0.00s user 71.50s system 100% cpu 1:11.47 total 1000000000 bytes (1.0 GB) copied, 71.3007 s, 14.0 MB/s dd if=/dev/urandom of=/dev/null bs=1MB count=1000 0.00s user 71.36s system 100% cpu 1:11.30 total 1000000000 bytes (1.0 GB) copied, 71.1508 s, 14.1 MB/s dd if=/dev/urandom of=/dev/null bs=1MB count=1000 0.00s user 71.21s system 100% cpu 1:11.15 total 2 threads: 1000000000 bytes (1.0 GB) copied, 133.55 s, 7.5 MB/s dd if=/dev/urandom of=/dev/null bs=1MB count=1000 0.01s user 133.64s system 100% cpu 2:13.55 total 1000000000 bytes (1.0 GB) copied, 133.243 s, 7.5 MB/s dd if=/dev/urandom of=/dev/null bs=1MB count=1000 0.00s user 133.33s system 100% cpu 2:13.24 total 1000000000 bytes (1.0 GB) copied, 134.352 s, 7.4 MB/s dd if=/dev/urandom of=/dev/null bs=1MB count=1000 0.00s user 134.43s system 100% cpu 2:14.35 total 4 threads: 1000000000 bytes (1.0 GB) copied, 353.65 s, 2.8 MB/s dd if=/dev/urandom of=/dev/null bs=1MB count=1000 0.00s user 348.54s system 98% cpu 5:53.65 total 1000000000 bytes (1.0 GB) copied, 354.961 s, 2.8 MB/s dd if=/dev/urandom of=/dev/null bs=1MB count=1000 0.00s user 348.84s system 98% cpu 5:54.97 total 14MB/sec translates to about 70,000,000ns per MB. So this is already considerably slower than SHA1PRNG. It is also obvious that /dev/urandom doesn't scale, although it is worth noting that CPUs are kept 100% busy during this experiment. Based on this, I think we should just change trilead code to use SHA1PRNG by default.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          src/com/trilead/ssh2/Connection.java
          src/com/trilead/ssh2/KnownHosts.java
          src/com/trilead/ssh2/RandomFactory.java
          http://jenkins-ci.org/commit/trilead-ssh2/961adfb2762d84e952c3b49126adaa5fa2c4933e
          Log:
          JENKINS-20108

          Prefer SHA1PRNG, which avoids VM-wide global lock on Unix.

          Another way to fix this is to avoid repeated calls to "rnd.nextInt()" in
          TransportConnection.sendMessage() and instead get all the padding in one call.

          That would require another byte array as there's no SecureRandom.nextBytes(byte[],int,int),
          but that'd be a monitor cost in the face of VM-wide lock across all the SecureRandom instances.

          The amount of padding is fairly small, so yet another way to fix this is to buffer random bytes
          by hitting SecureRandom in a bigger block (thus infrequentl) and save the rest at Connection.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: src/com/trilead/ssh2/Connection.java src/com/trilead/ssh2/KnownHosts.java src/com/trilead/ssh2/RandomFactory.java http://jenkins-ci.org/commit/trilead-ssh2/961adfb2762d84e952c3b49126adaa5fa2c4933e Log: JENKINS-20108 Prefer SHA1PRNG, which avoids VM-wide global lock on Unix. Another way to fix this is to avoid repeated calls to "rnd.nextInt()" in TransportConnection.sendMessage() and instead get all the padding in one call. That would require another byte array as there's no SecureRandom.nextBytes(byte[],int,int), but that'd be a monitor cost in the face of VM-wide lock across all the SecureRandom instances. The amount of padding is fairly small, so yet another way to fix this is to buffer random bytes by hitting SecureRandom in a bigger block (thus infrequentl) and save the rest at Connection.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          core/pom.xml
          http://jenkins-ci.org/commit/jenkins/70f5968160b0a1cf81dc451fd2aacf1e0f9201ea
          Log:
          [FIXED JENKINS-20108]

          Integrated the trilead with SecureRandom instantiation fix.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/pom.xml http://jenkins-ci.org/commit/jenkins/70f5968160b0a1cf81dc451fd2aacf1e0f9201ea Log: [FIXED JENKINS-20108] Integrated the trilead with SecureRandom instantiation fix.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3742
          [FIXED JENKINS-20108] (Revision 70f5968160b0a1cf81dc451fd2aacf1e0f9201ea)

          Result = SUCCESS
          kohsuke : 70f5968160b0a1cf81dc451fd2aacf1e0f9201ea
          Files :

          • changelog.html
          • core/pom.xml

          dogfood added a comment - Integrated in jenkins_main_trunk #3742 [FIXED JENKINS-20108] (Revision 70f5968160b0a1cf81dc451fd2aacf1e0f9201ea) Result = SUCCESS kohsuke : 70f5968160b0a1cf81dc451fd2aacf1e0f9201ea Files : changelog.html core/pom.xml

          Jesse Glick added a comment -

          Unfortunate that Trilead SSH in bundled in core; we would really prefer such updates to done directly in the ssh-slaves plugin.

          Has this issue been filed upstream?

          Jesse Glick added a comment - Unfortunate that Trilead SSH in bundled in core; we would really prefer such updates to done directly in the ssh-slaves plugin. Has this issue been filed upstream?

          Jesse Glick added a comment -

          For the record:

          The switch doesn't cause JVM to use /dev/urandom instead of /dev/random. It just bypasses both.

          That is what happens when you use the obvious

          -Djava.security.egd=file:/dev/urandom
          

          When you use the tricky

          -Djava.security.egd=file:/dev/./urandom
          

          then this does not match URL_DEV_URANDOM and so /dev/urandom is used.

          Jesse Glick added a comment - For the record: The switch doesn't cause JVM to use /dev/urandom instead of /dev/random . It just bypasses both. That is what happens when you use the obvious -Djava.security.egd=file:/dev/urandom When you use the tricky -Djava.security.egd=file:/dev/./urandom then this does not match URL_DEV_URANDOM and so /dev/urandom is used.

          There's no upstream for trilead ssh anymore. There was an invitation from another fork maintainer to combine the effort, but he was using trilead in different package name, so we couldn't switch.

          As for removing this from the core, we need to check if anyone else is using it from their plugins. ssh-plugin can potentially use a child-first classloading to have its copy of trilead, which might be a cheaper way to solve this problem.

          Finally, with the -Djava.security.egd=file:/dev/./urandom switch, I meant /dev/urandom is only used for seeding SHA1PRNG but not for generating actual random numbers.

          Kohsuke Kawaguchi added a comment - There's no upstream for trilead ssh anymore. There was an invitation from another fork maintainer to combine the effort, but he was using trilead in different package name, so we couldn't switch. As for removing this from the core, we need to check if anyone else is using it from their plugins. ssh-plugin can potentially use a child-first classloading to have its copy of trilead, which might be a cheaper way to solve this problem. Finally, with the -Djava.security.egd= file:/dev/./urandom switch, I meant /dev/urandom is only used for seeding SHA1PRNG but not for generating actual random numbers.

          Chris Reynolds added a comment - - edited

          Chris Reynolds added a comment - - edited Created https://issues.jenkins-ci.org/browse/JENKINS-25241

          Jesse Glick added a comment -

          csreynolds it is best to file a bug with the regression keyword blocking this one, so it can be assigned and its fix tracked.

          Jesse Glick added a comment - csreynolds it is best to file a bug with the regression keyword blocking this one, so it can be assigned and its fix tracked.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          core/pom.xml
          http://jenkins-ci.org/commit/jenkins/68eb26633b1c042d90a426efac7b6e60dd4b2ede
          Log:
          [FIXED JENKINS-20108]

          Integrated the trilead with SecureRandom instantiation fix.

          (cherry picked from commit 70f5968160b0a1cf81dc451fd2aacf1e0f9201ea)

          Conflicts:
          changelog.html
          core/pom.xml

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: core/pom.xml http://jenkins-ci.org/commit/jenkins/68eb26633b1c042d90a426efac7b6e60dd4b2ede Log: [FIXED JENKINS-20108] Integrated the trilead with SecureRandom instantiation fix. (cherry picked from commit 70f5968160b0a1cf81dc451fd2aacf1e0f9201ea) Conflicts: changelog.html core/pom.xml

          Code changed in jenkins
          User: Oliver Gondža
          Path:
          core/pom.xml
          http://jenkins-ci.org/commit/jenkins/8fbd44db2b2ebf81947a6c3c5861bc30b48cc775
          Log:
          Revert "[FIXED JENKINS-20108]"

          This reverts commit 68eb26633b1c042d90a426efac7b6e60dd4b2ede.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oliver Gondža Path: core/pom.xml http://jenkins-ci.org/commit/jenkins/8fbd44db2b2ebf81947a6c3c5861bc30b48cc775 Log: Revert " [FIXED JENKINS-20108] " This reverts commit 68eb26633b1c042d90a426efac7b6e60dd4b2ede.

          Daniel Beck added a comment -

          This caused JENKINS-25241 so unfit for LTS.

          Daniel Beck added a comment - This caused JENKINS-25241 so unfit for LTS.

          Jesse Glick added a comment -

          JENKINS-25241 has been fixed in 2.4.5 so I think this can be reconsidered for 1.580.3.

          Jesse Glick added a comment - JENKINS-25241 has been fixed in 2.4.5 so I think this can be reconsidered for 1.580.3.

          Daniel Beck added a comment -

          Jesse: IMO conditional on that issue not happening on the still bundled Subversion plugin 1.x. Forcing users to upgrade to 2.x wouldn't be nice in a minor LTS update.

          Daniel Beck added a comment - Jesse: IMO conditional on that issue not happening on the still bundled Subversion plugin 1.x. Forcing users to upgrade to 2.x wouldn't be nice in a minor LTS update.

          Jesse Glick added a comment -

          True, I forgot that we are still bundling an obsolete version of the plugin.

          Jesse Glick added a comment - True, I forgot that we are still bundling an obsolete version of the plugin.

          Rejected for 1.580.3. Removing lts-candidate label entirely, as this will be part of next LTS line anyway.

          Oliver Gondža added a comment - Rejected for 1.580.3. Removing lts-candidate label entirely, as this will be part of next LTS line anyway.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #4292
          [FIXED JENKINS-20108] (Revision 68eb26633b1c042d90a426efac7b6e60dd4b2ede)
          Revert "[FIXED JENKINS-20108]" (Revision 8fbd44db2b2ebf81947a6c3c5861bc30b48cc775)

          Result = UNSTABLE
          ogondza : 68eb26633b1c042d90a426efac7b6e60dd4b2ede
          Files :

          • core/pom.xml

          ogondza : 8fbd44db2b2ebf81947a6c3c5861bc30b48cc775
          Files :

          • core/pom.xml

          dogfood added a comment - Integrated in jenkins_main_trunk #4292 [FIXED JENKINS-20108] (Revision 68eb26633b1c042d90a426efac7b6e60dd4b2ede) Revert " [FIXED JENKINS-20108] " (Revision 8fbd44db2b2ebf81947a6c3c5861bc30b48cc775) Result = UNSTABLE ogondza : 68eb26633b1c042d90a426efac7b6e60dd4b2ede Files : core/pom.xml ogondza : 8fbd44db2b2ebf81947a6c3c5861bc30b48cc775 Files : core/pom.xml

            kohsuke Kohsuke Kawaguchi
            jglick Jesse Glick
            Votes:
            1 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated:
              Resolved: