>Except when it's a license violation or in something that ends up having a security vulnerability.

What's more secure isn't so simple. If you vendor something with a vulnerability then it wont be patched. But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities. And it can cut the other way - you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks).

There is a balance that must be struck, and I think LLM's strike a better balance than people do. Dependencies are a convenience with a cost and LLM's can trivially copy or re-implement things that we cant.

▲

packetlost 3 hours ago | parent [-]

> But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities

If you aren't using a library function you're not vulnerable to exploits in that code: unused but imported code is inert (possible usable as a gadget if you're vulnerable elsewhere, but at that point you're screwed anyways) and most compilers/runtimes completely eliminate it.

> you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks)

There are better mitigations to this than not using a library.

You still completely ignore the license violations.

	▲	kragen 42 minutes ago \| parent \| next [-]
		You might be exposing it to attackers without intending to use it.
	▲	nonethewiser 22 minutes ago \| parent \| prev [-]
		>You still completely ignore the license violations. The ones that you are imagining to happen? Its not a problem because you could simply observe proper licensing. >If you aren't using a library function you're not vulnerable to exploits in that code Not true, just because you arent calling a function doesnt mean it cant run. Read up on Log4Shell.