5 ms·

I generally agree with all of this, but I'll add a few additional remarks. Because it's come up a bunch lately, I decided to do a bunch of code review/audit of

I generally agree with all of this, but I'll add a few additional remarks. Because it's come up a bunch lately, I decided to do a bunch of code review/audit of the Fil-C codebase, and I'd say while it's got a lot of good bones, there's a long way to go to being a foundation I'd be ready to build on. I've reported a few UAF's upstream, and I've got a few PRs I'll add on, but if it only took me a day or two to find some of these big holes, I'm sure there's more lurking under the surface. I'd consider it to at this point be more of an engineering demo that this approach is feasible and tractable, but not a production ready language that I'd want to ship code in. On the muddling the discourse, I'm not on twitter and don't engage there, so I don't have an opinion on that, but I did come across https://news.ycombinator.com/item?id=49044561 https://news.ycombinator.com/item?id=49044561 recently, and I just don't see how the author can make such bold claims while examples like the one Steve provided above are still in the language. Corrupting memory in Fil-C is still easy, type confusion is still easy, intra-object overflows are still easy. Fil-C prevents a range of classes of bugs from being exploitable, but it doesn't stop the bugs from happening.

josephg 3mo ago
Yeah. In that thread the Fil-C author said of typescript, go and C#: > Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does. So Fil-C is safer than those Given the relative immaturity of Fil-C, this seems wildly wrong to me. I’m not sure how to take his claims about his runtime seriously. [ https://news.ycombinator.com/item?id=49042736 https://news.ycombinator.com/item?id=49042736 ]
- pizlonator 3mo ago
  This is a simple fact. The Fil-C runtime is tiny compared to TS and C#
  - mirashii 3mo ago
    > The Fil-C runtime is tiny compared to TS and C# Sure, this is a simple fact. > So Fil-C is safer than those This is not a simple fact that follows, and a good example of why you seem to be catching so much criticism for overly bold claims. One could state that a smaller runtime is easier to audit, and so the investment needed to reach similar levels of safety is lower. One might even argue that after similar levels of investment, that the probability that it's safer is higher. But jumping all the way from lower number of lines => safer is a simple fact is a huge leap.
    - pizlonator 3mo ago
      I have worked on both a major JS runtime and a .NET runtime. I have fixed hundreds of security bugs in JSC. Based on that, I have no doubt that what Fil-C does is safer. Just the absence of a JIT makes it safer in a way that I don’t think is seriously debatable. Even with JIT disabled, a JS runtime has massive attack surface due to the language relying on a large native library to do anything useful, not to mention a mind boggling amount of language implementation corner cases. By contrast Fil-C has a small number of rules and largely obviates the need for “native” code.
pizlonator 3mo ago
First of all, it’s incredible that on a HN thread about a language that isn’t C, there are 46 mentions of Fil-C! You guys are obsessed! I make bold claims because they hold water. - You can at worst corrupt only the capability you’re pointing to. - intra object overflows are almost never useful for memory corruption exploits unless they let you corrupt a pointer, and Fil-C prevents that from being useful because you cannot corrupt the capability. - the zunsafe api is basically unused. One library uses it (OpenSSL) for good reasons. This is in contrast to widespread use of the unsafe keyword in Rust, beyond just one library for a narrow purpose. Thanks for reporting bugs. Worth noting that they require doing things that extant C code never does. It’s good to fix those, but the true threat model of any memory safe language is not to sandbox a malicious programmer, but to protect the program of a normal programmer against a malicious user
- orf 3mo ago
  > the zunsafe api is basically unused. One library uses it (OpenSSL) for good reasons Wait, so there are escape hatches? But… you’ve repeatedly said, many times, that there are zero escape hatches? And now here you’re saying not only that there only are escape hatches, but there’s a good reason to use them? Damn. Misrepresenting `unsafe{}` whilst saying your language is better because there are no escape hatches and no need for escape hatches is like… 80% of your online personality. When can we expect the website to be updated to remove the misleading claims?
  - pizlonator 3mo ago
    From the second paragraph of fil-c.org: "Fil-C has no unsafe statement and only limited FFI to unsafe code." `zunsafe_call` is a weird thing to get hung up on as an "escape hatch", considering it's just a super limited form of FFI, intentionally designed so that it's only usable for OpenSSL's use case. > Misrepresenting `unsafe{}` `unsafe` lets you write Rust code that violates any reasonable definition of memory safety (including Rust's definition or my definition), and it's widely used.
    - orf 2mo ago

