Features/9618 stronger plugin verification

[bertagaz]

We at Tails use this puppet module to manage our Jenkins.

We're not at ease with the idea of installing on our infra plugins that are downloaded over an insecure connection, without any verification.

This branch proposes two changes:

• use HTTPS wherever possible, even if it doesn't help much with the mirrors
• by using the camptocamp-archive puppet module to download the plugin, one can specify its hash and this way add a bit of verification.

We're running it on our infra, and so far plugins are installed as we wish, so it works and hopefully this branch is in a good shape enough to be merged.

[jenkinsadmin]

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

[bertagaz]

This should make #164 unnecessary by the way, and will probably not conflict with #335

The puppet-archive module uses curl, but has no support for its --noproxy option, so I'm not sure how it fits with #306

[rtyler]

This look great to me.

There is some signing and checks that will happen with the update center already but this is a welcome change.

[jhoblitt]

@rtyler This module is now using wget directly, nanliu/staging, and camptocamp/archive. nanilu/staging is "puppetlabs approved" but nanilu/archive is intended to be its official replacement. It would be nice to be a bit more consistent about how files are retrieved. Do you have any preferences?

[rtyler]

@jhoblitt I do not have strong opinions one way or the other. I figured since @bertagaz did such a big amount of work here that we could refactor after the merge instead of blocking the PR based on that.

If @nanliu's archive module is in a decent shape, let's just pull that in and call it the standard way we should be dealing with these archives

[jhoblitt]

@rtyler I agree; wasn't worth blocking the merge -- just noting that we're fetching files a lot of different ways.

I also agree that nanliu/archive appears the most attractive option since it uses native providers. I've only used it once before though. I'll try to kick the tires later this week and come up with a proposal.

[rtyler]

@jhoblitt Sounds great, do you want me to hold off on the 1.5 release until then? Otherwise I can probably wrap up a release this week

[jhoblitt]

@nanliu Do you feel that archive module is getting close to api stability? (ie., a 1.0.0 release)

[jhoblitt]

@rtyler How about if I don't get a PR posted for comments later tonight, it waits for the next release cycle?

[rtyler]

👍

[nanliu]

@jhoblitt you are using a different archive module from camptocamp. I've migrated mine to puppet-community. There isn't a forge release under puppet-community yet.

[jhoblitt]

@nanliu I am aware, we're actually using two different modules and an exec of wget. The idea is to coverage down to a single module. I'd like to use nanliu/archive [or whatever its name ends up being] but I'm a bit concerned about breaking API changes. Eg., voxpupuli/puppet-archive#62

[nanliu]

@jhoblitt oh I see, I think 0.4.0 is the last major change before 1.0 (I'm hoping no breaking changes). I definitely need to spend some cycles to get it out the door.

[dannyviti]

Just read the updated ReadMe - where it lists updated dependencies, sorry for not starting there, I'll report back if that doesn't work.

We are getting errors when trying to build new Jenkins nodes as of yesterday afternoon, they appear to be related to this change. The error is "Invalid resource type archive::download at /etc/puppet/modules/jenkins/manifests/plugin.pp:171"
Do I need to explicitly include the archive module or am I just missing something else?
Thanks for your help and let me know if I should ask somewhere else.
Danny

[jhoblitt]

@rtyler / @bertagaz I've opened PR #340 as an RFC to discuss the best solution going forward.