> The world railway map

There is also something about train routes, but these messages are conflicting... also you don't immediately see explanation that it is curated d that's why people complain about missing routes.

Really hard to understand purpose when visiting first time.

Rest of us have some chance to stand against persuasion.

This is example. There are _bad_/_hard_/_dark_ jokes about women, grandmas, blacks, whites, east-asia. They have place - unless you're harming someone they are _ok_ for situation.

But only for situation. When recorded, stored and reheard years after it's not longer that situation. By recording, you're basically extending every private situation to infinity.

People in private situation, in close groups behave in ways they consider private - they cross boundaries, they "challenge" authorities/boundaries and it's ok.

It's not ok to take this freedom by assuming you can't say anything controversial in any setting.

Dark jokes and strong opinions are example - you something filthy - let's say dark Holocaust/Nazi joke but funny in situation In group that accept it and it's ok. But if it's recorded, it'll stay forever and will surface in most unexpected moment, like job interview or some other screening by gov/corpos.

Don't say that dirty jokes should be punished in future if in given situation they were received as ok and only later someone else, not in situation is going to judge it

you're wrong, moderation is needed in ventures like this

The other Hail Mary reference is on top of HN today.

Well done Andy Weir.

No, it was to search. Search within resources that are external to Google. Like index in library.

(stating the obvious). Starting article like this - that is with attempt to rewrite history - is very sad.

Key issue here is cache poisoning, that is feature/bug that exist in utility functions/actions provided by Github.

Even if there was misconfiguration on tanstack side, then root cause is on. GH for even allowing insecure workflows to interfere with secure ones.

Here people are trying to fix defaults - not to write cache in insecure context -> https://github.com/actions/cache/issues/1756

(even if sufficiely smart attacker would find the key somewhere and skip this kind of prodection, not sure where but write-allowing-key it must exist somewhere in runtime if actions/cache can us it)

Someone else on this thread:

> On GitLab even if you set the same cache key it will not cross between unprotected and protected runs.

They basically confirm that this whole provenance only proves origin. That origin was broken/flawed and was coerced to do something bad. (?)

Again, untrusted workflows can't write anywhere - cache poisoning was they key problem. If cache would be clean, release build/run would be clean too.

Well, one of simplest mitigation is that `pull_request_target` jobs shouldn't have access to write to cache, they can read for performance, but not write.

To extrapolate rule, the `pull_request_target` shouldn't have any ways to invoke external side effects.

In most strict scenario, they shouldn't have access to network at all ... or only to GET - where safeUrls are somehow vetted previously on main, derived from yarn.locks and similar manifests. Pita to setup, no wonder nobody does that.

Anyway, interesting approach for up to medium pages (not apps!). Totally not replacement for react.