jagrsw

> scheming -> didn't occur

If a model were actually capable of scheming, it would also have enough situational awareness from its training corpus to know that <thought> parts are monitored too.

If the monitor catches the model writing "let's deceive the user", it's definitely scheming. But if the monitor finds nothing, you've learned almost nothing.

<absence of evidence != evidence of absence>

I don't know much about corporations, but why business plans are needed at all? I mean, for EU citizens.

bank (loans), immigration and investors can be interested, but their interests are not covering every corporation out there.

> To stop me you'd have to compel me.

  Cow A: "That building smells like blood and steel. I don't think we come back out of there"
  Cow B: "Maybe. But the corn is right there and I’m hungry. To stop me, you'd have to compel me"

Past safety is not a perfect predictor of future safety.

To clarify the position, my concern isn't that the project is bad - it's that security engineering is a two-front war. You have to add new protections (memory safety) without breaking existing contracts (like ld.so behavior).

When a project makes 'big claims' about safety, less technical users might interpret that as 'production ready'. My caution is caused by the fact that modifying the runtime is high-risk territory where regressions can introduce vulns that are distinct from the memory safety issues you are solving.

The goal is to prevent the regression in the first place. I'm looking forward to seeing how the verification matures and rooting for it.

You're right, my tone was off.

I understand your point, and I have the utmost respect for the author who initiated, implemented, and published this project. It's a fantastic piece of work (I reviewed some part of it) that will very likely play an important role in the future - it's simply too good not to.

At the same time, however, the author seems to be operating on the principle: "If I don't make big claims, no one will notice." The statements about the actual security benefits should be independently verified -this hasn't happened yet, but it probably will, as the project is gaining increasing attention.

I checked the the code, reported a bug, and Filip fixed it. Therefore, as I said, I was a little concerned.

The author has a knack for generating buzz (and making technically interesting inventions) :)

I'm a little concerned that no one (besides the author?) has checked the implementation to see if reducing the attack surface in one area (memory security) might cause problems in other layers.

For example, Filip mentioned that some setuid programs can be compiled with it, but it also makes changes to ld.so. I pointed this out to the author on Twitter, as it could be problematic. Setuid applications need to be written super-defensively because they can be affected by envars, file descriptors (e.g. there could be funny logical bugs if fd=1/2 is closed for a set-uid app, and then it opens something, and starts using printf(), think about it:), rlimits, and signals. The custom modifications to ld.so likely don't account for this yet?

In other words, these are still teething problems with Fil-C, which will be reviewed and fixed over time. I just want to point out that using it for real-world "infrastructures" might be somewhat risky at this point. We need unix nerds to experiment with.

OTOH, it's probably a good idea to test your codebase with it (provided it compiles, of course) - this phase could uncover some interesting problems (assuming there aren't too many false positives).

It's not possible even in 10 years (.. but maybe in 11).

What a shift in the last 5 years (never -> 100 years -> 11)