On Mon, Dec 12, 2016 at 11:03 PM, Daniel Beck <[email protected]> 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. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2N0xAg%3D0XA1dCAoy%2Br9qcEFnLn2tGxedCXTLN_NOEaEA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
