And that commercially supported version does not currently contain hashes because it serves the content directly and checks the hash behind the scene... though we will be adding hashes shortly ;-)
On 30 July 2012 11:00, Nord, James <[email protected]> wrote: > the json that I retrieved from my commercially supported version > contained zero hashes, the JSON I have just pulled from retrieved from the > default update site (http://updates.jenkins-ci.org/update-center.json) did > contain hashes.**** > > ** ** > > So not a Jenkins issue (sorry for causing any confusion on the list)**** > > ** ** > > Regards,**** > > ** ** > > /James**** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Stephen Connolly > *Sent:* 30 July 2012 10:06 > > *To:* [email protected] > *Subject:* Re: Verify downloaded jpi-files**** > > ** ** > > The update metadata includes the signature of the metadata as well as the > sha1 sums of all the downloads, so that gives plenty of security.... though > I agree somebody could use that injection trick to create a plugin with a > matching sha1 to the sha1 in the metadata... but I suspect that it would be > a lot of effort... and keep in mind that if it is a popular plugin that > will get updated more frequently so the effort will be wasted... and the > non-popular plugins will be less likely to get uptake**** > > On 30 July 2012 09:50, Nord, James <[email protected]> wrote:**** > > > > -----Original Message----- > > From: [email protected] [mailto:jenkinsci- > > [email protected]] On Behalf Of Jesse Glick > > Sent: 27 July 2012 21:34 > > To: [email protected] > > Subject: Re: Verify downloaded jpi-files > > > > On 07/27/2012 08:58 AM, Fredrik Orderud wrote: > > > a simpler check against the in-built JAR/ZIP-file CRC-32 checksum > > > would probably be good enough in most situations > > > > Even simpler: check if the file starts with 0x50 0x4b 0x03 0x04, the ZIP > magic. If > > not, it is some junk like an error page which should be treated like a > 404 or > > other connection error. > > > > File a bug or open a pull request; > > hudson.model.UpdateCenter.UpdateCenterConfiguration.postValidate could > > easily do this, I think.**** > > Isn’t this a security issue - I thought the update.json was signed to make > it hard to prevent installing malicious components (but this just prevents > the main Jenkins site update from being forged - which is no protection at > all) > As it stands you don’t need to do anything complex just some dns hijacking > of a mirror (or attack a mirror, or be an evil mirror) and then you can > just replace whatever hpi you want (pick a popular one like git or svn) > then you can serve up any arbitrary code that gets executed? > > I guess the update.json needs to include the signatures of components as > well for this to work (with 3rd party update sites). > > To be honest I thought I recalled a discussion that this was already done > :-( > > /James > > ________________________________ > > > > ************************************************************************************** > This message is confidential and intended only for the addressee. If you > have received this message in error, please immediately notify the > [email protected] and delete it from your system as well as any copies. > The content of e-mails as well as traffic data may be monitored by NDS for > employment and security purposes. To protect the environment please do not > print this e-mail unless necessary. > > NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 > 4EX, United Kingdom. A company registered in England and Wales. Registered > no. 3080780. VAT no. GB 603 8808 40-00 > > ************************************************************************************** > **** > > ** ** >
