Remoting-based CLI removed from Jenkins

Published on 2/17/2019 by Jesse Glick

    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 jenkins-cli.jar client. 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.

    The 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 -remoting, 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 -remoting itself:

    • The login and logout commands, and the --username and --password options.

    • The -p option to select a proxy. (The CLI in default -http mode accesses Jenkins no differently than any other HTTP client.)

    • The install-tool, set-build-parameter, and set-build-result commands 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., install-plugin, build -p, support) now only accept the latter.

    • Some features of relatively little-used plugins will no longer work, such as:

    About the Author
    Jesse Glick
    		Jesse Glick

    Jesse has been developing Jenkins core and plugins for years. He is the coauthor with Kohsuke of the core infrastructure of the Pipeline system.