On Mon, Dec 12, 2016 at 11:03 PM, Daniel Beck <
m...@beckweb.net> wrote:
> Only allow authenticated use?
Well the problems in these cases related to vulnerabilities in the
Remoting layer preceding the check for authentication. We could
probably make this safer by using a whitelist during the
authentication phase, and then later switch to the current blacklist
after we have confirmed user identity. The design problem at the root
of JENKINS-12543 may make this trickier to do for username/password
authentication.
> Don't use remoting?
This would be my preferred approach. The Remoting protocol has some
obvious power—you can do special operations on the client side—but it
seems inherently hard to secure. The performance is also poor—every
command has heavy startup overhead.
In practice most commands (or selectable command modes) can run just
fine using a simple protocol that only allows arguments, nonstreaming
stdin, and possibly streaming stdout/stderr. You can already use SSH
protocol, but to make things easier for both users and administrators
I would advocate an HTTP(S)-based protocol, normally authenticated
using API tokens just like Jenkins’ current “REST” APIs. Most commands
would be usable using a generic client like `wget`/`curl`, though we
could also provide a custom client, built perhaps in Go, which would
offer a similar interface to the current `java -jar jenkins-cli.jar`
and `ssh` styles. Commands like `build -v` would just need to hold
open an HTTP response, which is less of an issue if we can assume
Servlet 3.x. There would be no need for a special port, and standard
proxies or even SSO systems would work transparently.
Alternately we could just deprecate the whole CLI (ideally via
JENKINS-26463) and make sure that every command (or command mode) has
a complete replacement using existing REST endpoints. Most already do,
but not all. Again we would have the option of building a custom
client to make it easier to invoke the most commonly needed commands
(`build`, etc.), though there is no good way to make it extensible by
plugins in that case: you would need to hard-code command names and
options in the client, since it would need to map them to URL patterns
and form/data submission protocols. From a plugin developer standpoint
this would be the better option since you only need to understand and
think about one kind of non-GUI interaction with your features,
whereas currently you need to at least consider providing two.