> Each rule below is enforced mechanically by the skill, not left to vibes.

> R1. Repo docs are the memory; not in HANDOFF.md = didn't happen

SKILL.md:

> Not in docs/HANDOFF.md = didn't happen. Refuse to judge results that exist only in conversation or builder chat output.

"Mechnical enforcement" just means "prompting the LLM a bit extra" these days? It (still) amazes me how much effort and tokens we expend on what could and should be a two line script...

A manually run ffmpeg on the command line does nothing to restrict its privileges, and its security model has very little interest in doing so, while browsers very much have.

They could, but it's one of those things that really only work if everybody joins. Because 3DS is rarely used right now, a portion of merchants don't even support it, so if you start enforcing is as a single bank, your customers will start complaining their card doesn't work. The banking industry in the US is also more decentralized than in the EU, so getting everybody to join in simultaneously is hard.

The window of opportunity for 3DS has also more or less passed, the industry is moving on to the next generation of tech (wallets/tokenization), that should be both easier to use and more secure.

It's bad service from GP's card company though, with network tokens they should be able to see which specific token was abused, and revoke just that one.

That really depends on the processor; many processors do allow merchants specify your acceptance rules in quite deep detail.

There's a bit of a dichotomy in the processor market: on one side you have those that aim to make it simple for their customers and unburden them, while on the other side you have those that expose all the complexities and give intricate controls. The first side won't allow you to specify security requirements, while the second side will give you a hundred options (of course there's also processors positioning them in between). The two sides generally target different customers.

Not necessarily, the EU has mandated strong customer authentication by law (PSD2), and as a result has practically universal 3DSecure support.

I'm also not proposing delaying the disclosure to the general public at all. They already waited 30 days with that, that's fine. Just look a bit further than your checklist of only contacting upstream, and send a mail to the distributions if they haven't picked it up a week or two before.

Well, for one thing, opening an AF_ALG socket, as the exploit does.

And it's not as if I'm asking for a lot of effort. One mail to the security team of a popular distro "hey, we have found this LPE that we'll release with exploit next week, it's patched upstream already in this commit, but you don't seem to have picked it up" would likely have been enough.

However, not having the module loaded does mean that in normal operation you don't need the module, so the proposed mitigation of disabling the module is safe in the sense that it won't disrupt anything.

It is not the responsibility of the initial reporter to communicate to distributions, but the fact that those responsible failed to do that, doesn't give everybody else a free pass.

It's more the other way around, this model started on desktop (eg WPF) and then React popularized it on the web.

It's definitely not easy, but it's possible: using the `.symver` assembly (pseudo-)directive you can specify the version of the symbol you want to link against.

It allows (among other things) the glibc developers to change struct layouts while remaining backwards compatible. E.g. if function f1 takes a struct as argument, and its layout changes between v2 and v3, then glibc_v2_f1 and glibc_v3_f1 have different ABIs.

There's a bigger problem though: in practice there's almost always a client that you don't control, and can't switch along with your services, e.g. an old frontend loaded by a user's browser.