About "Stop trusting mutable references" article.

[vhemery]

This discussion continues one in the mailing lists. Only it's not spamming everyone.

Following up on my earlier message, I have just published a blog post that expands on these recommendations and outlines concrete steps projects can take to reduce the risk of similar supply-chain breaches in the future:

https://mikael.barbero.tech/blog/post/2026-03-24-stop-trusting-mutable-references/

If you would like help implementing any of these recommendations, the Eclipse Foundation Security Team is available to support you. You can reach us by email at security@eclipse-foundation.org, or start a discussion in the Eclipse CSI GitHub organization: https://github.com/orgs/eclipse-csi/discussions

Kind regards,

On behalf of the Eclipse Foundation Security Team,
Mikaël Barbero — Head of Security

Hi

This guidance would appear to be very important, yet I understand very little of it. I have no idea what a GitHub Action is, let alone how to pin it.

On the one hand, the guidance references a number of projects that I am not aware of using and in some cases had not even heard of.

On the other hand, a couple of days ago I was struggling with string interpolation in a Jenkinsfile and came across some security 'do not's that I didn't really understand and put off till 'tomorrow'.

I have a test Jenkins job that takes a possibly arbitrary jenkinsfile argument. Is that a security hole? Probably not since surely only my co-project-committers have execute access?

My OOMPH setups reference tags. Is that a security hole? OOMPH setups can be displaced by a user-defined overwrite so can perhaps do clever things. Is that a security hole?

Bottom line. I would like to comply with best security practice, but when you send out guidance that is unintelligible, you encourage even willing respondents to ignore the hassle.

(The continued need to 'trust selected' to install Eclipse with even the most modest add-ons, even those using OOMPH, further re-inforces this dangerous ignore security attitude.)

Regards

Edward Willink

Hello,

Regarding Ed's comments, if you do not know what a github action, you are are just not the targeted audience. (just think of it as Gihub's own CI mechanism, like Jenkinsfiles are to Jenkins)

This blog post addresses a specific kind of issue, in a specific context, and gives useful tools on how to address it. I was already pinning with shas by hand, but did not know about many tools mentioned in this article. So I'd say it does reach its objectives, as far as I am concerned.

Yet, other points Ed mentions are worth taking a look by the security team. Unfortunately, although the security team can give broad advice that they have already repeated many times, they can not address all issues contexts at once.

To Ed, I do not doubt they might release later an article about how to strenghen your Oomph setup or your Jenkins job, which you will find highly usefull and enlightening.

So I would like to express my thanks to the security team and the job they realize, and formally (yet still respectfully) disagree with Ed's statement.
Keep up the good work.