YANPMWTF
-
Or is TFA TRWTF? Or just a rant about something that's not really possible to fix (INB4 don't use node).
-
@boomzilla 5 on "easily fixed 7 years ago"
-
@boomzilla said in YANPMWTF:
Or just a rant about something that's not really possible to fix
It's a by-product of the way the node ecosystem does things.
Traditionally, you would have a runtime environment, a tool set, and source code. Source code is inspected for vulnerabilities. But, in the npm world, tools and runtimes are pulled in exactly like libraries are. Sometimes, for example with some CSS compilers, the tools actually run at runtime.
My first experience with this was when I tried to build an Angular app with Visual Studio. I was like "node, WTF". Looking into it, node is necessary to run the npm package that compiles typescript to javascript. WTF, Microsoft invented that and VS has the tool built in.
You can develop securely with node and npm... you just have to always be thinking security and always consider if that npm package is worth the hassle of upgrading and testing it as often as will be necessary.
-
@boomzilla I'll just go ahead and say it so no one else has to.
Don't use node.
-
@boomzilla said in YANPMWTF:
Or just a rant about something that's not really possible to fix
It's a by-product of the way the node ecosystem does things.
Traditionally, you would have a runtime environment, a tool set, and source code. Source code is inspected for vulnerabilities. But, in the npm world, tools and runtimes are pulled in exactly like libraries are. Sometimes, for example with some CSS compilers, the tools actually run at runtime.
My first experience with this was when I tried to build an Angular app with Visual Studio. I was like "node, WTF". Looking into it, node is necessary to run the npm package that compiles typescript to javascript. WTF, Microsoft invented that and VS has the tool built in.
You can develop securely with node and npm... you just have to always be thinking security and always consider if that npm package is worth the hassle of upgrading and testing it as often as will be necessary.
Running
npmundersudohelps this not at all.
-
It's a classic tale of a good idea sabotaged by developers' inherent
. None of this would've been a problem if vulnerable packages were being fixed. But they aren't, so instead of appearing every so often and then disappearing when people update, the warnings pile up indefinitely and not a single fuck is given.
-
@Gąska I briefly cared about the warning I saw today.
-
@Gąska I would say it's a tale of developer's pathological ADHD. You can't put the entire blame on nerd community producing fucktons of garbage vulnerable packages and then forgetting about them if the ecosystem was designed to be exactly that and would not otherwise even exist.
-
@Applied-Mediocrity said in YANPMWTF:
@Gąska I would say it's a tale of developer's pathological ADHD. You can't put the entire blame on nerd community producing fucktons of garbage vulnerable packages and then forgetting about them if the ecosystem was designed to be exactly that and would not otherwise even exist.
Yes. Yes you can put the blame on them. Well perhaps you'd have to reserve maybe 1% for the people who created the said environment, but that's more or less the same people.
After all, they could do better. Hell, they should do better. So yes, they deserve the blame.
-
@Steve_The_Cynic said in YANPMWTF:
After all, they could do better. Hell, they should do better. So yes, they deserve the blame.
When I press the button, that'll be what I say to myself. If I have time. If it works I won't have time. Neither will you.
-
It's a classic tale of a good idea sabotaged by developers' inherent
. None of this would've been a problem if vulnerable packages were being fixed. But they aren't, so instead of appearing every so often and then disappearing when people update, the warnings pile up indefinitely and not a single fuck is given.Yes,
, but usually because the software dependencies are updated faster than the high level software built on top of them (which can go long periods without change). Patches come out all the time for dependencies, but they're usually only applied when the software that needs them has to be updated.Note that, as described in TFA, all of these vulnerabilities have fixes available, they're just not applied.
-
It's a classic tale of a good idea sabotaged by developers' inherent
. None of this would've been a problem if vulnerable packages were being fixed. But they aren't, so instead of appearing every so often and then disappearing when people update, the warnings pile up indefinitely and not a single fuck is given.Yes,
, but usually because the software dependencies are updated faster than the high level software built on top of them (which can go long periods without change). Patches come out all the time for dependencies, but they're usually only applied when the software that needs them has to be updated.Note that, as described in TFA, all of these vulnerabilities have fixes available, they're just not applied.
I'm (or my organization) is in this post and I don't like it.
Ok, most of the worst of our vulnerabilities are our own darn fault (don't ask about the passwords). And a bunch of the others are only used for testing (why that's part of the production build is another story). But there are plenty of the "we just haven't updated the dependencies" audit failures.
-
@Benjamin-Hall But what about the critical vulnerability of a potential specially-crafted SVG file that'll result in some slowdown when parsing CSS?
-
@Benjamin-Hall But what about the critical vulnerability of a potential specially-crafted SVG file that'll result in some slowdown when parsing CSS?
Yeah, stuff like that was part of what I had in mind in the OP. That's a big meh. OTOH, stuff that can affect your dev server could result in a supply chain sort of attack on your machine. That could definitely be bad, even though it probably doesn't matter for your end product.
-
@Benjamin-Hall But what about the critical vulnerability of a potential specially-crafted SVG file that'll result in some slowdown when parsing CSS?
Joke's on them. It's already slow. Not due to parsing CSS, but for many other reasons. Including our "not quite SPA...but not quite server-rendered either" abomination of a semi-PHP, semi-Vue.js (but without a real build system so everything is in one giant file except for the parts that get jQueried in in a way that totally confuses the browsers) mess.
-
-
@HardwareGeek said in YANPMWTF:
@Benjamin-Hall said in YANPMWTF:
don't ask about the passwords
What passwords?
Not quite. We do require passwords. But...yeah.
-
@HardwareGeek said in YANPMWTF:
@Benjamin-Hall said in YANPMWTF:
don't ask about the passwords
What passwords?
You were specifically told not to ask about them.
-
@HardwareGeek said in YANPMWTF:
@Benjamin-Hall said in YANPMWTF:
don't ask about the passwords
What passwords?
You were specifically told not to ask about them.
Which is, of course, exactly the reason I did ask about them.
-
@HardwareGeek said in YANPMWTF:
@HardwareGeek said in YANPMWTF:
@Benjamin-Hall said in YANPMWTF:
don't ask about the passwords
What passwords?
You were specifically told not to ask about them.
Which is, of course, exactly the reason I did ask about them.
I was a teacher for long enough to know exactly what I was doing there.
-
@error_bot tvtropes specific denial
-
TV Tropes said in https://tvtropes.org/pmwiki/pmwiki.php/Main/SuspiciouslySpecificDenial :
Suspiciously Specific Denial
Helmet: Did you see anything? Sandurz: No, sir! I didn't see you playing with your dolls again! Certainly no one is describing Suspiciously Specific Denial here, so that people will understand what the trope is about. And this sure isn't an opening gag to preface it. And this surely isn't an unnecessary prolongation of the gag to make it, supposedly, funnier.
A False Reassurance works because the speaker is being vague and non-specific enough to pull the wool over someone's eyes. A Suspiciously Specific Denial, on the other hand, fails because the speaker is Saying Too Much. This may be unintentional, such as when the speaker is panicked, is a Bad Liar, or perhaps just a little stupid. Often used to establish that you're Most Definitely Not a Villain.
Sometimes, this is used more deliberately, such as when the speaker is definitely not trying to give out information that they shouldn't but doesn't want to be too obvious about it (...Or So I Heard may follow). The Trickster may also use it as the misdirecting component of a Batman Gambit, Infraction Distraction or Kansas City Shuffle; by making an oddly specific denial that is actually true, the mark may be led to believe that the denial is false. (For example: the mark is told that there aren't 2,300,009 invisible vampire ghosts — so the mark believes there are, when in fact there are no invisible vampire ghosts at all.) In rare cases, the speaker may be telling the truth and have no intent to deceive, but it just comes out wrong.
Oddly, it can happen in two opposite ways: the specific denial ("I won't kill you using a poisoned stiletto!") was a lie (he does, and the fact that the question and/or answer was so specific means that someone already had the answer in mind), or the specific denial was technically true, but it left so many doors open that it was suspect anyway (he kills the other guy with a non-poisoned stiletto, or a gun). Either way, the result is the same - when someone is more specific than they need to be, it's a good sign something's wrong. Bonus suspicion points if the statement was made apropos of nothing.
This is a favored tactic of a Tsundere who got caught being dere — in fact Memetic Mutation has made this the motto of the Tsundere ("Stupid [love interest]! I-it's not like I'm [doing something affectionate] because I like you or anything!")
It's also related to Compliment Fishing, where someone will make a suspiciously specific Self-Deprecation in the hopes that other people will spot the denial and contradict them.
When the speaker is assumed to be telling the truth, a listener might suspect this if the denial was expected to be more general.
When The Mafia uses it, it's the Legitimate Businessmen's Social Club. If you insist that you'd NEVER make a Suspiciously Specific Denial (while doing so), then it's I'll Never Tell You What I'm Telling You!. This is not comparable to Bad Liar; a character who invokes this trope could certainly be a bad liar, but when used alone it's not indicative of Bad Liar.
Characters who are Lawful Stupid (or Oblivious to Love in the case of the Tsundere) may take the statement at face value.
This is frequently seen on Police Procedurals when someone under a confidentiality requirement (lawyers and doctors, mostly) make a very specific inclusion or omission in an answer to the investigators that provides a clue where they should be looking.
It is also a device in mysteries. Someone makes a statement or denial including information that they could only know if they were the perp. "Well, I didn't shoot him!" "No one ever mentioned how he was killed." That may also be related to You Just Told Me. This is the reason why it is also Truth in Television, especially why lawyers frequently advise not to make any reply to any allegation.
A suspiciously specific denial can also be part of a Gilligan Cut (eg, "You'll never get me to wear a pink polka-dotted tutu with a blue sweater and purple high-heels"), Description Cut ("It's not a run-down house with holes in the roof, broken windows, and blood-stains on the kitchen walls"), et cetera.
See also: Could Say It, But....
Super Trope of Have I Mentioned I Am Sexually Active Today? and People's Republic of Tyranny.
Compare Asbestos-Free Cereal, I Never Said It Was Poison, It's for a Book, Nightmare Fuel Station Attendant, ...Or So I Heard, Overly Narrow Superlative, Saying Too Much.
Contrast False Reassurance, Blatant Lies, and Implausible Deniability.
Compare/contrast with Hesitation Equals Dishonesty.
Often accompanies Mock Surprise Reaction.
-
@Benjamin-Hall said in YANPMWTF:
But there are plenty of the "we just haven't updated the dependencies" audit failures.
We use the dependency audit stuff in Github's dependabot to sort that out. OTOH, we use Maven and pip and not the dumpster fire. We'd get more out if we could use tighter version requirements in our pip requirements, but we support too wide a range of targets for that.
Dependabot is nice in practice. It's set to look for things to update once a week, and reviewing and okaying things is typically a few minutes work every Monday morning. (Occasionally it's more effort than that, when an API change needs to be handled, but that was probably coming anyway.) The bot does the rest. We only have two dependencies where we can't do that, and that's because the libraries in question have undergone several major version updates and work nothing like they used to. (Security delegation across domains is a tricky topic at best...)
-
npm audit: Broken by Design — overreacted
