This argument strikes me as massively disingenuous. The central problem of the US tax system is caused by a combination of:
- high net wealth individuals essentially being indifferent to income tax.
- income tax and short term capital gains are taxed at much higher rates to long term capital gains.
- lower net wealth folks (ie. the general public) receiving most of their income as income.
- high and ultra high net wealth individuals now making most of their money through dynastic trusts and inheritance.
This combination ends up making it so that, as Warren Buffet would put it, he ends up paying a lower effective tax rate than his secretary.
I effectively don't really care if it's a wealth tax or some other more targeted technical fix, but it's not sustainable to have the very wealthiest individuals taxed at a lower effective tax rate than everyone else and also able to pass on their wealth directly to heirs without significant estate taxes.
I'm far from an expert, but this feels like an oversimplification.
Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control.
Native Ruby Gems execute arbitrary code via extconf.rb.
Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorporated into your build (and so can run code at build time).
PHP Composer packages can ship install scripts or configure themselves as Composer plugins.
The venerable .tar.gz approach to packaging, covering decades of C and C++ code, is all about executing code during installation.
There are measures that can help (e.g., PHP Composer doesn't run install scripts of _transitive_ dependencies) but the JS space is adopting measures that can help too (like pnpm's approve-builds).
But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages.
> PHP Composer packages can ship install scripts
Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "composer -n config allow-plugins.foo/bar true && composer -n require foo/bar"
> The venerable .tar.gz approach to packaging
Which most people don't install directly, but have already had built for them by their distro.
As more and more languages get "package managers", there's an expectation that installing what should just be inert package/library code should not run commands. Sometimes generated files are needed, and the direction seems to be that these package managers should be like distro package managers, where they take the risk of running the build instructions and generate those files for you, serving up os/architecture-specific builds.
This is the direction npm ought to take, and furthermore shouldn't allow things like electron being a small bundle of javascript code that fetches large lumps of binary code from somewhere else on the internet to install. It should all be uploaded to, and sourced from, NPM.
> But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages.
Yes, and these are positive changes. But they aren't security boundaries, and they don't mean that pip won't execute arbitrary code: a malicious update could ship an update with sdist instead of wheels, a malicious pyproject.toml could provide an arbitrary-code `build-backend`, etc., and pip would still function as designed.
I appreciate the clarifications/corrections on PHP.
> Which most people don't install directly, but have already had built for them by their distro.
Yes, but the original claim was that npm is "particularly susceptible to these attacks" because "npm can execute code after install and most package managers don't do that." I don't think that's accurate: we've seen hundreds of NPM packages compromised in multiple high-profile attacks over the last several months, while .tar.gz was used for decades with nowhere near the same number of compromises.
Rather, I suspect it's a combination of factors: Early JS had a relatively anemic standard library in the early days, and NPM made code reuse dramatically simpler than before. This normalized the use of large and deep dependency trees among JS projects. And the extreme popularity of JS, the centralization of NPM + GitHub, and increased usage of automation makes attacks more practical and more lucrative.
Taking a step back from that particular debate, I'm very much in favor of changes like what you describe.
Taking still another step back, I'm not sure that even those will be enough. If I download a package, it's because I intend to run its code at some point: if it's malicious, I may be less automatically hosed than if its postinstall script runs, but I'm still hosed at execution time. I trust my distro packages, not because they don't execute arbitrary code on installation (RPMs and .debs both do), but because I _trust my distro_. NPM et al. simply cannot vouch for every package they host.
> Early JS had a relatively anemic standard library in the early days, and NPM made code reuse dramatically simpler than before. This normalized the use of large and deep dependency trees among JS projects.
This always seems like a very convenient excuse. C also have a very small standard library. And unless you're doing system programming, you often have to find utility library. It's just that those libraries tries to solve their domain instead of splitting themselves into molecules. Before npm, we had good js libraries too like jQuery as a fundamental one, backbone.js, dropzone.js,... where you import a few files (and vendor them in your project) and be done with it.
The issue with NPM is that it led to the creation of weird ecosystem like babel, webpack, eslint,... where instead of having a good enough solution, it was plugins ad infinitum. And other maintainers started doing the same thing, splitting their libraries, and writing libraries where a gist or a blog post would be enough[0]. Cargo is suffering the same[1]
Couldn't you accomplish the same thing by adding a malicious [build-system] to a pyproject.toml file? You can pull in arbitrary code by providing exact URLs for requirements:
That's a very visible Ken Thompson style attack. The modern expectation is that PyPI would be evaluating this build-system section and would only accept build-systems that they trust to turn package distributions into wheels, and the end users only need the wheels. If you need a specific version of hatchling that they know of, that's fine. If you need something they haven't heard of, they should say no.
> most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages
Technically true, but wheels can include a `.pth` which will run arbitrary code as soon as Python is started, which is only marginally less dangerous. Recently exploited in the LiteLLM attack.
That appears to be an exploitable feature of the language, not the package manager per se.
We could then add the philosophical question of asking what's the difference between:
1. Adding malicious code to a package's .pth file that's evaluated automatically on every python invocation
2. Adding malicious code to the package itself that's evaluated automatically on every python invocation _that uses that package_
Packaging systems that don't run arbitrary code when you install a package are more trustworthy than ones that do, but there's still the essential trust you have to place in all code you're installing, directly and indirectly.
/me looks at the `build.rs` file in my Rust's project's `Cargo.toml` and laughs nervously...
(For non Rustaceans: "Placing a file named build.rs in the root of a package will cause Cargo to compile that script and execute it just before building the package.")
aaand many Cargo packages do use it, right now. It became an inseparable part of Rust ecosystem. You cannot build any embedded program or something slightly complex (omg Protobufs!) without build.rs. Not just your own program but all of your dependencies' build.rs is also executed.
I get the need for simple ways to make ecosystem inviting to the new developers. However, I think Cargo was completely mis-designed for simplicity only, where a system language like Rust should shine in its ability to control complexity. With the bad initial design, they invented hacky solutions like build.rs which speaks a string-based language to talk with Cargo!
On top of that crates.io is completely ripe for typosquatting and package overtakes. I think the ecosystem should be completely revamped to a Maven-style namespaced repos and it should require strong GPG signatures.
You're installing code from npm anyway, presumably to execute it at some point on some machine. If it's will be executed from an install script or later during app execution should not really make much of a difference for most devs.
I will never buy another google hardware product again after my most recent pixel experience. I was sent a phone with a defective modem that they refused to replace. This is despite having bought 5 other pixels and also using google fi and a bunch of other google products.
I will never trust them with a hardware purchase ever again.
>I was sent a phone with a defective modem that they refused to replace
To be fair, how would they even verify this? Unless it's outright broken (eg. no cell reception), someone with a "defective modem" is basically indistinguishable from the 99 other people with a perfectly fine phone, but nonetheless want their phone replaced for various nonspecific issues about cell reception.
Good. Pixel phones are the single most overrated phone you can get today.
They've managed to convince people to pay $800 (usually with some discounts to be fair) for what's essentially a $400-450 mid range phone. Even if nothing was defective and customer service was "perfect", it's still a midrange phone priced like a flagship.
My experience with Google hardware is that they shipped an update for Pixel 4a that crippled the battery. In Australia, they announced a safety recall due to a discovered battery safety issue, but in the rest of the world, it seems they wanted to save money by crippling people's phones of their own volition without much explanation. But no worries, they're offering 3 methods of compensation: free battery replacement to restore it, $50 cash, or $100 credit for another Google phone.
I went to redeem my compensation - free battery replacement unavailable in your country, $100 credit unavailable in your country. I guess I'll take the $50 cash...? I fill in the form with my IMEI, full name, address, etc etc. After a week they send a response saying unfortunately after thoroughly looking into my case, I'm not eligible, and no further explanation is offered as to why. In effect it's as if they hacked into my phone and installed a virus that cripples the battery and there's nothing I can do about it, like this is just a normal way to do business now. You don't really own your phone after all...
It's already the case that you get much better results out of LLMs by forcing agents using them to go through additional layers of planning, design & review.
The future is going to dynamically budget and route different parts of the SLDC through different models and subagents running on the cloud. Over time, more and more of that process will be owned by robots and a level of economic thinking will be incorporated into what is thought of today as "software engineering." At some point vibe coding _is_ coding and we're maybe closer to that point than popularly believed.
I work at runloop and I've spent a considerable amount of time getting various benchmarks to run with very high concurrency (thousands at once). My experience is similar to your own: it takes a ton of time and effort setting up benchmarks to run at scale with protection against reward hacks.
Keeping a benchmark test harness secure and fast is non-trivial. You need to keep the grading script and the solution off the box, use network controls, deal with external resource usage, etc. It's a lot of work. I don't think it's realistic to expect benchmark authors to bullet proof their benchmark runners. Most benchmarks are written to be run conveniently on a single machine (ie. in docker), not to run in parallel across tends of thousands of secure, isolated machines.
I realize there's only so much you can fit into an article, but this article glosses over a monumental shift in welfare spending in the US: the transition from defined benefit retirement plans to defined contribution. It's not so simple as a split between private and public directed asset allocation: it affects the growth of companies that offer these plans and the wealth of participants in the plans.
The US has pushed the burden of retirement onto individuals, hoping that the private sector will offer incentives like 401k matching and generous health care plan subsidies, but this is a fundamental difference in who qualifies, what they receive, and how it's funded. These effects compound wealth and income inequality. If, for whatever reason, you're locked out from a job that would help pay for these programs, there's no coming back. You are dependent on the government at the same time as the government is underfunding the program you rely on. It's not a great situation.
Defined benefit plans have a fatal flaw: If the promised benefits don't match investment returns, the difference has to come from somewhere. It comes from some combination of broken promises, higher taxes, higher interest rates and inflation. All of which are political hot potatoes.
Defined contribution plans don't have the same flaw. What you get out of it depends on how much money you put in and how much alpha your investments get. If you don't have enough to support a comfortable lifestyle in retirement, it's not the government's fault, it's user error: You didn't put enough money in, or you didn't invest it properly. The politicians set up systems to help you; "If you didn't use them properly, too bad, so sad, but it's not our fault," they say.
There's also the inescable truth at the root of supporting retirees (and others who aren't working) - in the end, people who aren't working are being supported by those who are working. Investments, pensions, etc. are all just an abstraction around that fundamental reality.
There's also the inescapable truth about what purpose pensions served. They effectively create a massive amount of debt, "owned by" retirees, owed by regular people, managed by bank bosses and politicians. Surprisingly, they changed the social contract enormously: nobody got a choice. Everyone had to pay the new debt, MASSIVE debt, to take care of the elderly. The then barely existing elderly.
Which brings the question ... WHY did they do this?
Politicians: to spend the money (and not on retirees, on their own projects), in other words: when it comes to money, ideally you do not own, but do decide what money is spent on.
Banks (and the rich in general): to redirect a percentage of the money to themselves in 1000 different ways. They can't really get money unless there is large amounts of socially accepted debt in society, it doesn't work: can't get blood from a stone.
Now, when this leads to the problem that either the money disappears, or the social contract behind the debt disappears (ie. either pensions drop to almost nothing, and the spending/social contract (ie. if pensions aren't paid out/aren't livable the willingness of people to pay for pensions disappears, and the debt ... oh dear god the horror ... disappears, and with it the lifeblood of banks and the rich). Then of course panic sets in, and suddenly when THEY get in trouble any law change imaginable is suddenly on the table.
The scary part is the obvious solution, the only solution really. You know what would solve the pension crisis without destroying the social contract? If the elderly were to die (a lot) faster. That is the only way the politicians can keep spending and banks can keep their profits. Which is exactly what Trump's doing with the enormous increase in medical costs. For the elderly it's simple: pay ... or die. That's the new social contract here. In other words: in what I'm sure will come as a total surprise to everyone, when democrats get control again, they will see how much it costs, how much of their projects it would kill ... and then will not refund Obamacare to anywhere near the level before Trump and they will in fact vote to keep this new social contract in place.
Of course reality is simple: politicians and the rich are promising pensions to everyone, and the really obvious truth is starting to become glaringly fucking obvious: they're lying. One way or another, you're not getting the pension you paid for, you're not getting the medical care you're paying for. You paid the money, and ... you're NOT getting the service you paid for! You also, of course, don't get to stop paying, in fact they're demanding more now. You don't get to stop working. Obviously, politicians don't want to be called to account for that one.
Kill the elderly: it's either that ... or take the money from the rich. Easy choice, no?
That's right. But they (E2B) rely on the underneath Cloud infra to achieve high scalability. Personally, I'm still not sure about the value they add on top of Cloud hosted VMs. GCP/AWS already offer huge discounts to startups, which should be enough for VM-based sandboxing of agents in the MVP phase.
- high net wealth individuals essentially being indifferent to income tax.
- income tax and short term capital gains are taxed at much higher rates to long term capital gains.
- lower net wealth folks (ie. the general public) receiving most of their income as income.
- high and ultra high net wealth individuals now making most of their money through dynastic trusts and inheritance.
This combination ends up making it so that, as Warren Buffet would put it, he ends up paying a lower effective tax rate than his secretary.
I effectively don't really care if it's a wealth tax or some other more targeted technical fix, but it's not sustainable to have the very wealthiest individuals taxed at a lower effective tax rate than everyone else and also able to pass on their wealth directly to heirs without significant estate taxes.
reply