4 ms·

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

amoshi 2mo ago
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 https://github.com/oven-sh/bun/issues/39800 AI (robobun) responds and creates PR. https://github.com/oven-sh/bun/pull/37459 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.
- bigiain 2mo ago
  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.
  - reactormonk 1mo ago
    ref: https://en.wikipedia.org/wiki/XZ_Utils_backdoor https://en.wikipedia.org/wiki/XZ_Utils_backdoor
  - pluc 1mo ago
    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.
CrimsonRain 2mo ago
As it should be if not more. What's wrong with it?
inigyou 1mo ago
Here's the most recent nontrivial one as of this comment: https://github.com/oven-sh/bun/commit/d4de65e9a43224a14591ad75fd2258649141ab31 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/72ec6e2594892455df009072eb8034d93d510d75 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.
- charleslmunger 1mo ago
  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.
  - inigyou 1mo ago
    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'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 https://github.com/oven-sh/bun/issues/39800 AI (robobun) responds and creates PR. https://github.com/oven-sh/bun/pull/37459 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.

bigiain 2mo ago
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.
- reactormonk 1mo ago
  ref: https://en.wikipedia.org/wiki/XZ_Utils_backdoor https://en.wikipedia.org/wiki/XZ_Utils_backdoor
- pluc 1mo ago
  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.

CrimsonRain 2mo ago

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

inigyou 1mo ago

Here's the most recent nontrivial one as of this comment: https://github.com/oven-sh/bun/commit/d4de65e9a43224a14591ad75fd2258649141ab31 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/72ec6e2594892455df009072eb8034d93d510d75 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.

charleslmunger 1mo ago
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.
- inigyou 1mo ago
  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