amluto

Hmm. The example in the article involves overlapping references to .cache and .template. I’m not seeing how owned guard protections would make sense.

I can maybe see how one might have a MutexGuard for the entire RenderState and then pass an owned MutexGuard<PartOfTheState> somewhere else, but this seems like it should not be necessarily be able to coexist with other guards holding the same mutex.

How would split guards work, anyway? Reference counts on parts of the mutex? Would the mutex have to opt in? Is there an actual example where splitting a mutex guard would be useful!

This is neat, but I admit I find the MutexGuard example to be uncompelling. The article says:

> For example, how to turn (the handle for) a MutexGuard<RenderState> into a MutexGuard<String> when the programmer writes state.template.

Please don’t. In the examples later in the article, maybe an Option<&A> can be dereferenced and projected to get an optional reference to something inside the A. Fine — Option is logically a value, and you either have a reference or don’t have a reference.

But a MutexGuard is not just a value. It’s a representation of a lock held on a particular mutex. Dropping it has side effects! If I have a MutexGuard<RenderState>, this means that there is a Mutex<RenderState> and that, when the guard drops, the mutex unlocked. A field in the RenderState should not have a guard unless it has its own mutex!

ISTM what’s actually wanted for mutex guard field projections is one of two things:

1. Nicer syntax. The article points out that this works today:

    let state: &mut RenderState = &mut *state.lock().unwrap();

Great! Improve the syntax! Or:

2. Use the new machinery to make the actual motivating example work without making up a MutexGuard where none should exist. Have the field projection return an ordinary reference. Is this harder for some reason that having it return MutexGuard?

> I don't think such constraints would really work. My company might have 4 domains on different TLDs and then end up needing to use 4 different CAs. Geography doesn't really apply on the Internet.

I'm not sure it needs to map out this way. In the last few years people have gotten used to the idea that ACME means that the client interacts directly with the actual CA, but there's another model that at least used to be widespread: certificate brokers. Right now, I tell my ACME cliejnt to get me a Let's Encrypt certificate, and Let's Encrypt validates my request and makes it happen.

But what if I instead tell my ACME client to talk to a broker? The broker would arrange with various CAs for whatever portions of the overall namespace it supports, and it would give me TOS that those CAs find acceptable. And it would then forward my requests to appropriate backend CAs, and those backend CAs would (and would be required to by CA/B rules) validate my request. And I'd get a cert without particularly caring who the backend CA is.

The root stores would treat the backends as fully responsible for validation.

I don't know whether the current ACME model actually supports this very well. The tricky bits I can imagine mostly involve ACME account identification, CAA record details and dns-persist-01. If I authorize my ACME account (held with the broker) for my domain, the backend needs to be able to validate, in a manner that the broker cannot forge except to the extent that it's unavoidable. So if I have account 12345 (just an identifier), then I think the backend should be able to trust the broker's assertion that the client really did convince it (with replay protection) that it's the client for account 12345. But if I have an account where the account itself indicates a public key, then the broker should not be able to forge it.

In any case, I think it's vaguely ridiculous that, right now, the UK government has essentially no say in whether Let's Encrypt may issue certificates for .gov.uk domains. (This is just an example.)

For all that DNSSEC is crap, DANE would at least mean that a domain is only vulnerable to failures of the authorities relevant to the domain.

Meanwhile there are two less invasive changes that really ought to happen:

1. A clean way for things like curl and Python to start checking CT logs like Chrome does.

2. Name constraints. It’s long past time for the CAs of the world to have name constraints enforced. A CA that is not appropriate to use for .com should not work for .com. A CA that is not appropriate to use for .ae should not work for .ae. And the CA/B Forum should should requiring that all newly approved roots and all newly signed intermediates have appropriate name constraints.

CT logs are supposed to be useful. They serve at least two major purposes: visibility and auditing. Assuming that a CA is remotely well behaved, a site owner can trust that, if a certificate has been issued, then it's in the CT log. An auditor can read a complete record of certificates issued by a CA and attempt to determine whether they all follow the rules. And a CA that issues certificates without logging them is quite likely to get caught. Some browsers won't even accept certificates that aren't logged. And anyone who sees a signed certificate that isn't in the log holds evidence that the CA is misbehaving.

Once the private key has been leaked, this is basically all pointless.

Can a site owner trust that a certificate in their name has been logged? Of course not! An attacker could be signing it on the fly.

Can an auditor read the complete record? The complete record is kind of meaningless if the private key is leaked. But the auditor already knows that the private key is leaked!

Will the CA get caught if they issue a cert that isn't in the log? Yes! In fact, all newly signed certs won't be in the log.

Will browsers that check for log inclusion be protected? Yes, because newly signed certs won't be in the log.

Will anyone who sees a signed cert that isn't in the log hold evidence of misbehavior? Yes!

One might argue that the actual change to the CT system that should be made is a way for a CT operator to insert a statement into the append-only log that they believe a signing key to be compromised and that they will therefore no longer accept certificates signed by that key.

