quotemstr

Just add async_uuid to your IDL locally and rerun MIDL. The server doesn't know or care that it's being called asynchronously. It's a pure client thing. If you're calling an IFoo in a different apartment, you can do the call asynchronously by changing your client configuration without the IFoo implementation having to be aware that anything is going on.

You can also use IRpcChannelBuffer3 to make the call asynchronously no matter what the IDL says. You'll have to write the proxy plumbing yourself, but it'll work, and you don't even need to rerun MIDL.

And COM enforces lifecycle rules, transparent remoting, uniform activation (constructors basically), security primitives, marshalling, transparent async calls (yes, you can call any method asynchronously), and a ton of other things. It's actually very good and it's a shame most don't know about it and most of the rest sneer at it.

> less knowledge, more intelligence

People produce such models by over-RL-ing smaller models on math and coding tasks. I've found the results capable of neither innovative work nor thinking outside the box. They're straight-A students raised by tiger moments who never let them play freely for hours in the dirt.

Perhaps you could say such models are skilled --- but intelligent? Not by my measure.

People and AIs alike need diversity of experience and a broad liberal arts education to see hidden connections between fields and make real advances.

I wish that when people posted a performance win, they would include a theory explaining it. Unexpected speedups are usually noise, bugs, or harness issues. No program is faster due to the superior manly virtue of its programmer. Every effect has a cause.

When, from first principles, something shouldn't be faster, yet it is, you dig and dig until you understand. You don't just say your shit rules and the other thing sux0rz. If you do, you'll regret it: if you don't understand how you got a win, you don't understand how to keep it.

To be fair, this description omits a huge part of the modern terminal interface surface.

One advantage to using pthread is the ability to call pthread_setname_np to name threads and thereby make debugging easier. Granted, you can call it with std::thread by using std::thread::native_handle() to get the pthread handle, but you're still using a non-std::thread API.

Excellent use of Ragel to generate fast state machines. Everyone should check it out: https://www.colm.net/open-source/ragel/

The author of shitty encoded the whole terminal state machine in Ragel: https://github.com/pg83/shitty/blob/master/parser.rl

The thing generates one of big DFA with actions for everything that can ever happen in the terminal. Precisely correct way to do it. Plus, Ragel is a joy to program once you get the hang of it. You can compose edge-triggered, level-triggered, and recursive operators in surprisingly elegant ways.

It's confusing how they want a custom protocol that seems to be converging from JSON-RPC, just spelled differently. They should just use JSON-RPC. In any case, it'd essential to retain PAM's customization ability even if the bulk of the work is moved out-of-process.

Not everything has to be a "daemon". It's a bad trend in current programming zeitgeist to want to make everything into one. (sccache, no, you do NOT need a daemon to behave like ccache.)

For a PAM replacement, you want a separate process. It doesn't have to be a persistent separate process.

Implementation language is incidental. Rust is... fine, I guess? But I wouldn't mandate modules use it. What's important is to move PAM out of process and sandbox the process host (using landlock, namespaces like bwrap, whatever) so we can run sensitive code with least-privilege on both ends.

Everyone doing parallel biometric and password authentication on Linux today is either running two PAM stacks in parallel (which is meta-policy that kind of defeats the purpose of PAM) or just bypassing PAM entirely.

PAM really needs to be ravamped and support for (among other things) running multiple stacks in par@llel added. This way you could ask for a password OR a fingerprint

It'd look like Graal, which is a real thing you can use today.

Classic ciphers are damn fast and small compared to PQC. If you're doing PQC anyway, doing classical cryptography at the same time has negligible cost.

That makes attempts to push PQC-only modes super suspicious to me. Smells like Dual_EC_DRBG.

One attack weakens HAWK, a post-quantum cryptography cipher candidate. I don't trust these PQC things one bit. I'll use them in combination with a strong clasically-resistant cipher (in so-called hybrid encryption modes), but not alone.

There's a push to turn off the classical modes and rely entirely on PQC for both quantum and classical security. Uh... no, thank you? Why would we want to do that at this point? The classical cipher component isn't hurting anything. Awfully creepy to pushing reliance on the new thing alone.

... especially now that we have LLM-discovered attacks on the new things.

How do their servers know I'm running a proxy, exactly?

If I own a computer, I should be able to run whatever damn software I want on it, including software that provides a network proxy to others. (N.B. a smart TV is a computer I own.)

Yes, yes, we should fight deceptive software that doesn't disclose it has a proxy function. Fine. But there's no way to square 1) fighting all residential proxies, including ones run with informed consent and 2) preserving the public's access to general-purpose compute at home.

I'd rather live with the proxies than for someone to tell me that if I run squid, I'm damaging national security.

> And I also think it is totally fine to use Rust even if you could use a GC language like Go or Fil-C.

The problem with choosing Rust over a GC language like the above (or a good one, like OCaml) isn't that it's not "fine" to use Rust, but that manual memory management is an inefficient use of developer time. That's an issue for the developer, and one he inflicts on himself, not an issue for the end-user. Both Rust and (safe) GC languages provide memory safety, after all.

Your argument is literally that there is too much unsafe code.

That's a lot of words to say that the problem with Rust is that people you don't like are allowed to write unsafe code.

> It is not in scope of memory safety to make sure that logic not related to memory accesses works as you expected

This logic is related to memory accesses. This is not an issue that can occur in systems that provide the memory-safety guarantees that the words "memory safe" usually name.

You can't escape failure to meet a public definition of a term by adopting a private definition. The English language has a term for this pattern.

> You’re being disingenuously imprecise

