Removing CLI over Remoting

[Jesse Glick]

As of JENKINS-41745, merged in Jenkins 2.54 more than a year and a
half ago, the Remoting transport for the Jenkins CLI has been
deprecated as inherently hard to secure and just plain unwise. As far
as I know, all important CLI commands have long since removed any
dependency on this mode, or offered an alternative mode. The UI warns
you if you enable it. Is it time to finally remove this code?

I bring this up now because of Java 11 work:

https://github.com/jenkinsci/jenkins/pull/3759

made the physical layout of Jenkins core more complex, just in order
to maintain some exploit tests which were really only interesting in
CLI over Remoting, and not even that interesting anyway after JEP-200.
(Deserialization attacks via agents could still be launched, but
again, that would be much harder after JEP-200.)

I propose this `jenkins-test-jdk8` module and its three test suites
and ysoserial library be deleted, whether or not CLI over Remoting is
also removed, so that we can remove `jenkins-test-parent` and go back
to having only `jenkins-test`.

[Jeff Thompson]

+1

I support this proposal. We’ve seen another case recently of a problem with this antiquated mode. We have had to adjust tests to continue supporting it.

I don’t think there is enough value in continuing to support it, particularly with the costs to keep coaxing it along.

Jeff Thompson

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3RN-dRrPFXW%2Bn1S9V8VXDPRqxQL02t0NHcVyqwEq1n3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Waite]

+1 from me as well.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/78DB206D-FBA7-4F95-8AE8-AFC5280800CF%40cloudbees.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks!

Mark Waite

[Oleg Nenashev]

Hi,

I am not against removing CLI over Remoting. Or maybe it makes sense to move it to a plugin (without adding it as a detached plugin). But I do not quite get the need to simplify the component structure. It is just a matter of time till we hit another Java-specific test classes & Co. E.g. we may need to create Java11-only tests, or to add tests relying on modules detached from Java 11. I prefer to keep the code ready to such requirements, so revering test-parent would be a step backward IMO

BR, Oleg

[Jesse Glick]

On Sun, Jan 6, 2019 at 12:32 PM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> maybe it makes sense to move [Remoting-based CLI] to a plugin

Not possible I am afraid. It either needs to be baked into core and
supported, or deleted.

> It is just a matter of time till we hit another Java-specific test class

There is no indication that we will. The only Java 8-specific tests
are those which use ysoserial, which deliberately compiles against
internal JRE classes to simulate deserialization exploits.

> we may need to create Java11-only tests

I would hope that if we start having lots of Java 11-specific code, we
should simply decide to drop support for 8 already. In the past when
we needed on occasion to (for example) test some 7+ API when the repo
as a whole depended only on 6, we used reflection with a TODO comment
to clean it up when requiring the newer Java level.

> add tests relying on modules detached from Java 11

I am not sure what this means, could you elaborate?

> I prefer to keep the code ready to such requirements

My preference was to keep the source structure as simple as possible
and make it more complex only if and when there is a demonstrated need
that cannot be solved in a simpler way. If that ever happens, we have
Git history to serve as a working example.

Any third opinions?

[Jeff Thompson]

It’s not exactly a third opinion because I agree with Jesse. Jenkins build and test structures are already complicated enough. I would hope to not increase that complexity with a clear, demonstrated need.

Jeff Thompson

> --
> 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 jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3Jh6udHP2z1ndpKNjrRB8qzSgwgQDuC1yTczNvMXjWiA%40mail.gmail.com.

[Jesse Glick]

Since the response was mostly positive, I filed

https://github.com/jenkinsci/jenkins/pull/3838

[Baptiste Mathus]

I understand your point Oleg, but I feel quite strongly that we shouldn't keep the new test-jdk8 module empty or so for a "just in case" reason.

1) In case we ever need it again, we can very easily then revert the removal using Git, and reintroduce this module when needed.

2) in the meantime, it would be deeply misleading for everyone, and mainly newcomers that there is an empty maven module in the source tree.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/28e65655-9fa5-4e51-894a-a45bce6f5a71%40googlegroups.com.

[Oleg Nenashev]

We resolved the concern about the project structure in the PR.

• https://github.com/jenkinsci/jenkins/pull/3838 has been reviewed, and I consider it as ready-to-go according to the feedback
• There is a draft announcement blogpost by Jesse: https://github.com/jenkins-infra/jenkins.io/pull/2096

If anybody disagrees with removing the feature in Jenkins 2.165 (and hence in June LTS baseline), please respond by Thursday 5PM UTC

Best regards,

Oleg