The whole premise of CT logs is that issuance of a cert is an action taken by the CA or at least by the HSM holding the private key. If the entire private key leaks, which appears to be what happened here, then the existence of a certificate containing a valid signature means nothing at all. The CT log might as well record that every possible string of bytes has been signed.

It’s the Windows dialect of C with Microsoft quasi-Hungarian-notation type names. Whole generations of programmers have grown up with these and all too many somehow think they make sense :)

But the relevant bit is at the end, from “if” to “return”, and should be pretty accessible to anyone familiar with an imperative language who can get past the general ugliness of the code. Once that’s figured out, you can recover the password by copying and executing the rest of the function.

Am I off base, or should I be surprised that you were able to get the mentioned cert issued in the first place this recently (yesterday)? It seems unexpected that certificates are being actively issued and logged coming from a to-be-forcibly-distrusted part of the hierarchy.

The bugzilla issues mentioned elsewhere suggest at least a mostly orderly removal of trust with issuance stopped several months ago. Your new cert was issued by “CN=EM DV TLS CA - G3B,O=eMudhra BV,C=NL”, which presumably chains to the G3 root, and the bugzilla issue seems to say that G3 was going to be dropped from the root lists some time ago but that maybe it would be cross-signed by something still trusted. So I assume that something else is going on.

Was that cert issued via normal means (e.g. ACME)?

This doesn’t require any fancy analysis. You can literally read the password off it — the last bit is an oddly decompiled string comparison.

I wonder how this compares to going all-in: widen the input embedding to fit the output (post-“Hybrid Link”) latent vector and a token embedding and pass both through even when in text mode. After all, you’re paying essentially the full cost of running the latent-mode model while generating text, so why not let it latently reason at the same time?

(Or just add the vectors instead of using wider vectors - everyone seems to have good results from munging vectors together with plain addition.)

I am well aware of why this phenomenon happens. That does not mean that I think that OpenAI’s (and Anthropic, etc’s) training or harness behavior is appropriate.

Would it really have been so hard to encode an indication of whether use of the public Internet is permissible in the prompt and to train the models to not attempt to exceed authorized access?

I disagree. If I turn off web search in the config, then the tool should not search the web, thank you very much. Maybe if I very explicitly ask it to, then it should try.

The whole succeed-at-all-costs idea is a big part of why there have been so many massive security screwups lately.

It’s not exactly recent or a reveal, but I’ve caught at least several OAI models writing Python scripts to access web pages.

I can rewrite the kernel in C++ too: update the Makefile to treat .c files as C++. It’ll almost work :)

> It's an incredible engineering achievement to build in massive fans and rocket engines into a high performance car. It's truly wild.

How confident are you that the flying object in that video is a car?

Some cursory estimates suggest that one really could get several seconds of operation with enough thrust to lift a real car with a big motor and battery and seats and such, but the margins are not great. If I were designing this thing and I cared more about showmanship than about demonstrating an actual credible car, I might use the tiniest battery I could find with adequate power output (lithium titanate? small LFP?), as little motor as I could get away with, and no interior amenities whatsoever.

More cynically, I would also contemplate whether I really really needed the fancy downforce fan for this demo. After all, that’s a very controlled track and I can imagine other ways of getting a car up it.

If a function is inlined, the breakpoint can be at the end.

If you write:

    if (a)
        breakpoint();
    
    other code;

Then there two obvious ways for code to be generated, one of which puts the address after int3 in the wrong basic block.

In a good enough debugger insn length might not matter - there will be a choice of addresses, ask all belonging to the next instruction. Subtracting one and handling the case where the address is in the middle of an instruction should be good enough.

(Or just track whether the address in question is the start or end of the insn. Keep in mind that, in basically every architecture, call saves the next address, not its own.)

I’m pretty sure that even kernels from the date of that message report the trap/fault vector.

But let’s be clear. ptrace() is unbelievably crappy, and gdb is approximately as crappy.

Sadly the PR gets a detail wrong:

> Implementations are expected to optimize the code generated to be as minimal as possible for the platform. For example, on X86 it’s expected that this produces a single INT3 instruction. The goal in this expectation is to place the debugger as close as possible in the caller of breakpoint() to improve the debugging experience for users.

This is the wrong design on x86 at least with many debuggers. x86’s int3 is a trap and reports the address of the next instruction in the saved register state [0]. Most debuggers are not very clever and just use the saved address to generate the offending line of code and the call stack. But if the trap sequence is just int3, then the saved address could be outside the offending basic block or even outside the function entirely. gdb is certainly in the class of debuggers that get this wrong.

The easy workaround is to generate int3; nop for the breakpoint instead of just int3. The saved address will point to the nop and the debugger will be happy.

[0] FRED also reports the instruction length, allowing one to deduce the trapping address.

There are third-party tests that mostly validate this. Dekton appears to be rather more prone to breakage due to impact than most other countertop materials.

Many natural stones are, depending on precise application, pretty bad for exterior use.

I wish that there were well defined, common sense limits on indemnification and liability for misrepresentations.

