Not "instead", it's "in addition to". Your classical defense-in-depth.

No, "instead". If they compromise bubblewrap to send out your files, and you run bubblewrap anyway for any reason, you're still compromised.

But obviously you can probably safely pin bubblewrap to a given version, and you don't need to "install packages through it", which is the main weakness of package managers

▲

ChocolateGod 5 days ago | parent | next [-]

Bubblewrap uses the same Linux functions that billion dollar cloud infrastructure use. Bubblewrap does no sandboxing/restrictions itself, it's instructing the kernel to do it.

▲

aragilar 5 days ago | parent | prev [-]

How? bubblewrap isn't something someone has randomly uploaded to npm, it has well known maintainers and a well organised release process (including package signing). Which is easier to do: upload a package to npm and get people to use it, or spend 2+ years trying to become a maintainer of bubblewrap or one of its dependencies to compromise it.

▲

oulipo2 5 days ago | parent [-]

Sure, but there's plenty of packages with well-known maintainers who get compromised...

	▲	haswell 5 days ago \| parent [-]
		The fact that something can happen is separate from how likely that thing is to happen, and that’s what matters here. The comments here that point to this theoretical possibility seem to be missing the point, which is that using something like bubblewrap is an improvement over running arbitrary projects un-sandboxed, and the likelihood of such an attack is far less than the likelihood of any one of hundreds of rapidly evolving, lesser known, lesser scrutinized projects getting compromised.