I wonder what percentage of pull requests are cascading updates caused by dependabot and multiple code review bots reviewing those PRs.
My belief is it is likely 1% or more. And likely coming in as an avalanche.
1,088 karma · joined December 26, 2012
My belief is it is likely 1% or more. And likely coming in as an avalanche.
You can pass your favorite rootless Docker image using `--custom-docker-image` CLI parameter.
That's the definition of a sandbox, isn't it?
Even Python has that ability now. Also, `npm run dev` is running the script with full disk access.
Heck, Vscode/Cursor will auto-execute code if you open a project. And this has been actively used in the wild https://ashishb.net/security/contagious-interview/
So, amazing-sandbox at its core is nothing but a glorified docker command generator (in default mode).
Furthermore, you can use native sandboxing on macOS if you prefer.
If neither looks serious to you, then please educate me on a better sandboxing approach.
Using a proper sandboxing(https://github.com/ashishb/amazing-sandbox) regularly will drastically limit the blast radius of these attacks.
I smelled something fishy and never ran it though.
Most people stick to default of 0. In fact, I am realizing over time that it is best to make it 7-14 days.
So, just like COVID-19 used air travel, modern malware attacks are relying on GitHub+dependabot to speed up the spread.
Even for single page website built using Vue, I would get about 5 updates a week.
And how will the project accumulate more?
> everyone knows it's gamed anyway, so why not?
Then why do they still have purchase value?
So, the source is still GitHub, right?
Which means I have to keep my FOSS project on GitHub to accumulate stars.
The fact that companies request you to star them on GitHub and the stars can be bought tells you that there is a value in these stars. [2]
Now, some astute reader, who thinks the $1 trillion global advertisement market does not influence them, will also claim that they don't care about GitHub stars.
Well, that's not how the world works.
Fake stars can propel a good project to great.
A lot of people will use GitHub stars as a currency to decide the importance of certain FOSS (or even open-core) projects.
The real lock-in is in GitHub stars [3].
1 - https://blog.nginx.org/blog/nginx-open-source-moves-to-githu...
Too many weird edge cases to deal with, especially related to Alpine using musl libc instead of glibc.
At best, your builds are slower.
At worst, certain code paths are broken.
And it was each team owning multiple internal repos of their own deployments/libraries, and not, primarily, clones of public repos.
Unlikely that those guys were real. And I did reach out to them for explanation. Only to be blocked by both!
Nothing might happen but you should be on the alert.
I was never asked to install anything. I was not even given code access (without NDA) and I did get paid with equity/money in cases there was a mutual match and we proceeded.
You can run it without root. And that's what you should do.
> No Wayland, DBus, Pipewire, proc, sys filtering.
Yeah, I don't need Wayland for CLI tools. For others, you get them inside Docker, isolated from the rest of the system. When I run `npm install`, I want isolation.
I use it every day for CLI tools
> How would you sandbox an Electron app
I haven't figured that out yet
True but that's the problem. Once you have a big enough team, it becomes an uphill battle to maintain that.
The "faster to write" advantage becomes less relevant if most code is going to be auto-generated.
The "harder to maintain" might still remain more relevant.
Python is terrible for writing big systems.
Projects whose V1 is written in Go/Rust/C++ don't normally go out and re-write V2 in Python.
The reverse is really common.
Even many famous Python packages are now Python wrappers.
And the reason was that majority of backend engineers have never worked on frontend.
At almost all big companies, the team working on the frontend problem is relatively small +and that's how it should be).
> In my experience it's the NON software engineers who tend to underestimate the complexity
Yeah. That too as well.