Hacker News Reader

Hacker News

Comment by vermilingua | Hacker News Reader

Parent Full thread

vermilingua

More than 50% of the recent commits are from robobun, jesus

View on HN

It's AI all the way down.

An issue reported by a person account but post made by AI. https://github.com/oven-sh/bun/issues/39800

AI (robobun) responds and creates PR. https://github.com/oven-sh/bun/pull/37459

AI (coderabbit, claude, github actions) review the PR, AI (robobun) applies the fixes.

Some AI back and forth.

A human finally merges the PR.

Not gonna lie, it's kind of beautiful.

Some guy, profiling his linux distro, wonders why ssh connections are a few hundred milliseconds slower than expected, finds there PR introduced and RCE backdoor and p0wns the whole project.

ref: https://en.wikipedia.org/wiki/XZ_Utils_backdoor

Seriously, this is driving me insane. The XZ hack told us what we had to do to secure our supply chain, and instead we went ahead and implemented a worldwide standard for NLP-to-action and figured we'd worry about the guardrails later. Mad.

As it should be if not more. What's wrong with it?

Here's the most recent nontrivial one as of this comment: https://github.com/oven-sh/bun/commit/d4de65e9a43224a14591ad...

The code change makes no sense and should do nothing. The commit message described a very deep investigation into garbage collection on the C++ side. Some object is being kept alive when the test requires it to be collected, and changing the code in this way allegedly prevents that. But wouldn't you think there would be a better way to ensure an object gets collected, like setting the variable to null?

The comments in the code don't make a lot of sense either. Something so obscure and brittle has to be explained extremely clearly.

While the issue might be real, this commit is so far away from the locus of normal that it's sending red alert. Plus a hallucination is very likely with such a long investigation - once an LLM agent starts investigating it just assumes there is a problem. And this is the 1 out of 1 robobun commit that I looked at.

Edit: here's the next one: https://github.com/oven-sh/bun/commit/72ec6e2594892455df0090...

Make sure the fs module keeps working if someone freezes or seals its exports table. I was wondering who was going around freezing random tables from other modules, so I checked the linked issue - robobun reported the issue, too. Why? I'm skeptical of whatever robobun was doing when it decided that it was necessary for code outside of a module to freeze their export tables. It needs a very good justification.

The first is, annoyingly, a relatively common problem and solution when dealing with GC lifetimes in tests. Few interpreters/JITs want to generate extra instructions to null out stack slots or pre clobber registers to ensure something becomes collectible at a specific point. Eager nulling of a variable often gets removed by dead store elimination or even just from being a disconnected SSA node. I've written extra nested scopes or wrappers in Java to deal with this in tests.

Don't know anything about the second one.

If this is needed in tests it needs to be known how it works, it needs to work consistently, and it needs to be documented how it works. It can't be an ad-hoc deep investigation and random fix each time. The comment should then be just // ensure foo is no longer a GC root, see gc_roots.md

It needs a comment for sure. I always write a little helper utility to manage that when I need it.

Reply on news.ycombinator.com