3 ms·
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 t
by 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 agoUh, 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 agoIt'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