I think the article also has no clue what’s going on . From what I’m guessing, anonymous users might be able to run the stop environment job, which would be ba

I think the article also has no clue what’s going on . From what I’m guessing, anonymous users might be able to run the stop environment job, which would be bad. Not sure how that chains into a supply chain attack or any of that fun stuff. here’s the link for what changed updating to the 17.1.7: https://gitlab.com/gitlab-org/gitlab/-/compare/v17.1.6-ee...v17.1.7-ee?from_project_id=278964&straight=false https://gitlab.com/gitlab-org/gitlab/-/compare/v17.1.6-ee...... The merge commit with calling out environment stop actions: https://gitlab.com/gitlab-org/gitlab/-/commit/e2ceeac5ffc6a6d5fc881a20ed170cc14cf97359 https://gitlab.com/gitlab-org/gitlab/-/commit/e2ceeac5ffc6a6... The meat of the change is probably this chunk: https://gitlab.com/gitlab-org/gitlab/-/commit/e2ceeac5ffc6a6d5fc881a20ed170cc14cf97359#c2c98c66fb555cb7654ce999fc0787b2a9ce9958_15_12 https://gitlab.com/gitlab-org/gitlab/-/commit/e2ceeac5ffc6a6... my take on it is that if gitlab doesn’t know who you are, it looks to the last runner of the job (or maybe the creator) to run stop environment. The fix seems to use the current user to attempt the stop environment which seems simple enough.