Once a patch for a security vulnerability is public, the patch itself can reveal the vulnerability before the CVE is published. VCamper uses a staged LLM pipeline to analyze a Git commit range and flag likely vulnerability patches, even when they look like routine changes.

It’s still a proof of concept, but on known cases like curl CVE-2025-0725 it got close to the published root cause from the patch alone.

This matters because LLMs could make it much harder to keep security fixes quiet: once the patch is public, the bug may be recoverable almost immediately. Quietly shipping a fix and hoping it stays under the radar may stop being a reliable strategy.

https://github.com/rndhouse/vcamper

I’m building Draxl, a source format for a world where code is edited by millions of agents.

AI agents will produce far more code than humans do today. Rebased branches, concurrent edits, and long-lived forks will become much more common. Code management needs more precise control at that scale.

Draxl embeds stable AST node IDs directly in the source, so tools can target syntax by identity instead of by line position. Here’s a small example:

Here is a small example:

  @m1 mod demo {
    @d1 /// Add one to x.
    @f1[a] fn add_one(@p1[a] x: @t1 i64) -> @t2 i64 {
      @c1 // Cache the intermediate value.
      @s1[a] let @p2 y = @e1 (@e2 x + @l1 1);
      @s2[b] @e3 y
    }
  }

  @id[rank]->anchor

* `[rank]` orders siblings inside ranked slots

* `->anchor` attaches detached docs or comments to an existing sibling id

The same code lowers to ordinary Rust:

  mod demo {
      /// Add one to x.
      fn add_one(x: i64) -> i64 {
          // Cache the intermediate value.
          let y = (x + 1);
          y
      }
  }

That lets a tool say "replace expression `@e3`" or "insert a statement into `@f1.body[ah]`" instead of "change these lines near here."

That should make semantic replay more reliable under heavy concurrent editing. It should also reduce false merge conflicts and localize real ones more precisely.

It also opens up other uses. You could attach ownership, policy, or review metadata directly to AST nodes.

I’m interested in early feedback: does this source model feels useful, and whether editing code this way seems like a better fit for agent-heavy workflows. Where are the best places on the internet to discuss this sort of thing?

Connect with me: https://x.com/rndhouse

Comments URL: https://news.ycombinator.com/item?id=47328879

Points: 4

# Comments: 0

https://github.com/openfare/openfare

https://github.com/vouch-dev/vouch

https://github.com/mozilla/cargo-vet

I think this gets to the heart of the matter. The goal with OpenFare (for non-FOSS) is to minimize this overhead cost. I believe that it can be minimized to a point where it is negligible. For FOSS it is already negligible. The method for minimizing that cost is to make a predictable pattern familiar and ubiquitous.

> had better respond quickly to security vulnerabilities and feature requests

That depends on the deal. If you buy software for $.01 what do you expect beyond your expectations had you paid nothing? Software support can't be assumed just because money is trading hands.

I need to think about it a bit more. And I'd like to hear more opinions on ideas like this.

> If you, a contributor, want to change your funding preferences, you have to file a PR with the project?

Yes, or, a bot could track your funding preferences from some repo and submit a PR for you. (Cryptographic verification permitting.)

> If you update your preferences, other branches of the same project can still have different preferences?

Yes but those other branches will be outdated and git will make that clear. Only the commit from which the software package is derived matters. Donation schemes are derived from software packages.

## Forking a project

Contributors could get a share of donations by proposing a change to a project's lock file via a pull request. Or they could fork and make a change. But their fork would have to stand on it's own as a software package.

https://github.com/openfare/openfare#micropriced-commercial-...

If all users chip in $1/month, perhaps it adds up to something significant.

I think the challenge is to minimize the overhead costs of that process.

I imagine the distribution curve of funding. If it shifts one way, more developers become full time open source maintainers. Those who previously received nothing might start receiving coffee money.

If we can normalize a low friction mechanism for receiving funds for developers then the curve might be shiftable.

But I think mechanisms for rating software packages already exist (GitHub stars for instance). And we have reasonable metrics for whether a software package is under active development/maintenance. If we combine those two factors in deciding which dependencies to fund we might be in a reasonable place.

Any metric can be gamed of course.

The macro goal of OpenFare is to put in place a mechanism that developers can use to receive funds for developing public software. If there is a demand for donations, it needs to be brought to the surface. I don't think we're adequately over that hurdle.

Many content creators (youtubers, gamers, ...) get paid a lot. I think that there is room for public software engineers to ask for their share.

My goal is to put the mechanisms in place. And give people another means of self expression.

This is certainly a problem that I would like to address. It's important to reward/fund contributors as much as maintainers.

Donation schemes defined in code are as modifiable as any other code in the software. I would like to build a bot which will open a pull request on behalf of contributors and propose a share of donations.

Commercial payment plans defined in code can be managed programmatically. Which means that small payment obligations can be managed at scale. Consequently, trivial software dependencies could raise meaningful capital from micropayments.

See: https://github.com/openfare/openfare#micropriced-commercial-...

However, software for a fee is not FOSS.

My intent is to create a community around the idea and to get early feedback. It's true that there are many problems outstanding. I'm yet to share a payment portal for instance that will effectively outsource the infrastructure necessary to distribute funds.

Comments URL: https://news.ycombinator.com/item?id=29909068

Points: 89

# Comments: 49