ua-parser-js VS Laravel

Just look at all the big companies doing it

https://faisalman.github.io/ua-parser-js/

This project is backed under MIT License, special shout out to project UA-Parser, as liguard uses a piece of its source-code.

With NPM, what's actually published is not what's in the git repo, so it's harder to inspect/review vulnerabilities or hijacking. With composer, what's in git _is_ what composer pulls (with the exception of rules in .gitattributes to exclude files etc), making it much easier to trace. One such example: https://github.com/faisalman/ua-parser-js/issues/536

Composer packages are vendor namespaced, so hijacking an abandoned package is not possible (and it is with NPM), some examples like https://www.theregister.com/2021/08/10/github_npm_package/

Sure, I suppose in theory it could happen with other ecosystems, but for some reason it doesn't. It sure seems to just keep happening in NPM though.

From the other side, npm package may be hijacked(as it happened recently for ua-parser-js and to other packages earlier). To mitigate that, I don't know, probably, subscribing to some security digest would be the most helpful.

On Oct. 22, 2021, developers of a very common NPM package, ua-parser-js, discovered that some attackers uploaded a compromised version of the package containing malware for Linux and Windows, and were capable of stealing data (at least passwords and cookies from the browser).

Since Neovim 0.5 release (which has full Lua support) I see more and more amazing Lua plugins being developed, and I think this trend will likely to continue. But I recently got more concerned about security risks associated with the way Neovim plugins being installed and used (especially after seeing recent compromises like ua-parser-js or coa). Installing typical Neovim plugin is basically downloading and executing random code from the internet on your machine with your user privileges, so hijacked or deliberately malicious plugin could potentially do a lot of damage (like stealing keys/passwords, installing keylogger or just rm -rf / for fun).

thread about compromise https://github.com/faisalman/ua-parser-js/issues/536

Hope this saves a future team from unexpected behavior resulting in (potential) production data loss.

When using Postgres, Laravel's default method for truncate uses the cascade option, which will ignore foreign key constraints and potentially wipe large amounts of data with no confirmation or warning.

It was originally introduced in 2018: https://github.com/laravel/framework/pull/26389/files

Here are two threads on it if you are curious: https://github.com/laravel/framework/issues/29506

I am just exploring middleware in this post, but as you can see this is quite a different approach than we've seen historically. I sat there scratching my head, "How do I set up my own middleware? How do I change the defaults?" I had to explore the Illuminate\Foundation\Configuration\Middleware class to find out.

For example check out this issue I reported on their side: https://github.com/laravel/framework/issues/49089

It does not mean you should absolutely use it everywhere, but it can make sense for your case. Many frameworks, like Laravel use it to compose new projects.

https://github.com/laravel/framework/blob/00894b89e42a9d707c...

Even Tinker is a few lines of code to extend PsySH and credit is barely given.

Taylor Otwell is a fiend for creating wrappers around solid open source libraries, using PHP magic and encouraging bad practices, all just to breed an ecosystem ultimately to land him a Lambo, fuelled by amazing open source foundations that have barely been contributed back to by him.

This same system has been used in Laravel since version 4.0* albeit in the more PHP plain way, using call_user_func_array (Laravel Model Class).