Skip to content

[JENKINS-34121] IBM Java doesn't support AES/CTR/PKCS5Padding, required for JNLP3 #1157

Closed
Bug
Closed
[JENKINS-34121] IBM Java doesn't support AES/CTR/PKCS5Padding, required for JNLP3#1157
Bug
Labels
component:remotingimported-jira-issuepriority:majorresolution:wont-fix

Description

@jenkins-infra-bot
jenkins-infra-bot
opened on Apr 8, 2016

It is not possible to run slaves anymore using IBM Java.

This is due to the new encrypted communication introduced in Jenkins 1.653, where the handshake is done using "AES/CTR/PKCS5Padding".
I couldn't find what ciphers IBM Java does or doesn't support (maybe nothing else than the default ones), but I created a quick test to check (see below).

Would it be possible to switch to a cipher supported by IBM Java?

Test:
import java.security.NoSuchAlgorithmException;
import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;
public class PaddingIssue {
private static final String CIPHER = "AES/CTR/PKCS5Padding";
public static void main(String[] args) throws NoSuchAlgorithmException, NoSuchPaddingException

{ Cipher encryptCipher = Cipher.getInstance(CIPHER); System.out.println("Fine!"); }

}

Executions:
IBM JAVA 1.6
/usr/lib/j2re1.6-ibm/jre/bin/java PaddingIssue
Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
at javax.crypto.Cipher.getInstance(Unknown Source)
at PaddingIssue.main(PaddingIssue.java:10)
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10126Padding or NoPadding
at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
at javax.crypto.Cipher$a.a(Unknown Source)
... 2 more

IBM JAVA 1.7
/usr/lib/j2re1.7-ibm/jre/bin/java PaddingIssue
Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
at javax.crypto.Cipher.getInstance(Unknown Source)
at PaddingIssue.main(PaddingIssue.java:10)
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10126Padding or NoPadding
at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
at javax.crypto.Cipher$a.a(Unknown Source)
... 2 more

IBM JAVA 1.8
/usr/lib/jvm/java-ibm-x86_64-80/jre/bin/java PaddingIssue
Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
at javax.crypto.Cipher.getInstance(Unknown Source)
at PaddingIssue.main(PaddingIssue.java:10)
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10126Padding or NoPadding
at com.ibm.crypto.provider.AbstractBufferingCipher.engineSetPadding(Unknown Source)
at javax.crypto.Cipher$a.a(Unknown Source)
... 2 more

OpenJDK 7
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java PaddingIssue
Fine!

Full stacktrace:
Mar 22, 2016 3:54:13 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP3-connect
Mar 22, 2016 3:54:14 PM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: Failed to create handshake ciphers
java.lang.AssertionError: Failed to create handshake ciphers
at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCiphers.java:116)
at org.jenkinsci.remoting.engine.JnlpProtocol3.performHandshake(JnlpProtocol3.java:138)
at org.jenkinsci.remoting.engine.JnlpProtocol.establishChannel(JnlpProtocol.java:77)
at hudson.remoting.Engine.run(Engine.java:308)
Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
at javax.crypto.Cipher.getInstance(Unknown Source)
at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCiphers.java:109)
... 3 more
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10
126Padding or NoPadding
at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
at javax.crypto.Cipher$a_.a(Unknown Source)
... 5 more

Originally reported by gloparm, imported from: IBM Java doesn't support AES/CTR/PKCS5Padding, required for JNLP3
  • status: Resolved
  • priority: Major
  • component(s): remoting
  • resolution: Won't Fix
  • resolved: 2017-03-07T08:44:04+00:00
  • votes: 2
  • watchers: 8
  • imported: 2025-11-25
Raw content of original issue 
It is not possible to run slaves anymore using IBM Java.



This is due to the new encrypted communication introduced in Jenkins 1.653, where the handshake is done using "AES/CTR/PKCS5Padding".
I couldn't find what ciphers IBM Java does or doesn't support (maybe nothing else than the default ones), but I created a quick test to check (see below).



Would it be possible to switch to a cipher supported by IBM Java?



Test:
import java.security.NoSuchAlgorithmException;
import javax.crypto.Cipher;
import javax.crypto.NoSuchPaddingException;
public class PaddingIssue {
	private static final String CIPHER = "AES/CTR/PKCS5Padding";
	public static void main(String[] args) throws NoSuchAlgorithmException, NoSuchPaddingException 

{
        Cipher encryptCipher = Cipher.getInstance(CIPHER);
        System.out.println("Fine!");
	}

}



