Action "Auto-Update Linters" is failing

[muffl0n]

Describe the bug
Action "Auto-Update Linters" is failing with error

fatal: could not read Username for 'https://github.com/': No such device or address
Error: The process '/usr/bin/git' failed with exit code 128

https://github.com/oxsecurity/megalinter/actions/runs/9391727233/job/25864531487#step:11:37

I'm desperately waiting for a new release of Megalinter to include version 3.1.0 of v8r which includes proxy support. See: chris48s/v8r#442

Maybe the used token is expired? peter-evans/create-pull-request#2863

[echoix]

@nvuillam Can you check that the tokens aren't expired? I see the last three runs failing for the same error, and I don't see a reason why.

[nvuillam]

PAT regenerated and env vars updated :)

[muffl0n]

Thank you very much! #3606 was just updated. 😻

[echoix]

If you want to help out to get that PR unblocked, you may want to investigate the trivy vulnerabilities that came out this week, if there's something in our control to do

[muffl0n]

I'd be happy to!

I already took a look at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-29415 and the corresponding issue indutny/node-ip#150. But that seems to be a dead end cause the project is unmaintained.

Gonna take a deeper look at it tomorrow.

[muffl0n]

Just saw, @nvuillam already took care of that one. Thanks! 💗

[nvuillam]

:)

[echoix]

Just saw, @nvuillam already took care of that one. Thanks! 💗

Saw it just after finishing writing. But it was the blocker for the week.

[muffl0n]

ip@2.0.0 is transitively pulled in by make-fetch-happen

├─┬ make-fetch-happen@13.0.0
│ ├─┬ @npmcli/agent@2.2.0
│ │ ├─┬ agent-base@7.1.0
│ │ │ └── debug@4.3.4 deduped
│ │ ├─┬ http-proxy-agent@7.0.0
│ │ │ ├── agent-base@7.1.0 deduped
│ │ │ └── debug@4.3.4 deduped
│ │ ├─┬ https-proxy-agent@7.0.2
│ │ │ ├── agent-base@7.1.0 deduped
│ │ │ └── debug@4.3.4 deduped
│ │ ├── lru-cache@10.1.0 deduped
│ │ └─┬ socks-proxy-agent@8.0.2
│ │   ├── agent-base@7.1.0 deduped
│ │   ├── debug@4.3.4 deduped
│ │   └─┬ socks@2.7.1
│ │     ├── ip@2.0.0

The newest version of socks switched from ip to ip-addressin JoshGlazebrook/socks#94 but proxy-agent did not pick up the new version yet: TooTallNate/proxy-agents#295

[echoix]

So does it mean something else needs to be done, or it's ok now?

[muffl0n]

As there's nothing that can be done from our side, we can just go ahead. 👍

[echoix]

But your wish would be what package(s) at which versions?

[echoix]

Are the packages solved differently in a flavor that has less installed packages?

[muffl0n]

That's not a question that is easy to answer. ip@2.0.0 is vulnerable, but so is ip@2.0.1. There is no version of ip that has no active CVE. That's the reason why socks uses ip-address now: JoshGlazebrook/socks#94

As we're using make-fetch-happen which uses an old version of socks (transitively) we have no chance of solving this cleanly. Despite the possibility to ditch make-fetch-happen but I have no idea why this is installed and where it's used.

Seems like we have to wait for TooTallNate/proxy-agents#297 and dependent PRs in socks-proxy-agent, @npmcli/agent and make-fetch-happen.

I'm sorry that I can't be any more helpful cause I'm quite new to the node ecosystem and to Megalinter.

[muffl0n]

Maybe we can override to use socks@2.7.3 instead of socks@2.7.1 even though it's defined in a dependency down the graph?
Still not sure if that's a good idea. 😄

[echoix]

Is ip-address really better since it doesn't have CVEs found yet, or ip has real problems?

Also, yes, it's possible to apply some overrides in dependency resolution for cases like this, where some fixes are available but not applied in the dependent package yet. The thing here is to know when to remove it. We would be trying to be smarter than the resolver.

https://medium.com/microsoftazure/how-to-fix-your-security-vulnerabilities-with-npm-override-c4b5be0ab4f6

[muffl0n]

ip-address is actively maintained while ip is not. That's the most important difference, imho. Besides: ip-address has no open CVEs at the moment.

[echoix]

If you could find how to add an override, while we don't really have a package.json when creating the image, we could include it in main (and the release if it stays there until then) until needed. I have not problems with that.

[muffl0n]

I created #3623 to handle this. Imho we should move on with the release.