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

SSH slaves can block for a long time in NativePRNG

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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)

        Attachments

          Issue Links

            Activity

            jglick Jesse Glick created issue -
            Hide
            gatrot 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.

            Show
            gatrot 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.
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Assignee Kohsuke Kawaguchi [ kohsuke ]
            Hide
            greg 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.

            Show
            greg 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.
            Hide
            kohsuke 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.

            Show
            kohsuke 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.
            Hide
            kohsuke 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.

            Show
            kohsuke 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.
            Hide
            kohsuke 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.

            Show
            kohsuke 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.
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            scm_issue_link SCM/JIRA link daemon made changes -
            Resolution Fixed [ 1 ]
            Status Open [ 1 ] Resolved [ 5 ]
            Hide
            dogfood 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
            Show
            dogfood 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
            jglick Jesse Glick made changes -
            Labels performance lts-candidate performance
            Hide
            jglick 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?

            Show
            jglick 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?
            jglick Jesse Glick made changes -
            Assignee Kohsuke Kawaguchi [ kohsuke ]
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            kohsuke 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.

            Show
            kohsuke 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.
            Hide
            csreynolds Chris Reynolds added a comment - - edited
            Show
            csreynolds Chris Reynolds added a comment - - edited Created https://issues.jenkins-ci.org/browse/JENKINS-25241
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - Chris Reynolds it is best to file a bug with the regression keyword blocking this one, so it can be assigned and its fix tracked.
            jglick Jesse Glick made changes -
            Link This issue depends on JENKINS-25241 [ JENKINS-25241 ]
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            olivergondza Oliver Gondža made changes -
            Labels lts-candidate performance 1.580.2-fixed performance
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            olivergondza Oliver Gondža made changes -
            Labels 1.580.2-fixed performance 1.580.2-rejected performance
            Hide
            danielbeck Daniel Beck added a comment -

            This caused JENKINS-25241 so unfit for LTS.

            Show
            danielbeck Daniel Beck added a comment - This caused JENKINS-25241 so unfit for LTS.
            olivergondza Oliver Gondža made changes -
            Labels 1.580.2-rejected performance 1.580.2-rejected lts-candidate performance
            jglick Jesse Glick made changes -
            Link This issue is blocking JENKINS-25241 [ JENKINS-25241 ]
            jglick Jesse Glick made changes -
            Link This issue depends on JENKINS-25241 [ JENKINS-25241 ]
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - True, I forgot that we are still bundling an obsolete version of the plugin.
            olivergondza Oliver Gondža made changes -
            Labels 1.580.2-rejected lts-candidate performance 1.580.2-rejected performance
            olivergondza Oliver Gondža made changes -
            Labels 1.580.2-rejected performance 1.580.2-rejected 1.580.3-rejected performance
            Hide
            olivergondza 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.

            Show
            olivergondza 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.
            Hide
            dogfood 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
            Show
            dogfood 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
            jglick Jesse Glick made changes -
            Link This issue is related to JENKINS-32510 [ JENKINS-32510 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 151630 ] JNJira + In-Review [ 194015 ]
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal CJP-2555 (Web Link)" [ 19185 ]

              People

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

                Dates

                Created:
                Updated:
                Resolved: