4 ms·

"however, they made one of the most comedic mistakes you can still make while setting up jenkins (im actually not sure which misconfiguration leads to this): th

by dmbche 3y ago

"however, they made one of the most comedic mistakes you can still make while setting up jenkins (im actually not sure which misconfiguration leads to this): the build information for each past build contains a link to the git repository, including the bitbucket credentials in the url. genius."

bheadmaster 3y ago
The most horrible thing Jenkins does to devs is it encourages bad practice. Good practice is so cumbersome to do properly (create a secret, load secret in env through Groovy code, setup git configuration in a shell script) that, unless someone is actively monitoring them, devs are always in a temptation to just put the credentials in the git URL, we'll remove them after testing. Then one out of N times they forget and you get a security hole.
- ilyt 3y ago
  Uh, no, you just pick credentials from list in the repo config. If you wanted to download additional repo in the jenkins script sure, but Jenkins Git plugin just accepts credential (whether its password or pub/priv key pair), just paste URL and select one from the list
  - phendrenad2 3y ago
    It's 2023, it's far past the time that open-source projects should be made without security being the #1 concern, even above the basic functionality of the app. But Jenkins has been around since 2011, so it's understandable that the security posture is obtuse and tacked-on. It's time for some other CI project to surpass Jenkins. I won't be sorry to see it go. Security should be front and center, the first thing the user sees. The defaults should be secure out of the box, and if the user does something stupid, it should be painfully clear to everyone, even the least technical user who looks at it, that something is wrong. That said, I doubt that what happened here was a Jenkins configuration problem, and instead something to do with the build scripts they're running on Jenkins. You can't solve every class of stupid, sadly.
- onionisafruit 3y ago
  “one out of N times” where N is < 2
deng 3y ago
No, the most comedic mistake is to have a public-facing Jenkins running. I mean in general you wouldn't make your CI accessible from the outside, but especially not Jenkins. That software has probably more CVEs every year than all of our other tooling combined.
- supermatt 3y ago
  Given the frequency with which I seem to update nokogiri on a rails instance, i assumed libxml2 would hold that award: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libxml2 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libxml2 But sure enough, jenkins FAR outweighs it: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jenkins https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jenkins
  - deng 3y ago
    And that's just the ones that get reported. Since core Jenkins is pretty bare-bones, most instances also have many plugins installed, and most of those aren't properly reviewed at all.
    - jorams 3y ago
      The vast majority of those Jenkins CVEs seem to be for a wide variety of plugins, so it seems someone is putting in quite a bit of work to review them.
      - deng 3y ago
        Yes, to give credit, they do monitor the most important ones which almost everybody uses and which are usually also maintained by developers from Cloudbees. But there are over 1800 plugins for Jenkins, so at least quantitatively, most of them are not monitored.
- JackSlateur 3y ago
  The most comedic mistake is to have a running jenking in 2023
deleted 3y ago
[deleted]

by dmbche 3y ago

bheadmaster 3y ago

The most horrible thing Jenkins does to devs is it encourages bad practice. Good practice is so cumbersome to do properly (create a secret, load secret in env through Groovy code, setup git configuration in a shell script) that, unless someone is actively monitoring them, devs are always in a temptation to just put the credentials in the git URL, we'll remove them after testing. Then one out of N times they forget and you get a security hole.

ilyt 3y ago
Uh, no, you just pick credentials from list in the repo config. If you wanted to download additional repo in the jenkins script sure, but Jenkins Git plugin just accepts credential (whether its password or pub/priv key pair), just paste URL and select one from the list
- phendrenad2 3y ago
  It's 2023, it's far past the time that open-source projects should be made without security being the #1 concern, even above the basic functionality of the app. But Jenkins has been around since 2011, so it's understandable that the security posture is obtuse and tacked-on. It's time for some other CI project to surpass Jenkins. I won't be sorry to see it go. Security should be front and center, the first thing the user sees. The defaults should be secure out of the box, and if the user does something stupid, it should be painfully clear to everyone, even the least technical user who looks at it, that something is wrong. That said, I doubt that what happened here was a Jenkins configuration problem, and instead something to do with the build scripts they're running on Jenkins. You can't solve every class of stupid, sadly.
onionisafruit 3y ago
“one out of N times” where N is < 2

deng 3y ago

No, the most comedic mistake is to have a public-facing Jenkins running. I mean in general you wouldn't make your CI accessible from the outside, but especially not Jenkins. That software has probably more CVEs every year than all of our other tooling combined.

supermatt 3y ago
Given the frequency with which I seem to update nokogiri on a rails instance, i assumed libxml2 would hold that award: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libxml2 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libxml2 But sure enough, jenkins FAR outweighs it: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jenkins https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jenkins
- deng 3y ago
  And that's just the ones that get reported. Since core Jenkins is pretty bare-bones, most instances also have many plugins installed, and most of those aren't properly reviewed at all.
  - jorams 3y ago
    The vast majority of those Jenkins CVEs seem to be for a wide variety of plugins, so it seems someone is putting in quite a bit of work to review them.
    - deng 3y ago
      Yes, to give credit, they do monitor the most important ones which almost everybody uses and which are usually also maintained by developers from Cloudbees. But there are over 1800 plugins for Jenkins, so at least quantitatively, most of them are not monitored.
JackSlateur 3y ago
The most comedic mistake is to have a running jenking in 2023

deleted 3y ago

[deleted]