Executions:
IBM JAVA 1.6
/usr/lib/j2re1.6-ibm/jre/bin/java PaddingIssue 
Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
	at javax.crypto.Cipher.getInstance(Unknown Source)
	at PaddingIssue.main(PaddingIssue.java:10)
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10126Padding or NoPadding
	at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
	at javax.crypto.Cipher$a.a(Unknown Source)
	... 2 more



IBM JAVA 1.7
/usr/lib/j2re1.7-ibm/jre/bin/java PaddingIssue 
Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
	at javax.crypto.Cipher.getInstance(Unknown Source)
	at PaddingIssue.main(PaddingIssue.java:10)
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10126Padding or NoPadding
	at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
	at javax.crypto.Cipher$a.a(Unknown Source)
	... 2 more



IBM JAVA 1.8
/usr/lib/jvm/java-ibm-x86_64-80/jre/bin/java PaddingIssue 
Exception in thread "main" java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
	at javax.crypto.Cipher.getInstance(Unknown Source)
	at PaddingIssue.main(PaddingIssue.java:10)
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10126Padding or NoPadding
	at com.ibm.crypto.provider.AbstractBufferingCipher.engineSetPadding(Unknown Source)
	at javax.crypto.Cipher$a.a(Unknown Source)
	... 2 more



OpenJDK 7
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java PaddingIssue 
Fine!



Full stacktrace:
Mar 22, 2016 3:54:13 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP3-connect
Mar 22, 2016 3:54:14 PM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: Failed to create handshake ciphers
java.lang.AssertionError: Failed to create handshake ciphers
        at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCiphers.java:116)
        at org.jenkinsci.remoting.engine.JnlpProtocol3.performHandshake(JnlpProtocol3.java:138)
        at org.jenkinsci.remoting.engine.JnlpProtocol.establishChannel(JnlpProtocol.java:77)
        at hudson.remoting.Engine.run(Engine.java:308)
Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CTR/PKCS5Padding
        at javax.crypto.Cipher.getInstance(Unknown Source)
        at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCiphers.java:109)
        ... 3 more
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10
126Padding or NoPadding
        at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
        at javax.crypto.Cipher$a_.a(Unknown Source)
        ... 5 more

Activity

  1. jenkins-infra-bot commented on Apr 11, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on Apr 11, 2016
    Author
    danielbeck:

    oleg_nenashev FYI

  2. jenkins-infra-bot commented on May 9, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 9, 2016
    Author
    nyoung02:
    • Original comment link
    • Raw content of original comment: 
      Hitting the same problem. As I work on platforms where the IBM JRE is the only option, this will stop me from upgrading my Jenkins instance.
      


      If it helps, I reverted the slave.jar file to an old one from another instance of Jenkins running on the same machine and this connects successfully using Jenkins 1.656, giving me a workaround of sorts.
      


      The version number of the slave that will connect is at 2.33.

    Hitting the same problem. As I work on platforms where the IBM JRE is the only option, this will stop me from upgrading my Jenkins instance.

    If it helps, I reverted the slave.jar file to an old one from another instance of Jenkins running on the same machine and this connects successfully using Jenkins 1.656, giving me a workaround of sorts.

    The version number of the slave that will connect is at 2.33.

  3. jenkins-infra-bot commented on May 9, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 9, 2016
    Author
    danielbeck:
    • Original comment link
    • Raw content of original comment: 
      What happens when you remove the JNLP3 protocol from the list of supported protocols on Jenkins master?
      


      CC stephenconnolly who's planning to implement JNLP4, maybe this can be considered.

    What happens when you remove the JNLP3 protocol from the list of supported protocols on Jenkins master?

    CC stephenconnolly who's planning to implement JNLP4, maybe this can be considered.

  4. jenkins-infra-bot commented on May 9, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 9, 2016
    Author
    stephenconnolly:
    • Original comment link
    • Raw content of original comment: 
      So the JNLP4 protocol is implemented already. I am just awaiting approval to release the code. As it uses TLS rather than a home grown cipher system this should not be an issue for JNLP4. (The other change with JNLP4 is that it uses NIO whereas JNLP3 dropped the NIO support)
      


      If you remove JNLP3 from the list of supported protocols then it should fall back to JNLP2 if I recall the code correctly

    So the JNLP4 protocol is implemented already. I am just awaiting approval to release the code. As it uses TLS rather than a home grown cipher system this should not be an issue for JNLP4. (The other change with JNLP4 is that it uses NIO whereas JNLP3 dropped the NIO support)

    If you remove JNLP3 from the list of supported protocols then it should fall back to JNLP2 if I recall the code correctly

  5. jenkins-infra-bot commented on May 10, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 10, 2016
    Author
    nyoung02:
    • Original comment link
    • Raw content of original comment: 
      I have a system I can try it on so I'm happy to give it a try and see as a workaround - but how do I remove JNLP3 from the list of supported protocols?!

    I have a system I can try it on so I'm happy to give it a try and see as a workaround - but how do I remove JNLP3 from the list of supported protocols?!

  6. jenkins-infra-bot commented on May 10, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 10, 2016
    Author
    danielbeck:
    • Original comment link
    • Raw content of original comment: 
      

      java -Djenkins.slaves.JnlpSlaveAgentProtocol3.enabled=false -jar jenkins.war
      

      

       should do it.
      

    java -Djenkins.slaves.JnlpSlaveAgentProtocol3.enabled=false -jar jenkins.war

    should do it.

  7. jenkins-infra-bot commented on May 10, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 10, 2016
    Author
    nyoung02:
    • Original comment link
    • Raw content of original comment: 
      I started Jenkins using that property, all started ok. This appeared in the console output for the master when I tried to connect a slave:
      



      

      WARNING: Connection #1 failed
