| I understand that from the security model's perspective you provide an option here. While that is correct, I think there two valid considerations to mention explicitly with regards to the original request both revolving around the changing role of Jenkins in CI as integration with external systems becomes stronger and more automated checks happen. The first is that with Jenkinsfiles and builds as code, we, as users, are largely shifting the security control over the build process away from Jenkins to our SCM solutions (ex. GitHub). When we build out processes and protections in that system to protect the Jenkinsfile and allow automated reporting of the build status control other workflows (since we trust the Jenkinsfile). It can be alarming to discover that the SCM controls can completely be bypassed with the "Replay" feature on Jenkins which trivially let peoples people bypass all those checks since it allows edits. Needing block all access to job configuration options to disable this "problematic" feature really sounds like a lot of administrative hassle making exceptions for when people really do need to just configure a job, I think this could be a good reason to make it a separate security option. The next is really an appeal to consider the many users that are likely operating in a more security context. I am sure I'm not alone in using Jenkins in a relatively controlled corporate environment, everyone who has access to it is a "trusted" member of the team. Many in such an environment would generally not consider it worth the cost to fully harden the CI system. If we can make it easy to do the "right" we are not likely to have any issues; so long as it is working most users don't care enough to put in the effort to realize where the risks are. The users that do realize the risk are not likely to be motivated to put in the effort to exploit them, and those that would want to exploit something (we really shouldn't have any of these) are likely the ones that would be really hard to stop. Where this re-play with edits feature comes it is that it makes a "dangerous" option so easy that the first class of users that just want to use the system are likely to use it without realizing it is problematic, thus like the original request, it would be nice if we could just blanket disable this on a box. From pure information security standpoint, if that is the only model you are considering, I understand that is horrible and there are all sorts of flaws. When you consider the social environment and things like the cost of security vs convenience, being able to disable this particular enhancement would be valuable. |
