REST, REST, REST, REST. Toss the CLI. Don't worry about a replacement. Don't just bolt onto the existing REST api. Design a modern restful interface. If you do that we can all make a client work with it.
Please and thank you! On Monday, December 12, 2016 at 8:04:02 PM UTC-8, Daniel Beck 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 > > -- 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/a8ac9fc8-3b0c-4f13-88b4-c54df5b111ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
