201–210 of 276 posts
I'm fumbled around a bit and got it working, but not entirely sure if this is how it really works: have a look at https://github.com/ejpir/CVE-2025-55182-poc
Delete this distraction to genuine blue teamers and stop shitting up the information landscape with this utter hogwash.
This is why infosec is dead.
https://github.com/ejpir/CVE-2025-55182-poc/issues/1#issueco...
Earlier quoted context omitted.
Eval has been known to be super dangerous since before the internet grew up and went mainstream. It is so dangerous that to deploy stuff containing it should come with a large flashing warning whenever you run it.
Half of web map solutions rely on workers, which can't be easily loaded from 3rd party origins, so are loaded as blobs. loading worker from blob is effectively an eval.
Is there some sort of example exploit somewhere?
https://github.com/ejpir/CVE-2025-55182-poc
Delete this distraction to genuine blue teamers and stop shitting up the information landscape with this utter hogwash.
This is why infosec is dead.
https://github.com/ejpir/CVE-2025-55182-poc/issues/1#issueco...
Earlier quoted context omitted.
> They had minimal API changes in the last 10 years The 1 to 2 transition was one hell of a burn though; people are probably still smarting...
You aren’t wrong. I basically stopped using any OSS code backed by Google as a result. I’d pushed Angular over React[0] for a massive project, and it worked well, but the migration to Angular 2 when it came created a huge amount of non-value-adding work. Never again. I don’t even really want to build anything against Gemini, despite how good it is, because I don’t trust Google not to do another rug pull. [0] I’ve nev…
React also went through a lot of churn. (Still does.) There's no magic optimal duration for keeping API stability. Not in general and not for specific projects.
Ecosystems sometimes undergo a phase-shift. Sometimes they take a long time, based on the size. Python 3 was released in 2008, just a year before Angular 1. And the last Py2 release was in 2020, about 2-3 years before the last AngularJS version. (And of course there are many businesses running on py2 still. I know at least one.) These things take plenty of time.
Angular1 was pretty opinionated, willing to break with the tradition of just add one more jQuery plugin.
Miško was working at Google, he persuaded some people to take a look at the framework that he and Adam Abrons were tinkering with.
Angular 2 was announced in 2014 January. And then v1 still got years of support, even the component architecture was "backported" around 1.5 (in 2016?)
You can run old v1 code side-by-side in a v2+ app up until v17. (At least the v17 docs describe the process in full and later docs link to this page. https://v17.angular.io/guide/upgrade )
...
Google did a pretty good job IMHO. Google throws products under the bus, but not so much OSS projects. (Though the sate of AOSP comes to mind.)
Earlier quoted context omitted.
> Intentionally? It's RPC. Remote procedure calls. An approach that has made a comeback in the front-end space recently. There was tRPC; then react made a splash with the release of its server components; then other frameworks started emulating the approach. I think Svelte now has something similar with its "remote functions". And Solid has been working on something similar; so that SolidStart now has a "use server"…
> An approach that has made a comeback in the front-end space recently. It wasn’t really a “comeback,” RPC never lost popularity. We just called them “REST” APIs that were a barely disguised adhoc JSON RPC format with a few CRUD verbs tacked on for routing requests.
Earlier quoted context omitted.
I wish React wasn’t the “default” framework. I agree that the developer experience provided by the compiler model used in Svelte and React is much nicer to work with
React is good enough, so it's very hard to come up with a strong case to use anything else.
Why does the react development team keeps investing their time on confusing features that only reinvent the wheel and cause more problems than solve? What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering? Why won’t they invest more on solving the developer experience that took a nosedive when hooks were introduced? They finally added a compile…
Server Components is not really related to SSR. I like to think of Server Components as componentized BFF ("backend for frontend") layer. Each piece of UI has some associated "API" with it (whether REST endpoints, GraphQL, RPC, or what have you). Server Components let you express the dependency between the "backend piece" and the "frontend piece" as an import, instead of as a `fetch` (client calling server) or a (ser…
We'll see if the magic can be trusted on or if we need more explicit solutions to this, but the Next/RSC experience was vastly superior compared to writing another REST API that is never to be used with anything else than the accompanied React app, and I'd love to use it or something similar to it in the future.
The reason is probably that a REST API for a "BFF" is in many cases quite tightly coupled with the frontend, and trying to detach those in the system architecture does not separate them in some higher scheme of things. Even if the two parts could separated but would never end up used without another, the separation probably just makes an unnecessary barrier.
Earlier quoted context omitted.
Server Components is not really related to SSR. I like to think of Server Components as componentized BFF ("backend for frontend") layer. Each piece of UI has some associated "API" with it (whether REST endpoints, GraphQL, RPC, or what have you). Server Components let you express the dependency between the "backend piece" and the "frontend piece" as an import, instead of as a `fetch` (client calling server) or a (ser…
As merely a systems engineer sometimes having to create a Web app I really much appreciate the experience of building a well-separated app without layers of trivial but flaky boilerplate layers that is a REST API in a dynamic language. The Next app I built last year using heavily RSC is one of the most legible and easy-to-maintain apps I have created so far. We'll see if the magic can be trusted on or if we need more…
Earlier quoted context omitted.
Does transpilation not cover this? That's how they did JSX.
Transpilation of anything other than jsx requires a complex toolchain with layers of things like LSPs, compilers, IDE plugins, bundler plugins, etc. Frameworks that go that route typically activate this toolchain by defining a dedicated file extension (.vue, .svelte). This custom toolchain (LSP, IDE plugins) presents a lot of overhead to project maintainers and makes it difficult to actually create a viable alternati…