Compare both to bona fide insurance markets. If I buy insurance, there is a defined maximum payment. And if I defraud the insurer, I get in trouble. And the insurer knows that they’re getting into, and they understand the risks and get compensated appropriately.

When some random consumer contract states that the consumer indemnifies the service provider, the consumer usually has no idea what this means and probably literally never sees the contract text. There is rarely a limit specified and, if there is, it’s probably basically a joke. And the benefit to the consumer rarely has anything to do with the risk (in fact, often the consumer pays and supposedly indemnifies the party they’re paying).

And then we get to representations. In a real B2B contract negotiated by lawyers both sides, the representations are generally relevant, everyone does them, and the replying party is expected to do due diligence. But in contracts like this Meta thing, to the extent that there is a representation that the publisher can issue a license:

a) That representation has nothing to do with the actual reason the publisher is entering into a relationship with Meta (the customer probably just wants to run ads or use business messaging)

b) The customer is extremely unlikely to have had a lawyer review the contract and Meta would not allow any good faith negotiation anyway.

c) Meta is not doing due diligence.

I feel like some combination of a, b and c should invalidate Meta’s right to rely on the representations and, in an ideal world, would even serve as evidence of bad faith on Meta’s part and serve to shift additional liability to Meta.

I don’t really understand the legal theory here. Party A (Meta) writes a contract with Party B (a business account holder) ostensibly granting A the right to scrape B’s website and a license to the content.

But why is there any presumption that B owns the content or has any right to grant this license? It’s extremely common for a publisher to license content from a third party under terms that may not allow this sort of sublicencing. What happens if the publisher can’t grant this license?

The problem as I see it is not crashes and leaks. It’s that basic features are barely functional and the UI is not very usable.

Stupid examples from recently:

- The iOS 27 Preview app’s search feature appears to be present while in markup mode but missing while not in markup mode (this is quite reproducible for me).

- Mobile Safari regularly gets into a state where the overlay showing the current website domain gets stuck obscuring an important part of the site.

- On MacOS if you accidentally switch desktops you cannot switch back until the animation from the first switch finishes.

- Spotlight is still hilariously bad.

- The MacOS Music app’s AirPlay controls are barely functional.

- If you have an excessive number of desktop apps open, finding the one you want is gratuitously difficult. Sure, the bottom dock widget is pretty, but that doesn’t make it efficient.

- While typing this message, multiple different glitchy UI elements have appeared and disappeared.

- On iOS, if the keyboard is showing and you don’t want it, tough luck.

I’m surprised you didn’t use your shiny exploit to get enough access to write a startup script or give yourself root. Or patch the driver :)

(I’ve had Astra suggest binary patches things when I don’t even ask it to.)

re: the DMA API, it’s been a while since I’ve poked at it (and I’ve only really poked seriously on x86 Xen PV), but I think there are explicit APIs for cache maintenance, and you drivers may also be able to ask for more coherent mappings depending on hardware. You’re certainly not expected to stick arch-specific flush operations in.

A decent degree of phishing protection. And passkeys are not vulnerable to an attack that can transiently read server memory.

Fair enough.

As far as I know, packages that use or could use uv-build or flit-core are in the just-copy-files category.

I haven't come up with anything using natural integer operations. I can come up with really disgusting hacks using highly unnatural integer operations, but that feels too gross to even include in this category of cheats -- if you're willing to use unit-costs unnatural integer operations, then you might as well give up: you can do literally any operation on inputs that can be kludged into a integer in constant time.

I'm literally suggesting that some company could make a little device designed to be inserted inline between an IoT or industrial device and the LAN/Internet that would, effectively, retrofit a security policy onto the device without interfering with its normal operation or requiring rework of the device. You're saying that plant operators could use an off-the-shelf firewall, too. I'm saying that using an off-the-self firewall is both weak and a pain to configure and that I think a bespoke device could do a much better job for quite a few reasons.

I don't think any goalposts have moved.

I’m highly entertained by the way the robot tightens nuts. There is no way this would work in the real world :)

(This whole thing is awesome. I think they will need to get the number of rollouts needed down before it translates well to real robots — running hundreds of thousands of rollouts on small parts with a real rollout will be a real logistical mess when cleaning up parts on the floor and dealing with everything that the robots physically break while learning.)

> The nice thing about Python packaging is that it’s standardized

And a problem with Python packaging is that it's far too flexible.

For a pure Python package, IMO every single file in the wheel should be bit-for-bit identical to a file in the source tree (with the possible exception of a manifest listing the files). If this were actually a guarantee, even just for a category of package that opted in, then:

a) The build "tool" could be replaced with a build file selector, which would often be completely trivial and could have default behavior that worked for almost every pure python package right in pyproject.toml and

b) Instead of the giant mess of sigstore and attestation and weird trusted builds we have today, we would have a straightforward proof that a wheel actually matched a git commit irrespective of who built it. In fact, the proof could be embedded in the wheel! And the proof could be verified without executing any package-controlled code.