4

I am running a Jenkins 2.67 on a Red Hat 7 inside a corporate network. It can only access internet over a forward proxy restricting requests to HTTPS URLs only.

By default Jenkins downloads the plugins list from http://updates.jenkins-ci.org/ as update-center.json file. I could access the HTTPS version but the list of plugins downloaded is the same and contains about 50% of HTTP only URLs.

This brings me to 3 questions:

  1. Is it possible to have HTTPS URLs only? According to INFRA-110 feature request it is not.
  2. If point 1 is not possible, how can I verify that the downloaded plugin is not corrupted?
  3. How can I verify that the downloaded plugin does not contain any threat?

Edit

Also posted on Stack Overflow where it suites maybe better

U880D
  • 1,017
  • 2
  • 12
  • 18
Antoine Wils
  • 156
  • 4
  • Make a simple diif between **HTTP**://updates.jenkins-ci.org/update- center.json and **HTTPS**://updates.jenkins-ci.org/update-center.json output no difference. How do you know there is less plugin in https? – Joao Vitorino Aug 21 '17 at 21:02
  • 1
    I understand that my sentence is confusing. I mean that in the downloaded list of plugins urls, if you grep and count on http:// you find a lot of them. There is unfortunately no difference in the downloaded list over http or https – Antoine Wils Aug 21 '17 at 21:06
  • OP edited to clarify accordingly – Antoine Wils Aug 21 '17 at 21:09
  • @gf_ I looks like it is a [no go from Jenkins's team](https://issues.jenkins-ci.org/browse/JENKINS-46428?focusedCommentId=311696&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-311696) for the improvement request. I believe that the open source community should find a way to build a trust around healthy resources including Jenkins plugins – Antoine Wils Aug 25 '17 at 08:42
  • Yes, I've read the thread. They're still using SHA1... I wouldn't trust this anymore, and there is a reason this is deprecated (and gives warnings) since some time for HTTPS certificates in browsers. But well...their decision. You've to decide for yourself, if Jenkins is the right tool for your environment, alternatives do exist. (I've deleted my answer, as it doesn't apply, which I've learned just now.) – gxx Aug 25 '17 at 11:08
  • @gf_ indeed, I am disappointed that Jenkins as a major CI provider does not put more efforts to secure their resources – Antoine Wils Aug 25 '17 at 11:11
  • Building secure systems is not really a top priority for many people, it just costs money. Also, regarding the checksums of the plugins: Without using Jenkins, so I could be wrong on that: I've just had a quick plugin on the most popular plugins. Most of them are developed at GitHub, "releases" are unsigned git tags. I'm not sure how the Jenkins people pull the code (which they checksum), but if they pull the tags, they can't be sure anyway that they're pulling what the plugin developers pushed. – gxx Aug 25 '17 at 11:17
  • 2
    Re: "I believe that the open source community should find a way to build a trust around healthy resources including Jenkins plugins": AFAIK, Jenkins plugins aren't covered, but besides, there is the [reproducible builds initiative](https://reproducible-builds.org/). Luckily, more and more organisations and projects are joining; recently, the Debian policy was [regarding](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844431) this. It might become a release goal for the next release "buster". – gxx Aug 25 '17 at 11:39
  • @gf_ that is an interesting project supported by some interesting software projects. Thank you for the information – Antoine Wils Aug 25 '17 at 12:02

0 Answers0