And this is why I hate all web development and the fact that most jobs are web bs these days. Everything has so much crud baked in and including twelve modules with a million functions just to do anything is the norm.
Giving my back my beautiful optimized assembly dangit.
We have to work under the assumption that most development is done by inexperienced or, to put it bluntly, bad programmers. I would MUCH rather have bad JS code than bad assembly. One may crash a single tab in my browser, the other may crash my entire computer.
There's a string stating that the code should not be passed or the employee will be fired. I'd assume this was a test to see if an employee meant to be doing code review was actually doing them. Spoiler, they were not, as OP said they found this in production code.
I'd go a step further and I suspect it's a peppering string (i.e. fixed string you add to hashes to defeat rainbow tables). I'd really hope it isn't as you mentioned because gosh that sounds like a toxic workplace if someone is just leaving landmines around purely to get someone fired.
More like, you know damn well that Jim keeps passing code reviews without reading a line in them, he's been talked to, still does it, and you need something actionable to prove it so that you can get someone's ass in his chair who does their job.
From the stories I've heard from corporate software employees, this does sound like exactly the kind of thing you gotta do to show some manager the guy is buddy-buddy with that they're actually not doing their job. And even then they didn't listen.
No, I don't think so - it's just a dick move to go out of your way to sabotage someone. If they're fucking up just visit their existing mistakes - don't waste time contriving new ones.
My guess is a "solution" to the age-old problem of needing to store a secret in a file that the user can download, thus making the entire system insecure.
This "solution" appears to be either that the string itself is so outrageous that the user would not believe that it's the real secret when it is in fact the real secret, leveraging security through obscurity, or else it's there in place of the real secret that cannot be revealed under pain of death firing, and therefore is accidentally being used instead of that intended secret... so it's not secret after all.
Unless they're doing something incredibly clever to substitute that secret string for the real thing when the time is right and doing it in such a way that the user can't intercept, someone's getting fired.
No, it's not. It's part of React internals that you shouldn't use because your app will break. It's a warning for developers using React. It's not a secret of any kind.
You should really be using a pre commit hook to catch secrets. Admittedly it may not have caught this, but manual review is (clearly) not always sufficient.
It's an internal inside of React.
https://github.com/facebook/prop-types/blob/4de0644a10a554d0a556daa39f029369bc007ea5/lib%2FReactPropTypesSecret.js#L10
Crazy what other commenters are coming up with.
So, we have to blame github user acdlite?
So using react will get you fired? I knew it!
What an absolutely shitty peppering string.
The code file has 32.171 lines, at least after beautifing it. 1MB fucking js code.
And this is why I hate all web development and the fact that most jobs are web bs these days. Everything has so much crud baked in and including twelve modules with a million functions just to do anything is the norm.
Giving my back my beautiful optimized assembly dangit.
We have to work under the assumption that most development is done by inexperienced or, to put it bluntly, bad programmers. I would MUCH rather have bad JS code than bad assembly. One may crash a single tab in my browser, the other may crash my entire computer.
Unless you're using js in your hardware drivers it's very unlikely to bring down the entire computer
But with the state of software development maybe you are /o\
Dude what? The other guy implied that bad JS would kill a browser tab, not your computer.
Me: Can I have (small template parser)?
Stackoverflow: No, we have (small template parser) at home.
Small template parser at home: Full-stack web framework
Don't worry, this file is likely the output of a bundler.
What am I looking at here?
There's a string stating that the code should not be passed or the employee will be fired. I'd assume this was a test to see if an employee meant to be doing code review was actually doing them. Spoiler, they were not, as OP said they found this in production code.
I'd go a step further and I suspect it's a peppering string (i.e. fixed string you add to hashes to defeat rainbow tables). I'd really hope it isn't as you mentioned because gosh that sounds like a toxic workplace if someone is just leaving landmines around purely to get someone fired.
More like, you know damn well that Jim keeps passing code reviews without reading a line in them, he's been talked to, still does it, and you need something actionable to prove it so that you can get someone's ass in his chair who does their job.
From the stories I've heard from corporate software employees, this does sound like exactly the kind of thing you gotta do to show some manager the guy is buddy-buddy with that they're actually not doing their job. And even then they didn't listen.
Would that imply that all quality control is evil?
No, I don't think so - it's just a dick move to go out of your way to sabotage someone. If they're fucking up just visit their existing mistakes - don't waste time contriving new ones.
So when TSA sends fake guns and bombs through luggage, it's not qa, it's just a dick move to sabotage them?
My guess is a "solution" to the age-old problem of needing to store a secret in a file that the user can download, thus making the entire system insecure.
This "solution" appears to be either that the string itself is so outrageous that the user would not believe that it's the real secret when it is in fact the real secret, leveraging security through obscurity, or else it's there in place of the real secret that cannot be revealed under pain of
deathfiring, and therefore is accidentally being used instead of that intended secret... so it's not secret after all.Unless they're doing something incredibly clever to substitute that secret string for the real thing when the time is right and doing it in such a way that the user can't intercept, someone's getting fired.
No, it's not. It's part of React internals that you shouldn't use because your app will break. It's a warning for developers using React. It's not a secret of any kind.
I bet the guy who said "looks good to me" still has a job too.
You should really be using a pre commit hook to catch secrets. Admittedly it may not have caught this, but manual review is (clearly) not always sufficient.