There is a REST API in Blue Ocean that could be repurposed for something like this if someone is keen.
On Tuesday, December 13, 2016 at 9:14:14 PM UTC+11, Robert Collins wrote: > > On 13 December 2016 at 17:03, Daniel Beck <[email protected] <javascript:>> > wrote: > > Hi everyone, > > > > We've now had not one, but two unauthenticated remote code execution > vulnerabilities in Jenkins: > > > > - SECURITY-218 in > https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-11-11 > > > - SECURITY-360 in > https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-11-16 > > > > > Clearly, the current state of the CLI is a problem. Its Java > serialization based protocol without prior authentication has now > repeatedly resulted in remote code execution. For something like Jenkins, > keeper of all the secrets, this is just unacceptable. > > > > For now, we have a new system property that allows administrators to > disable all of the CLI. I don't think this is good enough, but it's all we > had time to do for SECURITY-360. > > https://jenkins.io/doc/upgrade-guide/2.19/#disabling-the-cli > > > > So, what are we going to do with the CLI? Remove it altogether? Only > allow access via SSHD? Only allow authenticated use? Don't use remoting? > Limit CLI remoting to specific users? WDYT? > > > > Daniel > > Writing the CLI purely in terms of the REST API would be good - > security wise you then have a single path to secure, and no vulns > unique to the CLI; obviously some work is entailed :P. > > -Rob > -- 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/ff9dd158-7f22-422e-80b4-3853022f97df%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
