2-day-old GitHub account added AI-generated dependency to Mailgen (2.5k stars)
1–4 of 4 posts
Re: 2-day-old GitHub account added AI-generated dependency to Mailgen (2.5k stars)
#2Not blaming any maintainer here - I also received a similar PR (https://github.com/foray1010/didyoumean2/pull/1849 same author, 1 hour before mailgen) but did not merge it.
The concern isn’t obvious malicious code in the PR itself, but how cheap it has become to generate a credible replacement library. Once accepted, it becomes part of the trusted supply chain and can be evolved later. Previously this kind of attack required real engineering effort, AI reduces that cost dramatically.
Re: 2-day-old GitHub account added AI-generated dependency to Mailgen (2.5k stars)
#3Not blaming any maintainer here - I also received a similar PR ( https://github.com/foray1010/didyoumean2/pull/1849 same author, 1 hour before mailgen) but did not merge it. The concern isn’t obvious malicious code in the PR itself, but how cheap it has become to generate a credible replacement library. Once accepted, it becomes part of the trusted supply chain and can be evolved later. Previously this kind of attack…
While everything said here is true, I find that in JavaScript world depending on a package that was last changed 8 years ago, complete as it may be, is asking for trouble. For your case, I couldn't find the link to the package the account was changing, so I can't tell how big of a risk keeping the previous dependency is.
Re: 2-day-old GitHub account added AI-generated dependency to Mailgen (2.5k stars)
#4Not blaming any maintainer here - I also received a similar PR ( https://github.com/foray1010/didyoumean2/pull/1849 same author, 1 hour before mailgen) but did not merge it. The concern isn’t obvious malicious code in the PR itself, but how cheap it has become to generate a credible replacement library. Once accepted, it becomes part of the trusted supply chain and can be evolved later. Previously this kind of attack…
While everything said here is true, I find that in JavaScript world depending on a package that was last changed 8 years ago, complete as it may be, is asking for trouble. For your case, I couldn't find the link to the package the account was changing, so I can't tell how big of a risk keeping the previous dependency is.
JavaScript ecosystems often end up with small, feature-complete dependencies where "if it ain't broke, don't fix it" is a reasonable stance, so staleness alone isn't necessarily a risk.
The link in the PR is incorrect, the referenced package by nicolo-ribaudo doesn't exist. The correct repository is https://github.com/ka-weihe/fastest-levenshtein