You are the one being imprecise. You claim that because T1 could access foo at some time in the past, it's okay for a subsequent execution to access foo when the program text limits the access to bar. The temporal history is irrelevant. You are taking language that applies to inter-actor access control and applying it to invalid execution detection.

If T1 and T2 were, say, mutually untrusting actors over a network, that T1 had a capability at one point would be a valid defense. We're talking about a totally different scenario, not an object-capability security system, but preventing attackers turning illegal C into various kinds of exploit, e.g. EOP, information disclosure, and so on.

It does not matter that T1 used to have the capability and could have used it. We're talking about an attacker using an exploit to make T1 do his bidding, not T1 itself being a hostile actor running in a sandbox.

You can't just define the problem away. Real-world C has these races. They've been exploitable. Your system doesn't close them.

> Hence, this isn’t an arbitrary memory access.

Not arbitrary, true. Irrelevant. It's a cross-object access that violates programmer expectations and is likely exploitable.

> This is a memory access that obeys the capability model

You're using the English words that denote a strong guarantee in the security community and using them to describe your weaker system.

> I think that is doing more damage than anything I have said

Damage to what? You can't fix this problem in Fil-C without introducing atomics to every globally-visible store path, so you're going around the internet trying to play definition games to define it out of existence. The only damage here is to people who think Fil-C provides stronger mitigations than it does.

> Also, Fil-C’s guarantee that it will panic on OOB or if a race goes badly

Fil-C as currently implemented does not guarantee panics on unsafe accesses due to races. You dodge the problem by using a private definition of safety under data race that permits program executions nobody would expect.

> In a race, you at worst access an object you could have loaded from whatever field you were racing on.

Suppose a pointer ptr is initialized to foo and transitions once to bar; suppose also that x is attacker-controlled. Then,

  T1: T* p = ptr; if (p == bar) p[x] = 7
  T2: ptr = bar

A program can observe p == bar (testing the address bits) but still permit a write to foo through p (allowed by the stale capability bits after offset by attacker-controlled x), allowing T1 to perform an unexpected mutation of foo.

No, you do not always trap in this scenario, as you've claimed repeatedly on X. You perform the capability check after combining p and x. If an attacker sets x == foo - bar, then p[x] refers to memory inside foo even if p == bar.

Because (for understandable reasons) you don't insert a memory barrier between a write of a pointer's address bits and its capabilities, use two-word atomic accesses, STM, or in any other way synchronize writes to pointer addresses and capabilities, programs with data races can observe arbitrary combinations of linear addresses and capabilities that go along with them.

Plenty of exploit chains have had humbler beginnings.

This access-foo-through-pointer-to-bar scenario can't happen in Java. It can't happen in CHERI. It can happen in Fil-C. Yes, T1 at one time had a capability on foo, but the programmer intent is clearly to mutate only bar, and Fil-C allows an execution that mutates foo instead.

Elsewhere, you've claimed such executions cannot be exploited. I am skeptical of this claim given previous exploits that began by the camel poking its nose through similarly innocuous-seeming holes in the tent.

Fil-C cannot fully protect C programs from exploitable memory corruption caused by violations of the C virtual machine. 99.9% of practical ones? Sure! Fil-C is good stuff. But there are holes (not only here, but for arenas, intra-object corruption, etc.), and these are holes that safe Rust prevents. Fil-C and Rust rules prohibit different (but mostly overlapping) classes of exploit.

Could you define Fil-C's behavior as "memory safety"? Sure. You can define words to mean anything. You cannot, however, define Fil-C as something that just deletes the security implications of bugs in existing C programs. Does it mostly achieve this goal? Sure. Does it supply comprehensive coverage? No! It's a hardening tool, not a panacea, and it would behoove you to represent it as the useful tool it is, not magic pixie dust that makes C safe.

Please stop ruining a tool as good as Fil-C by claiming it does things it does not and cannot.

> In Go, you can bypass all protections and corrupt all of memory if you race on structs (I think).

This is my understanding as well. I'm glad we agree, opinions on Fil-C memory model counting as "safe" aside, that Go is awful.

Races in Fil-C allow access to one object through a pointer to a different object if there's an attacker-controlled offset involved.

Fil-C's safety guarantees therefore fail to apply in this situation.

If we strip away the semantic maneuvering, your argument becomes this: Rust is unsafe because it lets people who aren't you, Pizlo, write unsafe code. Safety means trusting only you with machine code.

Anyone could do the same with a Rust lint rule if he wanted. He wouldn't, because this policy is not the way to secure software.

Any safe system has unsafe parts. Quibbling about whether these parts are called "blocks" isn't useful. The term changes nothing.

Every one of these posts is the same. There's this weird blindness to the problems and imperfections in Fil-C --- just shouting down. It reduces my confidence in Fil-C as a whole.

Rust, for all its faults, at least engages with its critics. I've long faulted Rust's use of Result over exceptions, for example, but the maintainers at least acknowledge that other options exist and each has trade-offs. Not Pizlo and his fans.

To be clear, I like Fil-C. It's a practical implementation of something that should have existed a long time ago. And Pizlo is, in fact, a great programmer. It just rubs me the wrong way that he can't be content with having done excellent work --- he has to claim things that his system doesn't provide (like memory safety under data races --- minor fault, but still) and claim that other systems are worse in ways they are not (e.g. with respect to Rust having unsafe blocks).

Is genuine excellence not enough? Why must he persist in claiming a false perfection?

Okay, let me know when I can call process_vm_writev or ptrace and have Fil-C verify safety properties on the result.

> is going to be short lived because someone will train an AI on a corpus of human keystrokes and get a replication

You can remotely attest the input devices. You can do it anonymously (long story, but doable) and without requiring some kind of pre-signed image for the while OS. (The OS passes through recent-input attestations.)