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) rele
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
>
> 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
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 added several JGit class
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 betw
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 serio