java.io.EOFException
        at java.io.DataInputStream.readUnsignedShort(Unknown Source)
        at java.io.DataInputStream.readUTF(Unknown Source)
        at java.io.DataInputStream.readUTF(Unknown Source)
        at hudson.TcpSlaveAgentListener$ConnectionHandler.run(TcpSlaveAgentListe
ner.java:175)

      

      

      And the slave still fails to connect:
      

      

      May 10, 2016 9:41:11 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP3-connect
May 10, 2016 9:41:12 AM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: Failed to create handshake ciphers
java.lang.AssertionError: Failed to create handshake ciphers
        at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCipher
s.java:116)
        at org.jenkinsci.remoting.engine.JnlpProtocol3.performHandshake(JnlpProt
ocol3.java:138)
        at org.jenkinsci.remoting.engine.JnlpProtocol.establishChannel(JnlpProto
col.java:77)
        at hudson.remoting.Engine.run(Engine.java:308)
Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supp
orting AES/CTR/PKCS5Padding
        at javax.crypto.Cipher.getInstance(Unknown Source)
        at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCipher
s.java:109)
        ... 3 more
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10
126Padding or NoPadding
        at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
        at javax.crypto.Cipher$a_.a(Unknown Source)
        ... 5 more

      

      

      So it looks like the slave is still trying to connect with JNLP3. I tried passing the same property to the slave.jar in case the intention was to use it there, with no effect.

    I started Jenkins using that property, all started ok. This appeared in the console output for the master when I tried to connect a slave:

    WARNING: Connection #1 failed
java.io.EOFException
at java.io.DataInputStream.readUnsignedShort(Unknown Source)
at java.io.DataInputStream.readUTF(Unknown Source)
at java.io.DataInputStream.readUTF(Unknown Source)
at hudson.TcpSlaveAgentListener$ConnectionHandler.run(TcpSlaveAgentListe
ner.java:175)

    And the slave still fails to connect:

    May 10, 2016 9:41:11 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Trying protocol: JNLP3-connect
