Added the proposal sign-off to the today's Governance meeting agenda.
The pull requests are up and running: 
https://github.com/jenkinsci/jenkins/pull/2950

BR, Oleg

пятница, 28 июля 2017 г., 14:59:53 UTC+2 пользователь Baptiste Mathus 
написал:
>
> Having seen recently a customer simply switch from JNLP2 to JNLP4 and get 
> their instance back to working, after they had disabled JNLP4 after some 
> mistake I'm +1 to help drive users more towards the "right"/recommended 
> version.
>
> 2017-07-28 10:02 GMT+02:00 Stephen Connolly <[email protected] 
> <javascript:>>:
>
>> +1
>>
>> On Fri 28 Jul 2017 at 08:53, 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] <javascript:>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> Sent from my phone
>>
>> -- 
>> 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] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw-mrET-X9xO4Y2B%3Dy2MfQ%3DyduKedp9wLiFL-Xk_eKYjQ%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw-mrET-X9xO4Y2B%3Dy2MfQ%3DyduKedp9wLiFL-Xk_eKYjQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/601824cd-7a04-4d8c-8194-10f0db590926%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to