Remoting-based CLI removed from Jenkins
Close to two years ago, we announced in
New, safer CLI in 2.54
that the traditional “Remoting” operation mode of the Jenkins command-line interface
was being deprecated for a variety of reasons, especially its very poor security record.
Today in Jenkins 2.165 support for this mode is finally being removed altogether,
in both the server and bundled
The projected June 5th LTS release will reflect this removal,
at which point the Jenkins project will no longer maintain this feature
nor investigate security vulnerabilities in it.
This change makes the code in Jenkins core related to the CLI considerably simpler and more maintainable.
(There are still two transports—HTTP(S) and SSH—but they have similar capabilities and behavior.)
It also reduces the “attack surface” the Jenkins security team must consider.
Among other issues, a compromised server could freely attack a developer’s laptop if
-remoting were used.
2.46.x upgrade guide
already urged administrators to disable Remoting mode on the server.
Those Jenkins users who rely on the CLI for remote scripting (as opposed to the HTTP(S) REST APIs)
would be affected only if they were still using the
-remoting CLI flag,
since the default has long been to use HTTP(S) mode.
Most CLI features have long worked fine without
in some cases using slightly different syntax such as requiring shell redirects to access local files.
As part of this change, some CLI commands, options, and option types in Jenkins core have been removed, other than
logoutcommands, and the
-poption to select a proxy. (The CLI in default
-httpmode accesses Jenkins no differently than any other HTTP client.)
set-build-resultcommands relied on a fundamentally insecure idiom that is no longer supportable.
Command options or arguments which took either a local file or
=for standard input/output (e.g.,
support) now only accept the latter.
Some features of relatively little-used plugins will no longer work, such as: