Ignore security advisories

[annv99]

Composer 2.7+ blocks packages with known security advisories by default, causing composer install to fail.

• PKSA-z3gr-8qht-p93v
• PKSA-rkkf-636k-qjb3
• PKSA-wws7-mr54-jsny

Added composer config --json audit.ignore before installation in all three entrypoint scripts to suppress these advisories

This affects Magento versions 2.4.5 and 2.4.6.

[fredden]

@sprankhub and @convenient, I'm now getting the same issue with PKSA-db8d-773v-rd1n example. Would you like me to add this to the list of ignored problems, or turn the whole audit feature off with "block-insecure": false docs?

[sprankhub]

@fredden, for me, it would also be fine ignoring insecure packages completely, but @convenient had good reasons for not doing it - maybe he can elaborate on this :)

[convenient]

Will post my thoughts and a draft PR for discussion this morning to see if we can find a way that works well for everyone in every case

[convenient]

FYI @fredden I have spotted on your repository that you are fighting with elasticsearch booting for integration tests, see #144 (comment) for workaround.

I am in two minds about the handling of block-insecure and audit.ignore in this set of github actions. I would very much like for this set of actions to "just work" and not have to think too hard about anything and just get verification that my code is correct, but I believe that is ignoring the landscape we're living in. It seems every month or so I read about a new CI pipeline hack that occurs because tokens or something is leaked by pulling in a third party dependency

On closed source repositories where I run integration tests I also attach environment variables for GitHub tokens or third parties etc, they're always locked down and only for test envs, but turning it off entirely would relax the security profile a bit much. For actual deployed environments we have a lockfile and private packagist which helps, but in these test cases we dont have a lockfile and the only thing covering our backs is this very reasonable composer security handling.

It may be a bit pedantic, but to me it feels like outright turning off security functionality that has our back is not the right step given that this is a reasonably commonly exploited attack vector.

That said, the team at packagist/composer built this functionality with the ability to turn it off so as to give us the necessary level of flexibility. Maybe we should follow suit and expose those same defaults and configurations here? See POC #153 I am aware that this starts adding a bit of extra complexity to the implementation of these actions, but the web is always a moving target and what was simple years ago may need workarounds now. It's a complex thing keeping many versions of software installed over a rolling 4 year window, especially when the technology that you're building on is moving along as well.

Happy to hear all thoughts, this is just my opinion on the matter and I personally don't like throwing out good security tooling when its built in 😄 but I may just be being daft