May 10, 2016 9:41:12 AM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: Failed to create handshake ciphers
java.lang.AssertionError: Failed to create handshake ciphers
at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCipher
s.java:116)
at org.jenkinsci.remoting.engine.JnlpProtocol3.performHandshake(JnlpProt
ocol3.java:138)
at org.jenkinsci.remoting.engine.JnlpProtocol.establishChannel(JnlpProto
col.java:77)
at hudson.remoting.Engine.run(Engine.java:308)
Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supp
orting AES/CTR/PKCS5Padding
at javax.crypto.Cipher.getInstance(Unknown Source)
at org.jenkinsci.remoting.engine.HandshakeCiphers.create(HandshakeCipher
s.java:109)
... 3 more
Caused by: javax.crypto.NoSuchPaddingException: CTR mode must be used with ISO10
126Padding or NoPadding
at com.ibm.crypto.provider.AESCipher.engineSetPadding(Unknown Source)
at javax.crypto.Cipher$a_.a(Unknown Source)
... 5 more

    So it looks like the slave is still trying to connect with JNLP3. I tried passing the same property to the slave.jar in case the intention was to use it there, with no effect.

  8. jenkins-infra-bot commented on May 10, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 10, 2016
    Author
    stephenconnolly:

    Yeah looks like there is no way to disable the client protocol: https://github.com/jenkinsci/remoting/blob/master/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocolFactory.java#L54

    So just use an older slave.jar as that will not try JNLP3 at all.

    I will be fixing that code up to allow control of the individual protocols when I merge by JNLP4 protocol

  9. jenkins-infra-bot commented on May 10, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 10, 2016
    Author
    stephenconnolly:
    • Original comment link
    • Raw content of original comment: 
      (by fixing up I mean refactoring into something else)

    (by fixing up I mean refactoring into something else)

  10. jenkins-infra-bot commented on May 12, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 12, 2016
    Author
    scm_issue_link:
    • Original comment link
    • Raw content of original comment: 
      Code changed in jenkins
User: Stephen Connolly
Path:
 src/main/java/hudson/remoting/Engine.java
 src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol.java
http://jenkins-ci.org/commit/remoting/04037ec8ee633109c557d8f5f35922f2e2f495fc
Log:
  [Related to JENKINS-34121] Allow disabling the protocols individually
      


        
	
      • Also ensure that a fatal unexpected error in one protocol does not prevent a fall-back
        •

    Code changed in jenkins
    User: Stephen Connolly
    Path:
    src/main/java/hudson/remoting/Engine.java
    src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol.java
    http://jenkins-ci.org/commit/remoting/04037ec8ee633109c557d8f5f35922f2e2f495fc
    Log:
    [Related to JENKINS-34121] Allow disabling the protocols individually

    • Also ensure that a fatal unexpected error in one protocol does not prevent a fall-back

  11. jenkins-infra-bot commented on May 12, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 12, 2016
    Author
    scm_issue_link:
    • Original comment link
    • Raw content of original comment: 
      Code changed in jenkins
User: Stephen Connolly
Path:
 src/main/java/hudson/remoting/Engine.java
 src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol.java
