Hi all,

It is almost one year since the release of JNLP4 protocol in Remoting 3.0. 
This protocol is available in Jenkins LTS since 2.32.1, and so far it 
demonstrates good stability being compared to JNLP2 and especially to 
JNLP3. The protocol was enabled by default in 2.46.x, and we do not have 
confirmed JNLP4 issues since that.

I propose to disable the previous protocols. I have created JENKINS-45841 
<https://issues.jenkins-ci.org/browse/JENKINS-45841> for it.


*Why?*
   
   - JNLP2 stability concerns
      - There are known issues in JNLP2 connection management. The engine 
      is complex and barely diagnosable
      - Examples: 
         - https://github.com/jenkinsci/remoting/pull/156 
         - JENKINS-31735 
         <https://issues.jenkins-ci.org/browse/JENKINS-31735> - 
         NioChannelHub thread dies sometimes
         - JENKINS-24155 
         <https://issues.jenkins-ci.org/browse/JENKINS-24155> - Slaves 
         going offline in NIO mode
      - In many cases update to JNLP4 was a resolution
   - JNLP1/JNLP2/CLI1 are known to be unencrypted
      - Sam Gleske also made it explicit in UI, Jenkins 2.41+ (pull request 
      <https://github.com/jenkinsci/jenkins/pull/2682>)
      - It is not a security issue, they have been never claimed to be 
      encrypted
      - Jenkins CERT team agreed that disabling protocols is reasonable 
      from the security hardening standpoint
      
*How?*
   
   - UPD: When installation wizard is enabled && it runs in the new 
   installation mode, disable the old protocols during the instance 
   initialization
      - It is similar to what we do for Remoting CLI disabling and the 
      default security initialization in Jenkins 2.0
      - ADD: administrative monitor, which warns about obsolete Remoting 
   protocols and points to the errata documents (like this one)
   - ADD: Explicit deprecation notice to the built-in HTML documentation

*Compatibility concerns*
   
   - Old instances won't be affected, protocols will be still enabled for 
   them
   - "New" Jenkins instances installed via setup wizard may be affected in 
   age cases. Examples:
      - Agents with Remoting older than 3.0 will be unable to connect. 
      - One may bundle old Remoting in his custom Docker images, AMIs, etc.
         - Swarm Plugin 
      <https://wiki.jenkins.io/display/JENKINS/Swarm+Plugin>: old versions 
      of Swarm Client (before 3.3) will be unable to connect, because Remoting 
      2.x is bundled
      - **Very** old jenkins-cli.jar without CLI2 support will be unable to 
      connect
   
*Not affected:*
   
   - Newly installed instances created from scratch
   - Instances using the "-Djenkins.install.runSetupWizard=false" flag (all 
   configuration-as-code instances)
   - SSH Slaves Plugin, any newly installed agent type, community-provided 
   Docker packages for agents, etc.

*Announcement*

   - It's a potentially breaking change, hence it should be announced in 
   blog posts
   - The change and the corner cases should be addressed in the upgrade 
   guide, which should be published within the blogpost
   


*I think it's a good time to finally do this change. WDYT?Thanks in 
advance,Oleg Nenashev*

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to