Re: [JEP-200 Discussion] - Switch Remoting/XStream blacklist to a whitelist

Heads up, JEP-200 has been accepted. I am going to proceed with the current roll-out plan which targets delivery in weekly in 2.102 (next weekly) unless there is no major issues discovered. My current plans: - Jan 9 morning, EU TZ - Get Remoting 3.16 and all packaging (Docker/Swarm)

Re: [JEP-200 Discussion] - Switch Remoting/XStream blacklist to a whitelist

We have discussed the single whitelist concern with Jesse and agreed that there is no immediate need to implement it as a part of this JEP. The testing concern has been also addressed last week, all recommended and other popular plugins have been tested by ATH/PCT. There was no other feedback

Re: [JEP-200 Discussion] - Switch Remoting/XStream blacklist to a whitelist

> > They sound unrelated to security and are best addressed, if required, by > plugin developers on their own initiative. > Let's park this question for now. I am going to play with the current PR state, and then I will provide a response around Jan 02. My IMHO is that it would be preferable

Re: [JEP-200 Discussion] - Switch Remoting/XStream blacklist to a whitelist

On Thu, Dec 21, 2017 at 1:38 PM, Oleg Nenashev wrote: > The main purpose of whitelisting for Remoting is to allow particular > communications between agent and master by saying the class is secure to be > sent. Received. And/or loaded from XML files. > For example, Jesse

Re: [JEP-200 Discussion] - Switch Remoting/XStream blacklist to a whitelist

While we are doing the JEP review in the pull requests, I would also want to start one topic here. The current JEP-200 design shares the whitelist between Remoting and XStream, and I am a bit aware of that. The main purpose of whitelisting for Remoting is to allow particular communications

[JEP-200 Discussion] - Switch Remoting/XStream blacklist to a whitelist

Hi all, I am starting this thread in order to collect extra feedback about JEP-200, which proposes switching Remoting/XStream implementations from a blacklist to a whitelist. The intention is to significantly reduce risks of class deserialization attacks, which was hitting Jenkins project