Nope. You can sign your own update center too. The code for signing the UC is open source.
The issue is that for the signing to have meaning you need to have the cert trusted. There are a number of ways to get the cert trusted. You can drop the cert into a special directory in $JENKINS_HOME (I cannot recall exactly which, but it can be found on the jenkins wiki) There is a set of certs that ships in OSS jenkins. These are tied to the OSS update center. There is a set of certs that CloudBees use to generate our update center ( jenkins-updates.cloudbees.com) those certs are installed by our plugins (in the exact same way anyone else can install certs) Here is an example of how we verify that the metadata from our update center comes from our update center: https://github.com/jenkinsci/cloudbees-plugin-gateway/blob/master/src/main/java/com/cloudbees/jenkins/plugins/freeplugins/CloudBeesUpdateSite.java#L250 If you want to issue your own update site, you can use that code but bundle your own cert. Signing is not about vendor lock in... in fact I gave out to KK for introducing the signing as it was a right pain for me when he introduced it and I had to rewrite a chunk of our update center under the clock before a release ;-) Look at the code and you will see that metadata signing is all above board and actually driven by the community and not CloudBees.... though we do support it. -Stephen On 20 August 2012 23:33, cforce <cfo...@gmx.de> wrote: > I nkew it all the time. This useless signing is just a business case to > sell some extra plugin. > JUst remove that signing code and allow opensoucing everything. Just use a > plain old maven repo and get plugins via dependecy resolution. > Noone wants cloudbees vendor lock in to plugins update site generation. > > > 2012/8/17 Stephen Connolly <stephen.alan.conno...@gmail.com> > >> [shameless plug] >> http://docs.apps.cloudbees.com/docs/user-guide-bundle/ch14.html >> >> note that link will be changing to >> >> http://docs.apps.cloudbees.com/docs/user-guide-bundle/uc.html >> >> CloudBees have an UpdateCenter plugin that allows Jenkins to serve it's >> own UpdateCenter and allows easy configuring of that update center from >> other Jenkins instances (i.e. it provides a plugin that you can download >> and install into the jenkins instances that installs the required trust >> certs for signed update center metadata) >> [/shameless plug] >> >> On 17 August 2012 12:02, Hui Shen <hihuis...@gmail.com> wrote: >> >>> Hi Guys, I meet the same issue. >>> >>> Then how can I generate an update-center.json JSON file that can be >>> interpreded by Jenkins. >>> >>> We do have several plugins which will be used only inner our group, we >>> do not like to deliver them to jenkins group. >>> As a solution, I think we should put the plugins somewhere, and update >>> the update-center.json to point out these plugin, but jenkins always report >>> a signature or digest error. >>> So my question is can any people head me how to write an >>> update-center.json file that can be interpeded by jenkins. >>> Thanks very much. >>> >>> >>> >>> 在 2011年10月13日星期四UTC+8上午1时52分40秒，grayaii写道： >>>> >>>> We have a few Jenkins masters behind a firewall that I need to manage, >>>> and I >>>> would like to know if it's possible to create our own Update Center >>>> within >>>> our firewall. This will allow us to regulate all the plugins and >>>> Jenkins >>>> updates for all our Jenkin masters. >>>> >>>> Is there a way to do this? I took a look at "simpleupdatesite" plugin, >>>> but >>>> the instructions are extremely vague. Is there a way to create a custom >>>> Jenkins Update Center, and if so, how? >>>> >>>> Thanks! >>>> >>>> -- >>>> View this message in context: http://jenkins.361315.n4.** >>>> nabble.com/Alternate-Update-**Center-tp3898939p3898939.html<http://jenkins.361315.n4.nabble.com/Alternate-Update-Center-tp3898939p3898939.html> >>>> Sent from the Jenkins users mailing list archive at Nabble.com. >>>> >>>> >> >
