3 ms·
I think the next step is creating a PR to another, higher profile package introducing a problematic dependency among other changes. It existing on its own doesn
by vasco 4y ago
I think the next step is creating a PR to another, higher profile package introducing a problematic dependency among other changes. It existing on its own doesn't prove intention of doing that, but it enables it. If I were doing this I'd start by creating an actually useful package and then later change it's behavior, but same principle.
If you were just trying to get people to install it directly you'd go for name collisions / typos / namesquatting in your package name instead.
- vorticalbox 4y agoThe trick is to change the package-lock. What you do it fork a popular package that the project uses and make some changes. Then update the package-lock so that it points to your GitHub fork. This file is normally ignored in PR due to the amount of line changes in there so you can have quite a bit of fun.
- leipert 4y agoWe‘ve been writing a tool to check lock files against the registry: https://www.npmjs.com/package/@gitlab/untamper-my-lockfile https://www.npmjs.com/package/@gitlab/untamper-my-lockfile For now it only supports yarn, but npm support shouldn’t be too hard.
- louislang 4y agoThis is really cool work, glad to see someone tackling this! Can I assume this will get rolled out into gitlab natively?
- leipert 4y agoActually good point, will talk to the respective PMs next week. Mainly been using it in CI in order to protect our own projects (thus yarn only for now)