pip throws your dependencies in some lib directory either on your system (default if you use sudo), in your home directory (default if you don't use sudo), or inside your virtualenv's lib directory. npm pulls dependencies into node_modules as a subdirectory of your own project as default. Python really should consider doing something similar. Dependencies shouldn't live outside your project folder. We are no longer i…
Have you seen how much space a virtualenv uses? It can easily be >1 GB. For every project, this adds up. (Not to mention the bandwidth, which is not always plentiful).
Well, npm uses a cache so it won't re-download every package every time you install it.
> I'd try to keep the permission sets as small and simple as possible though. You've described OpenBSD in general. I recommend a deeper dive - it's fantastically refreshing, how simple yet functional an OS can be.
Same for FreeBSD. Incredibly code-stable and well-documented by Linux standards. I often use the FreeBSD Handbook as an example of first-party documentation done right, and that's only possible because of deliberately limited "churn for churn's sake". The kinds of regular code rot and attrition that Linux suffers just does not take place on BSD systems because if you contribute something new you're expected to make y…
What attracted me to Linux so long ago is what ultimately drove me away. I now apply it only as needed because it's no longer simple ("stable" over the timescales I'm interested in) as a project, and it's not moving towards any type of consistency.
If you read "rolling stones gather no moss" to mean "keep moving or risk becoming obsolete", choose Linux. If you understand it as "change for change's sake prevents the achievement of mastery", go with a BSD.
I think @jart has been porting it to Linux https://justine.lol/pledge/ .
Indeed! If your dependencies are able to be command line programs that are shell scripted together, then you can in fact have an access policy on a per-dependency basis, using the pledge.com program linked on my website. So shell scripters rejoice. But it gets better. If you build Python in the Cosmopolitan Libc repository: git clone https://github.com/jart/cosmopolitan cd cosmopolitan build/bootstrap/make.com -j8 o/…
I thought the thread model of pledge/unveil was to restrict a program that you are writing, but that you couldn't wrap around other program in a safe way.
That is, you can protect your own program from doing network stuff because of incorrect input, but you can't use it to sandbox another program.
Readme says: https://marketplace.visualstudio.com/items?itemName=ms-vscod... > A compromised remote could use the VS Code Remote connection to execute code on your local machine. So I would say that it might be a bit harder for an attacker to gain access to your local machine, but you should not rely on it, because it's more like security by obscurity.
Well damn. I was under the impression that the communication channel uses/accepts only well defined VSCode specific messages related to the UI...
Darn. Maybe the solution is to use vs-code client in the browser? Like vscode.dev or https://github.com/coder/code-server ? It limits what keyboard shortcuts and extensions are available, but at least it's in a secure sandbox on the client side.
I started to develop only inside VMs, with a full Desktop, IDE, browser etc. inside the virtual machine. There have been to many contaminations of major package repos lately. Only one typo in an import statement up the dependency chain and you’d be compromised.
Packj sandbox [1] offers "safe installation" of PyPI/NPM/Rubygems packages. 1. https://github.com/ossillate-inc/packj/blob/main/packj/sandb... It DOES NOT require a VM/Container; uses strace. It shows you a preview of file system changes that installation will make and can also block arbitrary network communication during installation (uses an allow-list). Disclaimer: I've been building Packj for over a year now.
Only secures installation, not runtime, but still helpful. I'm not a package maintainer, but I do wish that packages were not allowed to run any code at install-time.
I wonder why we can’t have pip packages be published by username or organization, like pip install google/tensorflow It would significantly reduce the attack space
npm does something similar with their scoped packages. It fixes the problem for the top level packages, but you'd still have to contend with the transitive dependencies written by smaller organizations or individual contributors. In this case, you have to guarantee that no one involved in the dependency chain ever typos anything.
"you'd still have to contend with the transitive dependencies written by smaller organizations or individual contributors" - generally these are the higher risk dependencies anyway and should probably be used with extra caution anyway.
Indeed! If your dependencies are able to be command line programs that are shell scripted together, then you can in fact have an access policy on a per-dependency basis, using the pledge.com program linked on my website. So shell scripters rejoice. But it gets better. If you build Python in the Cosmopolitan Libc repository: git clone https://github.com/jart/cosmopolitan cd cosmopolitan build/bootstrap/make.com -j8 o/…
I thought the thread model of pledge/unveil was to restrict a program that you are writing, but that you couldn't wrap around other program in a safe way. That is, you can protect your own program from doing network stuff because of incorrect input, but you can't use it to sandbox another program. See this thread: https://marc.info/?t=162367803300003&r=1&w=2 and this mail about sandboxing: https://marc.info/?l=openbs…
You can, if you use pledge() and unveil() on Linux. SECCOMP and Landlock use a monotonically decreasing permissions model. It's inherited across exec(). This is a good thing. OpenBSD devs don't need it because they built their own hermetic system. They're more afraid of having their servers compromised remotely than they are of programs they've installed locally. The tradeoff is you can't use pledge() and unveil() to build your own SSH server on Linux, since SSH needs to shed restrictions when launching a shell. But the benefit is you can safely leverage more code written by strangers on the Internet, which is what Linux is all about.
I don't see how having dynamic imports matters if all you want to do is detect if a specific file is imported. Run the install and see what gets imported. That's it.
If you actually have to execute a program (but have no safe way of doing so), to see if a complex routine that may return any filename imports a safe file or not, then you are facing up against https://en.wikipedia.org/wiki/Rice%27s_theorem
So? Any method of detecting a "malicious package" faces Rice's theorem, unless you want to claim that "malicious" is a trivial property.