> > I would personally propose removing the options of having them enabled at > all. Though, if they can be disabled by default I guess that's a > compromise I'd be willing to accept. >
- Protocols are already disabled by default on new installations (since 2.75) - There is a PR from Vincent Latombe which disables them on old installations as well (with opt-in option): https://github.com/jenkinsci/jenkins/pull/3188 . Not ready for merge, needs some minor fixes There is a related story about detaching Remoting protocol handlers to plugins (JENKINS-44100 <https://issues.jenkins-ci.org/browse/JENKINS-44100> and PR #2875 <https://github.com/jenkinsci/jenkins/pull/2875>). Obsolete protocols could be detached to a separate plugin if it helps to move this story forward. BTW, it just needs a here who has time for it. Unfortunately, I don't. BR, Oleg On Sunday, April 29, 2018 at 9:46:01 AM UTC+2, Sam Gleske wrote: > > I agree with this sentiment. As one who has argued for a decently secured > agent to master protocol for years I think by even leaving an option to > have them configured is just yet another checkbox in which a user can make > a mistake. I've tried clarifying their function in the help text > https://github.com/jenkinsci/jenkins/pull/2682 ; however, every company I > join seems to have the worst configurations enabled. Even companies where > Jenkins is secured with HTTPS it comes as a surprise to the owners that the > protocols they selected have no bearing on the security of the web UI > frontend. > > I would personally propose removing the options of having them enabled at > all. Though, if they can be disabled by default I guess that's a > compromise I'd be willing to accept. Still think it would be better to > remove them, though. If a user truly needs to have them enabled than we > can provide a way to have them enabled via JVM properties. Not very user > friendly, but then again if a user wants to lower the integrity of the > security of their installation we shouldn't make it easy or user friendly > (but still provide it as an option for those daring enough to do it). > > On Fri, Jul 28, 2017 at 12:53 AM, Oleg Nenashev <[email protected] > <javascript:>> wrote: > >> 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/fb81f9b1-a996-4bdb-820a-4c163c84f91a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
