As usual, there's a cultural issue here. I know it's entirely possible to paste those seven lines of code into your app. And in many development cultures this will be considered a good thing.
If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".
I think the fact that everyone cites the same is-number package when saying this is indicative of something though.
Like I legit think that we are all imagining this cultural problem that's widespread. My claim (and I tried to do some graph theory stuff on this in the past and gave up) is that in fact we are seeing something downstream of a few "bad actors" who are going way too deep on this.
I also dislike things like webpack making every plugin an external dep but at least I vaguely understand that.
Even there the "problem" was left-pad being used by one or two projects used in "everything".
So the problem isn't that everyone is picking up small deps, but that _some_ people who write libs that are very popular are picking up small deps and causing this to happen.
This is different because it doesn't really say that all JS developers are looking to include left-pad. But I _do_ think that lots of library authors are too excited to make these kinds of dep trees
The point isn't that everyone needs to write the same code manually necessarily. It's that an author could easily just combine the entire tree of seven line packages into the one package the create-react-app uses directly. There's no reason to have a dozen or so package downloads each with seven lines of code instead of one that that's still under under a hundred lines; that's still a pretty small network request, and it's not like dead code analysis to prune unused functions isn't a thing. If you somehow find yourself in a scenario where you would be happy to download seven lines of code, but downloading a few dozen more would be an issue, that's when you might want to consider pasting the seven lines of code manually, but I honestly can't imagine when that would be.
I feel like people have gotten used to holding phones pointing outwards in a way that only works on speakerphone.
Like I put a phone to my ear the way I have been for the last forty years and I feel like I'm old and out of touch for doing so, because I haven't seen anyone younger than me in years take a call and not just turn on speaker phone and hold the phone pointing outwards.
I'll counter argue that "large corporates" are exactly the environment with a massive legacy of VBA based Excel spreadsheets stapled together handling half the businesses most critical functions.
These redos vulnerabilities always come down to "requires a user input of unbounded length to be passed to a vulnerable regex in JavaScript ". If someone is building a hard real time air plane guidance system they are already not doing this.
I can produce a web server that prints hello world and if you send it enough traffic it will crash. If can put user input into a regex and the response time might go up by 1ms and noone will say its suddenly a valid cve.
Then someone will demonstrate that with a 1mb input string it takes 4ms to respond and claim they've learnt a cve for it. I disagree. If you simply use Web pack youve probably seen a dozen of these where the vulnerable input was inside the Web pack.config.json file. The whole category should go in the bin.
These are functional safety problems, not security vulnerabilities.
For a product that requires functional safety, CVEs are almost entirely a marketing tool and irrelevant to the technology. Go ahead and classify them as CVEs, it means the sales people can schmooze with their customer purchasing department folks more but it's not going to affect making your airplane fly or you car drive or your cancer treatment treat any more safely.
Open Facebook and scroll. Every time ICE comes up the content is exclusively positive (and no I don't feed the trolls and bring this algorithm on myself).
It's not all bots. Some people back this push, and FB is where they hang.
I don't think this stuff is why people will be pulled out of line at CBP, but it will inform why they are bounced, should they otherwise come to the attention of the authorities. They don't need a bloom filter over 1m entrants, they need something they can say "because" when they toss you out.
I like to implement independent mail systems. No SSO BS. IT enters the password into the mail client while setting up the laptop and phone. The boss can't be phished if he doesn't know his password (or if the password has no use on the internet).
I also like to put everything behind a VPN (again no SSO). But the bigger the company gets, sooner or later this will come to an end. Because it's not "best practice" to not be phishable. Apparently what is needed are layers and layers of BS "security" products that can be tricked by a kid that has heard of JS. https://browser.security
Those checklists are frequently answered like this:
"Hey it says we need to do mobile management and can't just let people manage their own phones. Looks like we'll buy Avanti mobile manager". Same conversation I've seen play out with generally secure routers being replaced with Fortigates that have major vulnerabilities every week because the checklist says you must be doing SSL interception.
Easy answer here - nearly every LOB app we have uses MSSQL.
I've had engineers want to talk about syncing it to MySQL using some custom plumbing so that they can build a reporting infra around their MySQL stack, but it's just another layer of complexity over having code just use Microsoft's reporting services.
I'll add, having finance people with Excel really like being able to pull data directly from MSSQL, they do not like hearing about a technican's python app.
That movie will be quite case study in media bias. Depending who is reporting on my social media feed, it was either the most successful movie of all time with every single showing at capacity, the run being extended, and gen z girls being the main demographic for a movie certain to clean up awards. Or it was a flop that lost money.
It can be both! You can fill up the seats with people that you pay to watch it!
You can also look it up on Rotten Tomatoes where it currently has a 99/100 audience score and then look it up on IMDB, where it has 1.3/10. I personally believe none of the two are completely legitimate, but I think it's pretty obvious which of the two is more astroturfed.
Instead of both-sides-ing this, you can look at objective data. Here's BoxOfficeMojo: https://www.boxofficemojo.com/release/rl4287397889/. Right now it says $8.1M in the US, $75k worldwide. Not bad for a movie that cost $40M to make and about as much to market, huh?
One rationalisation I've heard is that it made more money than expected for a documentary. If we take that at face value, it's worth asking why Bezos felt the need to pay Melania tens of millions more than the budget for the typical documentary.
Your case study in media bias writes itself. All it took was a google search.
If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".
reply