If they made a low power/mobile version, this could be really huge for embedded electronics. Mass produced, highly efficient "good enough" but still sort of dumb ais could put intelligence in house hold devices like toasters, light switches, and toilets. Truly we could be entering into the golden age of curses.
You can probably get any coding agent with this if you put these instructions in the README/CLAUDE.md/AGENTS.md or whatever of your repo.
It's unclear to me if Bob is working as intended or how we should classify these types of bugs. Threat modeling this sort of prompt injection gets murky, but in general don't put untrusted markdown into your AI agents.
It's actually pretty easy to detect that something is obfuscated, but it's harder to prove that the obfuscated code is actually harmful. This is why we still have a team of humans review flagged packages before we try to get them taken down, otherwise you would end up with way too many false positives.
When we find malware on any registry (npm, rubygems, pypi or otherwise), we immediately report it to the upstream registry and try to get it taken down. This helps reduce the blast radius from incidents like this and mitigates the damage done to the entire ecosystem.
You can call it ambulance chasing, but I think this is a good thing for the whole software ecosystem if people aren't accidentally bundling cryptostealers in their web apps.
And regarding not copying massive trees of untrusted dependencies: I am actually all for this! It's better to have fewer dependencies, but this is also not how software works today. Given the imperfect world we have, I think it's better to at least try to do something to detect and block malware than just complain about npm.
We use a mix of static analysis and AI. Flagged packages are escalated to a human review team. If we catch a malicious package, we notify our users, block installation and report them to the upstream package registries. Suspected malicious packages that have not yet been reviewed by a human are blocked for our users, but we don't try to get them removed until after they have been triaged by a human.
In this incident, we detected the packages quickly, reported them, and they were taken down shortly after. Given how high profile the attack was we also published an analysis soon after, as did others in the ecosystem.
We try to be transparent with how Socket work. We've published the details of our systems in several papers, and I've also given a few talks on how our malware scanner works at various conferences:
While it sucks that this happened, the good thing is that the ecosystem mobilized quickly. I think these sorts of incidents really show why package scanning is essential for securing open source package repositories.
Signing doesn't protect against maintainer sabotage, but it could theoretically help if the registry were ever compromised. It mainly works to prevent MITM type attacks on the package distribution itself.
In the case of central package managers like rails/npm/cargo/etc., these benefits are very speculative, but there is probably some merit to adopting this approach in distributed ecosystems like go.
This seems really badly argued. The second version seems much worse and harder to extend. Looks like classic ORM style database abstraction wrapped with hand written types. This type of code usually leads to inflexible data models and inefficient n+1 query patterns. Relational algebra is inherently more flexible than OOP/ML-style type systems and its usually better to put as little clutter between your code and the db queries as possible in practice.
Most games since Half Life 2 use constraint forces like this to solve collisions. Springs/penalty forces are still used sometimes in commercial physics solvers since they're easier to couple with other simulations, but they require many small timesteps to ensure convergence.
The principle of least constraint is the basis for rigid body mechanics based contact forces. This has been known since the days of Gauss and Hamilton, and is fundamentally how restitution and collision forces are derived in Lagrangian mechanics. There's a long literature on this going back more than a hundred years.
It's true that some commercial solvers like Ansys use spring/penalty methods, but this is due to the spring forces being easier to couple to other solvers. It's harder in the Ansys force/velocity formulation to combine things like elasticity and fluids to their rigid body solver. To deal with the instability of systems of many stiff springs they have to take many small timesteps to avoid convergence issues.
More recently techniques like XPBD have been gaining popularity, particularly in film, which use purely positional constraints and variational methods to combine many different types of physics simulations. There's a really great and approachable series of videos by Matthias Muller on youtube which goes through how to implement all this in JS https://matthias-research.github.io/pages/
Finally it's funny you should mention games, since many older games used spring methods for physics. It was only when constraint based solvers became popular after Havok/Half-Life 2 did we start to see games with real rigid body dynamics and stable stacking of boxes. Older physics games like Trespasser ( https://en.wikipedia.org/wiki/Trespasser_(video_game) ) had many bugs due to the use of hacky spring physics. For a good explanation of how games do it today look at Erin Catto's work on Box2D https://box2d.org/publications/
It's still the same principle even in games. If you are trying to explain where forces come from and how resolution works, you need to ground it in something. Otherwise you are just adding extra assumptions onto assumptions.
Collisions are violations of the pairwise non-intersection constraint between bodies. Collision forces are Lagrange multipliers of these constraints. Collision normals are the (normalized) partial derivatives of the constraint function wrt one of the body's configurations.