Denvercoder9

DESIGN.md:

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...

I'm not up-to-speed with the current state of sandboxing in browsers, but in principle it's (on modern operating systems) not especially hard for them to sandbox the decoding into a separate process with basically no privileges beyond rendering a video stream. It's a bit trickier if we're only considering demuxing and delegating decoding to the hardware, but that's a much smaller attack surface.

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.

can't all the banks just agree to enforce 3DS

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.

Account Updater functionality isn't necessarily even involved there. In the end whether to accept a transaction is up to the issuer, and quite often they'll keep accepting recurring transactions on otherwise outdated card information.

Indeed, I suspect that's what went on here. I don't think there even exist 99 providers of what's customary called a digital wallet (e.g. Apple/Google Pay), and there's no definitely no single person that uses 99 of them.

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.

merchants can’t select what level of security they want from the credit card processor

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.

but things like this are a matter of negotiation between the card issuers and the merchants.

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

I'm not advocating for delaying the disclosure at all; my point is, if you see your initial disclosure to the kernel didn't go anywhere, to be responsible is to put in a little extra effort to ensure the fix is picked up before you disclose.

The situation with e.g. BlueHammer is fundamentally different: there, the only party that could act on it (Microsoft) ignored them. In this case, the parties that could act on it weren't notified at all.

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.

I don't know what exactly can load this module

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

In my world, responsibility is not just checking a box of following industry practice. Responsibility, as Wikipedia puts it on their social responsibility page, is working together with others for the benefit of the community. And yes, sometimes that's a bit larger burden than would ideally be the case. It's an imperfect world, after all -- and let's not forget the disclosure as it happened also placed a larger burden than ideal on people scrambling to patch.

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.

None of the distros were.

Not having the module loaded doesn't mean you're not vulnerable, the kernel loads the module on-demand when it's needed. I tried the exploit on such a system, and it worked.

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.

Two things can be true simultaneously: the Linux kernel ecosystem should have done better at communicating this to their downstreams, and publicly sharing the exploit was irresponsible.

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.

There's no contradiction, the point is that Bob is able to produce valid output using LLMs, but only while he himself is being supervised; and that he doesn't develop the skills to supervise independently himself in the future.

That's why it went beyond web, and why all modern native UI frameworks have a similar model these days.

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

It would be infinitely simpler if one could simply 'cross-compile' down to older symbol versions, but the tooling does not make this easy at all.

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.

why would it be that way?

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.

The same's true for the radio on a Raspberry Pi, though.

So yes, in theory you can always deploys sets of compatible services, but it's not really workable in practice: you either need to deploy the world on every change, or you need to have complicated logic to determine which services are compatible with which deployment sets of other services.

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.

Some smartphones are locked down by their vendors. There's plenty of options to get full root access on something that's for all intents and purposes a smartphone, especially if you don't particularly care about warranty and/or keeping commerical apps functional.

Maybe the database upgrade from v(N-17) to v(N-16) simply takes a while, and hasn't completed yet? Or the responsible team is looking at it, but it doesn't warrant the whole company to stop shipping?

Being 17 versions behind is an extreme example, but always having everything run the latest version in the repo is impossible, if only because deployments across nodes aren't perfectly synchronised.

https://github.com/jj-vcs/jj

Blue/green might allow you to do (approximately) atomic deploys for one service, but it doesn't allow you to do an atomic deploy of the clients of that service as well.

Good luck getting 100+ devs to all use the same logical commit style

The Linux kernel manages to do it for 1000+ devs.

If my change is small enough that it can be treated as one logical unit, that will be reviewed, merged and (hopefully not) reverted as one unit, all these followup commits will be amends into the original commit. There's nothing wrong with small changes containing just one commit; even if the work wasn't written or committed at one time.

Where logical commits (also called atomic commits) really shine is when you're making multiple logically distinct changes that depend on each other. E.g. "convert subsystem A to use api Y instead of deprecated api X", "remove now-unused api X", "implement feature B in api Y", "expose feature B in subsystem A". Now they can be reviewed independently, and if feature B turns out to need more work, the first commits can be merged independently (or if that's discovered after it's already merged, the last commits can be reverted independently).

If after creating (or pushing) this sequence of commits, I need to fix linting/formatting/CI, I'll put the fixes in a fixup commit for the appropriate and meld them using a rebase. Takes about 30s to do manually, and can be automated using tools like git-absorb. However, in reality I don't need to do this often: the breakdown of bigger tasks into logical chunks is something I already do, as it helps me to stay focused, and I add tests and run linting/formatting/etc before I commit.

And yes, more or less the same result can be achieved by creating multiple MRs and using squashing; but usually that's a much worse experience.

Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.

The article is from 2019, things might also simply have changed since then.

That's true for local hooks, but neither a dishonest person nor an LLM can bypass a pre-receive hook on the server (as long as they don't have admin access).

GPS gets its time from NIST (though during this incident they failed over to another NIST site, so it wasn't impacted).