josephg 3mo ago

Yeah. In that thread the Fil-C author said of typescript, go and C#: > Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does. So Fil-C is safer than those Given the relative immaturity of Fil-C, this seems wildly wrong to me. I’m not sure how to take his claims about his runtime seriously. [ https://news.ycombinator.com/item?id=49042736 https://news.ycombinator.com/item?id=49042736 ]

pizlonator 3mo ago
This is a simple fact. The Fil-C runtime is tiny compared to TS and C#
- mirashii 3mo ago
  > The Fil-C runtime is tiny compared to TS and C# Sure, this is a simple fact. > So Fil-C is safer than those This is not a simple fact that follows, and a good example of why you seem to be catching so much criticism for overly bold claims. One could state that a smaller runtime is easier to audit, and so the investment needed to reach similar levels of safety is lower. One might even argue that after similar levels of investment, that the probability that it's safer is higher. But jumping all the way from lower number of lines => safer is a simple fact is a huge leap.
  - pizlonator 3mo ago
    I have worked on both a major JS runtime and a .NET runtime. I have fixed hundreds of security bugs in JSC. Based on that, I have no doubt that what Fil-C does is safer. Just the absence of a JIT makes it safer in a way that I don’t think is seriously debatable. Even with JIT disabled, a JS runtime has massive attack surface due to the language relying on a large native library to do anything useful, not to mention a mind boggling amount of language implementation corner cases. By contrast Fil-C has a small number of rules and largely obviates the need for “native” code.

pizlonator 3mo ago

First of all, it’s incredible that on a HN thread about a language that isn’t C, there are 46 mentions of Fil-C! You guys are obsessed! I make bold claims because they hold water. - You can at worst corrupt only the capability you’re pointing to. - intra object overflows are almost never useful for memory corruption exploits unless they let you corrupt a pointer, and Fil-C prevents that from being useful because you cannot corrupt the capability. - the zunsafe api is basically unused. One library uses it (OpenSSL) for good reasons. This is in contrast to widespread use of the unsafe keyword in Rust, beyond just one library for a narrow purpose. Thanks for reporting bugs. Worth noting that they require doing things that extant C code never does. It’s good to fix those, but the true threat model of any memory safe language is not to sandbox a malicious programmer, but to protect the program of a normal programmer against a malicious user

orf 3mo ago
> the zunsafe api is basically unused. One library uses it (OpenSSL) for good reasons Wait, so there are escape hatches? But… you’ve repeatedly said, many times, that there are zero escape hatches? And now here you’re saying not only that there only are escape hatches, but there’s a good reason to use them? Damn. Misrepresenting `unsafe{}` whilst saying your language is better because there are no escape hatches and no need for escape hatches is like… 80% of your online personality. When can we expect the website to be updated to remove the misleading claims?
- pizlonator 3mo ago
  From the second paragraph of fil-c.org: "Fil-C has no unsafe statement and only limited FFI to unsafe code." `zunsafe_call` is a weird thing to get hung up on as an "escape hatch", considering it's just a super limited form of FFI, intentionally designed so that it's only usable for OpenSSL's use case. > Misrepresenting `unsafe{}` `unsafe` lets you write Rust code that violates any reasonable definition of memory safety (including Rust's definition or my definition), and it's widely used.
  - orf 2mo ago