A promise like that just isn't binding, things can change in 2 years, the managers themselves may have moved and been replaced with different people. A bird in the hand is worth many birds three years from now.
"Proteins" is not one thing, it's a class of many different things made from amino acids. Same as the "peptide" craze you might have heard of, except proteins are bigger.
Antibodies don't have to bind only to proteins, it could be some lipid, carbohydrate, any molecule big enough. Most of the time it's some protein, but it's not an allergy proteins in general.
It's not exactly uncommon, it's basically C's equivalent to exceptions. It lets you avoid having to do an extra error checking branch after every fallible operation and can quite significantly speed up the happy path of a language VM.
I know but I don't think the risks justify using this, as demonstrated here. "It's fine when it's used correctly" except it's so hard to use correctly. It completely messes up any analysis of codepaths because you have this "time travel" footgun that can bypass everything.
Exceptions aren't great for that either, but languages that feature them at least have the tooling and support features to make them work. C has no destructors or anything to handle exception unwinding cleanly. Scheme has call/cc, but scheme has a big runtime and garbage collector to deal with the fallout.
Let the branch predictor do its job and implement error checking properly, I say. If performance matters so much that you worry about pipeline flushes and icache thrashing, surely you wouldn't be using PHP anyway.
setjmp, longjmp and gets are 3 function I would absolutely ban in any C codebase I would be responsible for. Maybe strncpy too. and strtok. C is fun.
This is all well and good, I'm not saying it's wrong, but if real world benchmark results of "letting the branch predictor do its job" indicate a 10% performance regression, I would understand why such a change wouldn't get merged even if it was proposed. "Just don't make mistakes" is, for better or worse, the modus operandi in C.
It's C's equivalent to exceptions, except without any of the stuff that might actually make exceptions safe and reasonable to use in other languages.
There's no automatic cleanup of anything, no built-in way to even register things for manual cleanup, and it doesn't even consistently save/restore the values of your local variables. A local variable that was mutated between the setjmp and longjmp may end up with the old value or the new value depending on where the compiler decided to store it. The documentation does mention this and says that you need to use the volatile keyword to avoid it, but in typical C fashion there's nothing to enforce this, it's just up to the programmer to remember it.
It is extremely uncommon in C codebases because it is extremely dangerous. It makes hazards like pointer arithmetic and manually-terminated strings look like a walk in the park by comparison.
> It's not exactly uncommon, it's basically C's equivalent to exceptions.
longjmp is very uncommon, I don't recall seeing any high-quality C codebase using it, and if you want exceptions, you should pick a different language because longjmp doesn't really give you comparable semantics. It's basically saying "ok, computer, f--k my s--t up".
The fact that OOM conditions are an enduring source of exploitable vulnerabilities in PHP really should give everyone a pause. Like, that's not a thing in any sane project.
I'm surprised by CGI. The vulnerability description talks about a second request being affected by corrupted state from an earlier request. But I thought CGI only processes one request per process?
Boom. A leak. It's now a public fact, so we'll instantly see people exploiting it, right? Except that without a commit or patch fixing it, or even a suggestion of a workaround, you are searching for a needle in a haystack. It could be literally anywhere, after all!
In fact, it is so well-hidden that I have not even discovered it myself yet. But its presence is a statistical certainty due to the sheer size of the codebase, so we should assume it is somewhere in there. Did I just doom every W11 user, or are perhaps embargoes at least somewhat useful?
> I feel like all "non-inner-circle people" here are taken for a laugh. OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix, and then leave the rest out to dry
Had they just kept this between themselves and the vendor this would've been effective.
Instead they selectively released it to various parties one of which promptly leaked it.
I hold eMudhra's private key. I generate a cert signed by their intermediate on my box. eMudhra didn't issue the cert, so it is not sent to any CT logs, and I have no SCT to put in the cert.
I think I might just be talking past you. If your point is "anyone with these broken eMudhra keys can attack users without caring about CT", that's totally true --- it's just that browser/no-browser doesn't factor into it. I'm really only on this subthread because of the notion that CT enforcement requires browsers.
Right, I think I'm with you that browser/no browser shouldn't be a factor. I think I'd like to hear from Rust and Go webpki people on whether we could help the ecosystem enforce CT.
My point is more that as a user of a high-level library like reqwest, I'd like to talk safer defaults when root CAs are in use
I believe Android updates things like CA certs independently of their monthly security patch. I'm not sure Android 12 uses the same system, but on newer Android I think those are shipped via Google Play system updates, which don't require waiting for the phone vendor.
Yeah, in Android 14 they separated it out so that the CA store can be updated from Google Play. Versions below that you're reliant on the manufacturer to ship updates.
I don't see how this happens in a C++ function, since breakpoint() is not noreturn you'd have to be doing something very strange for the next instruction to be outside the function. It's possible some debuggers will show the next line, and even then that seems like a debugger QoL issue that's fixable pretty mechanically. A soft breakpoint can come from CD 3 or CC, even if you don't get the instruction length from the CPU there aren't that many possibilities. I'm sure we don't need everyone to start inserting extra NOPs to get the desired behavior.
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.)
Agreed, and just to make it shorter and clearer; when you resume a debugger, it resumes at that next address. If it's outside a basic block, it's because in the absence of a debug break, it was about to go off the rails anyway, nothing to do with the break.
reply