http://jenkins-ci.org/commit/remoting/43793e5b46f223c57f0a7b137cd983903fd63446
Log:
  [Related to JENKINS-34121] Allow disabling the protocols individually (#83)
      


        
	
      • Also ensure that a fatal unexpected error in one protocol does not prevent a fall-back
        •

    Code changed in jenkins
    User: Stephen Connolly
    Path:
    src/main/java/hudson/remoting/Engine.java
    src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol.java
    http://jenkins-ci.org/commit/remoting/43793e5b46f223c57f0a7b137cd983903fd63446
    Log:
    [Related to JENKINS-34121] Allow disabling the protocols individually (#83)

    • Also ensure that a fatal unexpected error in one protocol does not prevent a fall-back

  12. jenkins-infra-bot commented on May 13, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 13, 2016
    Author
    oleg_nenashev:
    • Original comment link
    • Raw content of original comment: 
      Workaround - Disable JNLP3 protocol.
This workaround has been implemented by Stephen and released as remoting 2.59.
Should become available in the next weekly, may be a subject for backporting into the next LTS release (1.651.3)

    Workaround - Disable JNLP3 protocol.
    This workaround has been implemented by Stephen and released as remoting 2.59.
    Should become available in the next weekly, may be a subject for backporting into the next LTS release (1.651.3)

  13. jenkins-infra-bot commented on May 14, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 14, 2016
    Author
    scm_issue_link:

    Code changed in jenkins
    User: Oleg Nenashev
    Path:
    pom.xml
    http://jenkins-ci.org/commit/jenkins/409438f36dc80f20964fb16f8d88041e11ba4ed4
    Log:
    [JENKINS-19445, JENKINS-34213, JENKINS-34808, JENKINS-34121] Bump remoting to 2.59. (#2344)

    Changes:

  14. jenkins-infra-bot commented on May 25, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 25, 2016
    Author
    scm_issue_link:

    Code changed in jenkins
    User: Oleg Nenashev
    Path:
    pom.xml
    http://jenkins-ci.org/commit/jenkins/12e79963cca5122351943ee107f65c3ad91a2e25
    Log:
    [JENKINS-19445, JENKINS-34213, JENKINS-34808, JENKINS-34121] Bump remoting to 2.59. (#2344)

    Changes:

    (cherry picked from commit 409438f36dc80f20964fb16f8d88041e11ba4ed4)

  15. jenkins-infra-bot commented on May 25, 2016

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 25, 2016
    Author
    olivergondza:
    • Original comment link
    • Raw content of original comment: 
      The workaround will be available in 1.651.3 LTS.

    The workaround will be available in 1.651.3 LTS.

  16. jenkins-infra-bot commented on Mar 7, 2017

    @jenkins-infra-bot
    jenkins-infra-bot
    on Mar 7, 2017
    Author
    scm_issue_link:

    Code changed in jenkins
    User: Oleg Nenashev
    Path:
    docs/protocols.md
    src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol3Handler.java
    http://jenkins-ci.org/commit/remoting/fe2587b7f9d78334e0ab05ab0b95f39b4b600a25
    Log:
    Docs - Noting JENKINS-37302, JENKINS-33886, and JENKINS-34121 in Errata

  17. jenkins-infra-bot commented on Mar 7, 2017

    @jenkins-infra-bot
    jenkins-infra-bot
    on Mar 7, 2017
    Author
    scm_issue_link:

    Code changed in jenkins
    User: Oleg Nenashev
    Path:
    docs/protocols.md
    src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol3Handler.java
    http://jenkins-ci.org/commit/remoting/86e13055079fd679a46b06fc7ce54ea1eb33ac1f
    Log:
    Merge pull request #155 from oleg-nenashev/doc/jnlp3_errata

    [Docs] - Noting JENKINS-37302, JENKINS-33886, and JENKINS-34121 in JNLP3 Errata

    Compare: b8f10d8...86e1305

  18. jenkins-infra-bot commented on Mar 7, 2017

    @jenkins-infra-bot
    jenkins-infra-bot
    on Mar 7, 2017
    Author
    oleg_nenashev:
    • Original comment link
    • Raw content of original comment: 
      Closing as "Won't fix", upgrade to JNLP4 is the recommended solution.
      


      If somebody wants to fix it, please feel free to reopen it and to create a pull request

    Closing as "Won't fix", upgrade to JNLP4 is the recommended solution.

    If somebody wants to fix it, please feel free to reopen it and to create a pull request

  19. jenkins-infra-bot
    closed this as completedon Mar 7, 2017

  20. jenkins-infra-bot commented on Mar 23, 2017

    @jenkins-infra-bot
    jenkins-infra-bot
    on Mar 23, 2017
    Author
    srimanoj_kandala:
    • Original comment link
    • Raw content of original comment: 
      Can someone please provide instructions to upgrade to JNLP4 ?
      


      We prefer to use IBM JRE.

    Can someone please provide instructions to upgrade to JNLP4 ?

    We prefer to use IBM JRE.

  21. jenkins-infra-bot commented on Mar 23, 2017

    @jenkins-infra-bot
    jenkins-infra-bot
    on Mar 23, 2017
    Author
    oleg_nenashev:
    • Original comment link
    • Raw content of original comment: 
      srimanoj_kandala
      


      1) Upgrade to Jenkins 2.32.1 or above
2) Go to the Global Security Configuration in Manage Jenkins
3) Ensure that JNLP4 is allowed in protocol security settings

    srimanoj_kandala

    1) Upgrade to Jenkins 2.32.1 or above
    2) Go to the Global Security Configuration in Manage Jenkins
    3) Ensure that JNLP4 is allowed in protocol security settings

  22. jenkins-infra-bot
    added
    bugFor changelog: Fixes a bug.
    imported-jira-issue
    component:remoting
    priority:major
    on Nov 25, 2025

  23. jenkins-infra-bot commented on Nov 25, 2025

    @jenkins-infra-bot
    jenkins-infra-bot
    on Nov 25, 2025
    Author

    [Original relates_to from Jira: JENKINS-34819]

  24. jenkins-infra-bot
    added
    resolution:wont-fix
    and removed
    bugFor changelog: Fixes a bug.
    on Nov 25, 2025
  25. jenkins-infra-bot
    added the
    Bug
    issue type on Nov 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    component:remotingimported-jira-issuepriority:majorresolution:wont-fix

    Type

    Bug

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions