Largest NPM Compromise in History - Supply Chain Attack

[-]

Haplo12345@reddit

Ah yes, crypto... continuously proving that it is great for one thing: cyber crime.

[-]

AvailableTie6834@reddit

interesting, criminals prefer dollars over crypto, usually because you cannot trace dollar bills, but you can trace every single bitcoin transaction or any crypto that has it blockchain public. huh.

[-]

Haplo12345@reddit

It's pretty hard to get payment from someone overseas when demand payment in cash.

Dollar bills are also traceable--each bill has a unique serial number.

[-]

Haplo12345@reddit

I mean the US government and Fed have a fine time doing it. They've been doing it for like a century at this point.

[-]

AvailableTie6834@reddit

too bad they doesnt seem to catch many criminals with their tactics.

[-]

Haplo12345@reddit

They catch plenty of criminals that way.

[-]

AvailableTie6834@reddit

imagine using a 100% traceable currency that is open to the public to perform big criminal activities.

[-]

The comment I replied to wasn't talking about this particular way of crypto safety issues. It was talking about it in a broader sense.

Because the attack vector we are currently talking about isn't related to crypto in any way other than what the malicious code is doing, which is hijacking Chrome extensions, which are pretty shit in general, safety wise. If your code base is compromised, you may lose funds even in a normal banking system.

[-]

grauenwolf@reddit

Again, it is related to crypto. If the same attack was done against me, I would call my bank and have them revert all of the charges.

Heck, they bank would probably pre-emptively block the charges when they saw a whole bunch of unexpected transactions from unrelated people all going to the same handful of accounts.

And those accounts would be, at least in theory, registered to real people who had to show ID.

[-]

grauenwolf@reddit

I wish I could give you all the upvotes I got in this thread because you are pointing to the elephant in the room that everyone else including myself was ignoring.

[-]

grauenwolf@reddit

One of the problems in crypto currency is the mistaken belief that you can use tools to verify the validity of smart contracts.

But I don't recall anyone claiming that tools can verify addresses because addresses are not uniquely linked to people. Isn't like you get an SSL certificate when you get an address.

[-]

EZGGWP@reddit

Your lack of experience with blockchains shows. You can use tools (explorers) to verify the validity of smart contracts (via security audits performed by specialized entities). There is no tool that can scan smart contract code and tell us if it is malicious or not, that's true. But such a thing can not exist.

It's interesting that you used SSL as an example since certificate based security relies heavily on trust (one of the biggest authorities is literally Google Trust Services). Blockchain industry already has multiple well-known "authorities" that simplify checking the validity of contracts, some addresses, and other miscelaneous stuff. Such big entities are about as likely to turn malicious as Google Trust Services leaking their private keys to bad actors.

If you apply the same principles to crypto as you do to your bank account, that is - not leaking your password or 2FA - your funds will be safe. If you check the address to which you send tour funds - the same way you check an IBAN when making a transfer - your money will not go to the wrong person.

[-]

grauenwolf@reddit

Cork Protocol, a defi project aimed at "tokenizing the risk of depeg events for stablecoins and liquid (re)staking tokens", suffered a $12 million loss after an attacker exploited a bug in how the project's smart contract calculated exchange rates. The attacker stole around 3,762 wrapped staked ETH (wstETH), which they exchanged for ETH. The project announced that they were investigating the theft and had paused markets. Cork had been audited in whole or in part by four different security firms. The project's funders include Andreessen Horowitz, OrangeDAO, and Steakhouse Financial, and Cork is a part of Andreessen Horowitz's Crypto Startup Accelerator.

[-]

EZGGWP@reddit

There was a news article about how a finance worker was scammed through a deepfaked video call. $25m lost. People lose money for many reasons every day.

And don't pretend like there are no bugs in software outside blockchain. Yes, blockchain has a lot of exploits, many of which sprout from it's questionable legality, subpar popularity, and high complexity paired with relatively sparse number of expert developers. It is not a great point to use to consider it a worse industry.

[-]

fishling@reddit

u/grauenwolf isn't disputing that humans can fall for scams via social engineering or AI fakes. So, you're not countering actually their point here.

They are challenging YOUR assertions in your last paragraph:

If you apply the same principles to crypto as you do to your bank account, that is - not leaking your password or 2FA - your funds will be safe. If you check the address to which you send tour funds - the same way you check an IBAN when making a transfer - your money will not go to the wrong person.

They posted several responses proving you are plainly wrong here AND that audits and reviews aren't sufficient.

[-]

EZGGWP@reddit

Nothing is sufficient until human factor exists. This NPM phishing accident is the best proof there is: however skilled and knowledgable a person is, however many auth factors there is, mistakes will be made and damage will be done.

My points still stand: there were no major issues with USDT exploits that were based on the nature of the blockchain. They were caused by negligence or mistakes made by third parties.

Most examples that grauen provided are far from major players. Typical USDT users wouldn't be affected by these vulnerabilities. So they are about the same as some startup on stock market that went out of business but investor money were already offshore on Marshall islands.

These things happen. They happened to our economy a lot when it was cash-oriented. Once computerization and regulation took place, number of these cases reduced. Blockchain is early in its life still.

[-]

fishling@reddit

Of course human factors are going to be relevant in phishing attacks. That's part of the definition.

My points still stand: there were no major issues with USDT exploits that were based on the nature of the blockchain

Actually, this is a much narrower point than you were arguing earlier, based on the words you actually used, which was a much broader stance that anyone using 2FA and keeping their credentials safe and not falling for phishing attacks was completely immune to losing any currency, ever. "Nature of the blockchain" excludes things like smart contract exploits or defects in the software.

Most examples that grauen provided are far from major players. Typical USDT users wouldn't be affected by these vulnerabilities.

This is a major shift in your position. You didn't say "niche players are vulnerable". Your position was "only idiots are vulnerable and it's by negligence on their own part".

[-]

grauenwolf@reddit

I have to wonder what a "major player" is in their mind when only one of my examples had less than a million dollars in losses.

[-]

grauenwolf@reddit

So they are about the same as some startup on stock market that went out of business but investor money were already offshore on Marshall islands.

Oh you really don't want to open that can of worms. It is widely known that USDT/Tether is a fraud and they don't have anywhere near the amount of assets they claim to have in their accounts.

Why do you think there's never been an audit of the company's financials? If there were, the entire scheme would collapse and cause immense amount of collateral damage.

That said, it's only a matter of time before some AG gets a wild hair and and forces Tether to open their books.

[-]

fishling@reddit

That guy will just continue move the goalposts.

[-]

grauenwolf@reddit

To some degree I feel bad for them. Crypto made a lot of promises after the 2008 crash.

It's like being promised a socialist utopia, but getting a weird mix of communism and end-state capitalism instead. And being so invested, they can't just walk away. So they scramble for something to cling to.

[-]

fishling@reddit

I guess, but on the other hand, maybe they shouldn't make crypto such a big part of their identity that they can't be rational or objective about it. :-)

[-]

grauenwolf@reddit

There was a news article about how a finance worker was scammed through a deepfaked video call. $25m lost.

Blockchain is not a new technology. If you have to resort to obvious lies to defend position your position is bad.

[-]

BadGraaphics@reddit

Blockchain as it is being used now is far more complex than how it was used in 2009. Bitcoin uses a proof-of-work model which is very energy intensive and inefficient. Solana (just as an example, there are other models) in contrast uses a proof-of-stake and proof-of-history model which makes transactions cheaper, more energy efficient, and faster, at the cost of a higher degree of centralization. These technological improvements have allowed for significantly more complex products and tools to be developed.

You're needlessly aggressive about something you seem to know little about.

[-]

grauenwolf@reddit

I know a lot about the topic. You're the one who apparently doesn't because you still think that these problems could be fixed even though they are fundamental to the design.

Why are you talking about proof of stake? That has an absolutely nothing to do with the security vulnerabilities of blockchain technology that we're talking about.

Actually I know why. You trying to change the topic of conversation because you know you're going to lose on security every single time.

It should also be noted that all of the smart contract problems existed before ethereum went to proof of stake. So it was in no way in enabler for all of those advanced products that are causing so many additional problems.

[-]

BadGraaphics@reddit

I brought up proof-of-stake to give an example of how blockchain as a technology has evolved since 2009.

I'm not trying to change the topic as you so aggressively put, I'm responding to you claiming blockchain isn't a new technology - which, again, I don't entirely disagree with as proof-of-work is older, while proof-of-stake and other models are newer.

I don't know why you are so aggressive and combative in all your responses.

In my opinion, there is nothing inherently wrong with blockchain technologies. They are implemented successfully at private scales all the time. Furthermore, it's probably the closest thing we have to a zero-trust system that functions at a large scale.

In your opinion, how are these "smart contract problems" you mention mitigated via other software, and what makes that "impossible" to do via a blockchain?

[-]

stormdelta@reddit

I don't know why you are so aggressive and combative in all your responses.

Because we're sick to death of disingenuous posters continuing to make excuses, especially as you're years past any plausible deniability of arguing in good faith.

They are implemented successfully at private scales all the time

A "private blockchain" that makes any sense is basically just a distributed merkle tree or hash chain, and are really a completely different thing than cryptocurrencies in terms of security implications and tradeoffs made.

[-]

grauenwolf@reddit

I am aggressively against blockchain technology because it is universally a scam, or rather a collection of different scams piled up on top of each other. It has no useful purpose other than to make it easier to commit various forms of fraud and money laundering.

Furthermore it, it has been an environmental disaster causing unknown billions in waste. I'm talking about both electricity and hardware costs, but there's probably substantial amount of public and corporate money wasted on blockchain projects as well.

And I'm especially sick of all the excuses such as claiming it's a "new technology". Proof of Stake dates back to 2012, so I don't want to hear it again unless you can explain how it addresses the fundemental security issues.

[-]

BadGraaphics@reddit

I can't agree that it is universally a scam - it's used in supply chain management at a private level quite effectively. It feels like you're lumping cryptocurrency and blockchain technology together into one, which imo isn't fair to the technology at all. I agree that cryptocurrency has, almost universally, been a "scam".

(I use scam lightly as I believe the majority of people who "invested" into cryptos knew the volatility of the "assets" they were buying. Teams that made a good faith effort to run misguided projects are just failed entrepreneurs, in opposition to genuine scammers who were rampant. But I digress)

Proof-of-work WAS and IS an environmental disaster I completely agree. There is so much wasted energy being used frivolously. Solana is more efficient energy wise than VISA. I think that says enough about how much the technology itself has improved over even a short period of time (2012 to now, if we're talking about proof-of-stake)

You also didn't answer how blockchain technology has security problems inherent to it that can't be solved via better engineered software (or smart contracts) the same way we solve security problems in other areas of distributed computing, consensus mechanisms, and financial infrastructure.

[-]

grauenwolf@reddit

I can't agree that it is universally a scam - it's used in supply chain management at a private level quite effectively.

No it's not. There is literally no use case for blockchain in supply chain management.

It doesn't even make sense in supply chain management. The security guarantees of blockchain only exist if you have an open database where everyone can see every transaction and anyone can calculate the next box. This is not something that companies want. Those systems are run as private blockchains with one organization maintaining the database of record, meaning they offer no more protection than a normal hash chain.

Furthermore, recording transactions was already a solved problem. The difficulty in supply chain management is proving the contents of the shipping container have not changed. And no database can do that.

At best blockchain was used as an excuse to get funding for normal database improvements they wanted to do anyways. At worst it was a complete scam and no meaningful software was ever delivered.

You also didn't answer how blockchain technology has security problems inherent to it that can't be solved

How many times do I have to repeat myself? Transactions cannot be rolled back. This isn't something that you can 'solve' because it's a fundamental feature of the technology.

[-]

EZGGWP@reddit

Do you know how much money is lost to corruption? And corruption money often come from working people's taxes. These crypto losses are mostly gamblers' and commercial investors' money, mixed with some poor souls' attempts to earn money through investment. You can lose huge amounts of money on stock market as well.

I swear to god, you people just need a scapegoat to laugh at. All while modern world's economy is in poor state, yet CEOs and directors get hundreds of millions in annual bonuses.

[-]

grauenwolf@reddit

I've heard all of these excuses before. They didn't impress me then and they don't impress me now. Blockchain is a fundamentally insecure platform for financial transactions. All of your complaints about corruption in other Industries doesn't change the fact that blockchain is a fundamentally insecure platform.

[-]

The defi protocol Penpie was exploited for 11,113.6 ETH (~$27.3 million) by an attacker who exploited a flaw allowing them to withdraw unearned "rewards". Although the protocol claimed to have been audited by two blockchain security firms, they later disclosed that the smart contracts containing the bugs had not been fully audited. The team behind Pendle (the platform on which Pendie is built) detected the attack and paused Pendle an hour after the attack began, which they claim prevented another $105 million from being stolen.

Members of the Penpie team filed complaints with Singaporean police and the US FBI. They also attempted to negotiate a "bug bounty" via on-chain and social media messages to the attacker, but the hacker seems uninterested and has continued to transfer funds between various crypto wallets and launder funds through Tornado Cash.

[-]

grauenwolf@reddit

An attacker noticed a vulnerability in a smart contract for The Idols, an NFT project that also incorporates ETH staking functionality. They discovered that a function used to distribute rewards had a bug when the sender and recipient addresses were the same, allowing a holder to repeatedly claim rewards. By taking advantage of this bug, they were able to siphon 97 stETH (~$324,000) from the project. Although The Idols boasts of two audits from several years ago, the contract containing the vulnerability may not have been audited.

[-]

grauenwolf@reddit

A new Solana-based defi protocol called Loopscale, backed by Coinbase Ventures and Solana Labs, suffered a $5.8 million exploit only two weeks after its launch. The stolen funds represented 12% of the protocol's TVL. The project blamed the exploit on a bug in the protocol's pricing calculations. Although the project had been audited in February by OShield, the audit evidently did not detect the flaw.

[-]

grauenwolf@reddit

The PulseChain-based defi project BetterBank was exploited by an attacker who took advantage of a vulnerability that allowed them to mint arbitrary tokens, some of which they then swapped for ETH. The attacker later returned around $2.7 million of the stolen assets, having cashed out around $1.4 million. The vulnerable smart contract had been audited by cybersecurity firm Zokyo, which claimed they had flagged the issue during an audit. BetterBank responded by claiming that the auditors had either not identified or failed to communicate the true severity of the flaw.

[-]

stormdelta@reddit

If you're dumb and ignorant as a rock, then yes, your funds will be stolen

Victim blaming isn't a security model, particularly when requiring inhuman perfection to use safely, and which fails irrevocably and catastrophically if any mistake is made. We're talking about requiring a level of opsec even experts screw up, much less regular people, with zero fallback or recovery.

As other mentioned, there is no central authority in blockchains, which is a blessing and a curse. It's a trade-off, nothing more, nothing less.

Trade-off yes, but such an extreme and severe one that the genuine applications are largely illegal transactions in order to bypass otherwise better systems that have more oversight. And sure, illegal doesn't mean unethical, but that's the only relevant niche they provide real utility in over other options.

I personally paid for many things with crypto and I wasn't scammed out of my money. There are people who are scammed out of tens of thousands of dollars through normal banking. The issue is human factor.

The relative risk profile is worlds apart, and it's incredibly disingenuous to pretend otherwise.

[-]

EZGGWP@reddit

Victim blaming is not a security model, it's a statement of what actually happened. As I said, there are tools and practices used by many players jn the industry that help avoid getting scammed. And yet, people still grt scammed. If a normal person was threatened to withdraw cash and give it to the bad actor, normal banking system wouldn't be able to do much either. Financial safety takes away freedom, and blockchain had freedom in mind since its first inception. If you don't like the trade-off, you're welcome to not use it.

The person I initially replied to talked about trust, and I drew a parallel with the SSL/TLS system. It's also built on trust. There may be more accountability among normal organizations, but when shit hits the fan, they will pay the fees and be on with their life, while you, having suffered the consequences, will have to either go to court with them, or suck it up. Court shennanigans are not always worth it.

Afterword, USDT is a very safe token to use. The minting organization keeps big records on those who abuse crypto and their blacklists are very long. It doesn't fully protect you from losing money, but it sure as hell reduces the amount of stolen money on blockchain.

[-]

The vast majority of people aren't capable of realistically auditing it, so they're back to trusting the word of people they don't know.

If anything happens to the hardware wallet, they've lost access. If they kept backups outside the wallet, those can be compromised. In both cases there is zero chance of recovery.

And that's not even getting into how the key generation process might be found to have flaws later, or all the other myriad forms of human error that all result in catastrophic, irrevocable loss.

Yes, these things happen in conventional finance too, but the difference is there is no pretense that they can't. We have laws and processes to recover funds, reverse fraudulent transactions, etc.

[-]

Beneficial_Slide_424@reddit

The system sitting between the wallet and the chain can be compromised

This comment exposes the lack on information you have on public-key cryptography. The transactions are signed and sent out of the device, even if everything else is compromised, they can not fabricate a transaction using your identity, as it would require breaking ECDSA (Specificially, curve SECP256K1), which reduces to solving Elliptic Curve Discrete Logarithm Problem, and best known attacks take 2\^128 operations. No known hardware can come close to solving it.

And that's not even getting into how the key generation process might be found to have flaws later, or all the other myriad forms of human error that all result in catastrophic, irrevocable loss.

Have you ever written an implementation for any cryptography algorithm? I implemented SECP256K1 curve myself on low level languages. All you need is to generate random 32 bytes then use ec_scalar_mul to compute the corresponding public key. There is no complicated process and common pitfalls compared to RSA, and you can simply generate it by rolling a hex dice 64 times. All operating systems have secure random generators, and today mostly hardware provided entropy is used, i.e, TPM (see TPM_CC_GetRandom). The outputs can then be put into tests, such as, SP 800-22, Dieharder, or PractRand.

There will always be a risk if you want to be your own bank, i.e. An authority not being able to revert any transactions, also means they can not censor/debank you, and this is a trade worth for people into the crypto (not investors/cryptobros, crypto is a currency, not an investment), for many reasons, simplest being, living under an religious/authoritarian government.

[-]

stormdelta@reddit

This comment exposes the lack on information you have on public-key cryptography.

I'm well aware of how public-key cryptography works, and I would've thought it was obvious I'm not talking about that part.

I'm talking about the software being used to actually talk to the chain being compromised - the exact kind of attack that this whole thread is in response to in the first place.

There is no complicated process and common pitfalls compared to RSA, and you can simply generate it by rolling a hex dice 64 times.

The kind of failure I'm talking about has literally happened multiple times with hardware wallets. Mistakes and error have happened.

You seem to keep getting hung up on the cryptographic protocols and missing the forest for the trees when it comes to the full end-to-end picture of how security works in the real world.

simplest being, living under an religious/authoritarian government or just wanting financial privacy.

Most cryptocurrencies are very poor at actually providing any kind of privacy - monero is basically the only one that even attempts to. I will grant this is one of the very, very few legitimate use cases for the tech, even if it's only possible by being subsidized by illegitimate uses.

[-]

Luize0@reddit

And when a bank suddenly doesn't want to do a payment because of political reasons or whatever. That is also viable? Lack of brain on this subreddit is intense.

[-]

grauenwolf@reddit

Oh that's already happening with VISA and Master Card.

It sucks and I personally think it should be illegal to block payments to legally operated businesses. Unfortunately it is often the US government pushing for these restrictions, so it's probably going to take a change in the law to make it stop.

The work-around is to use cash or a wire transfer service like Western Union.

[-]

Oh that's already happening. People with money in crypto exchanges are losing access to their funds because they can't prove they originally bought the crypto with legitimate funds. This was prompted by a political decision (i.e. the government) in the countries where said people reside.

[-]

roscoelee@reddit

Sure. Switching to something that is vulnerable to compromised JavaScript packages is definitely preferred to a bank or whatever. /s

[-]

Zushii@reddit

Well it’s not a bank. It’s what experts have been trying to tell the world. A bank can stop a transfer, call you to make a third factor authorization, or even revert a bank transfer or worse case, use its insurance to reimburse you if the fault was their compromised application. Crypto has nothing of the sorts.

[-]

allwordsaremadeup@reddit

Banks can't do that. I've been very up close and personal with a few severe cases of invoice fraud, and banks can't help. The police can't help. Money is gone, and that's it.

[-]

danielv123@reddit

Oh, banks can help. We recently had our cfo get a phone call about a suspicious transaction that was stopped by the bank due to possibly being a scam.

They confirmed it was not a scam without consulting with anyone, and now the money is gone :)

[-]

allwordsaremadeup@reddit

This is not the CFO's fault. Social engineering hackers are gonna social engineer, it should never depend on the CFO saying "sure". The bank knows where the money went; a police report was filed saying it was theft, so the bank should get the money back. Banks should be liable for allowing criminal networks with mule accounts and withdrawal of criminal money.

[-]

danielv123@reddit

Oh, no, it was definitely the CFOs fault.

Was sent from some random free account + having the misspelled name of CEO in the "from header", marked as external email by outlook
10 minutes after phishing awareness and payment attestation meeting
Biggest bill of the entire year by quite a large margin, to a foreign lawyer of all things (we are not multinational)
Mail had all the hallmarks of being a scam - no specific names, mixed different fonts, misspellings
Bank stopped the transaction, called and confirmed that it was legit. CFO didn't even tell anyone after they had confirmed it was legit.

This was like 5th grader social engineering.

[-]

allwordsaremadeup@reddit

I'm laughing. But still, if a crime was committed, it can never be the victim's fault, no matter how stupidly they acted.

[-]

imabotdontworry@reddit

Banks in the west can all do that kind of things IF your claim is valid.

[-]

allwordsaremadeup@reddit

Not in my experience. Police can't talk to banks, banks can't talk to banks, as a non-customer, you can't talk to the bank you sent it to, there are all kinds of artificial deadlines, it's a mess. Just beyond my anecdotal evidence, there are many reports, etc, like [this one] (https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf) showing billions are lost. Considering these are recorded transactions between accounts in Western banks, where people open accounts in their own names, it should be trivial to just get the money back, but no.

[-]

fire_in_the_theater@reddit

Crypto has nothing of the sorts.

crypto could be made with this sorts. ofc that would still requiring trusting an entity with that power, and cryptonerds hate that kinda trust

[-]

stormdelta@reddit

ofc that would still requiring trusting an entity with that power, while the value of modern popular crypto is essentially built on not requiring that kinda trust

Not requiring that type of trust is quite literally the very premise of cryptocurrency, so introducing it defeats the point.

Cryptocurrency proponents want to eat their cake and have it too, it doesn't work.

[-]

fire_in_the_theater@reddit

Not requiring that type of trust is quite literally the very premise of cryptocurrency, so introducing it defeats the point.

no it's just one premise, one that cryptobros promote to no end in complete denial that their wealth entirely depends on the massive system of govts regulating real property ownership.

crypto has other premises as well: a cheap distributed and transparent consensus on a chain of transactions. dispute and resolution practices could easily be built into the chain's protocols assuming agreement can be made on who should handle the resolution. at some point trust has to be found, we can't really built a society on a total lack of trust in others.

there are also certain problems you wouldn't want reversal with: like voting, which can be even done privately on a public chains using zero-knowledge proofs

[-]

stormdelta@reddit

a cheap distributed

"Cheap" was never part of the premise. Lower efficiency is a known and expected tradeoff for this type of decentralization.

The only ways it could even theoretically have been cheaper is by bypassing regulations and oversight, which is part of the problem.

dispute and resolution practices could easily be built into the chain's protocols assuming agreement can be made on who should handle the resolution. at some point trust has to be found, we can't really built a society on a total lack of trust in others.

Again, you're not wrong about trust but that's exactly why cryptocurrency doesn't work. What you're describing literally invalidates the premise of the tech, you're talking about reinventing how traditional finance already worked just with extra steps and less oversight.

there are also certain problems you wouldn't want reversal with: like voting, which can be even done privately on a public chains using zero-knowledge proofs

A voting system nobody but a handful of experts can understand can't be trusted by the public, and that's only the tip of the iceberg of problems with that idea.

[-]

fire_in_the_theater@reddit

"Cheap" was never part of the premise. Lower efficiency is a known and expected tradeoff for this type of decentralization.

cheap definitely was part of the premise.

regulations, oversight, and after-the-fact corrections are extremely expensive and we want do as little of that as possible.

block chains can take a lot of the weight off such oversight by relying on computable math for much of the security ...

additional oversight for edge cases (like disputed txns) can be baked into the protocol, like i said.

What you're describing literally invalidates the premise of the tech, you're talking about reinventing how traditional finance already worked just with extra steps and less oversight.

it only invalidates the nonsense cryptobros pushed, which idgaf about

A voting system nobody but a handful of experts can understand can't be trusted by the public, and that's only the tip of the iceberg of problems with that idea.

and a voting system that only a handful of people can audit, can?!

the trust isn't based on rationality in the first place, it's based on pure societal indoctrination, which obviously can be used to indoctrinate people into trusting a zero-knowledge proof.

[-]

stormdelta@reddit

regulations, oversight, and after-the-fact corrections are extremely expensive and we want do as little of that as possible.

Who's "we" here? Those exist for very good reasons - reasons so good, you're literally talking about adding them back in even with cryptocurrencies.

block chains can take a lot of the weight off such oversight by relying on computable math for much of the security ...

This is the kind of misunderstanding of security I'd expect from laypeople, not r\/programming.

We already use cryptography heavily in modern finance, and while there's plenty of improvements to be made, this is not generally where the big failures happen. The failures are down to fraud, misuse, human error, etc.

Public blockchains (aka cryptocurrency for all practical purposes) even in a hyper-idealized scenario would at best only improve the things we already do well with software and cryptography today. And would make the things we already have issues with worse, as things like fraud become far easier to do and far harder to fix.

I highly recommend you read Bruce Scheneier's articles criticizing cryptocurrency. He literally wrote the book on cryptography and security in practice.

additional oversight for edge cases (like disputed txns) can be baked into the protocol, like i said.

You can't do those things without central authority and oversight. Which again not only invalidates the core engineering tradeoffs of the tech, it's also the very kinds of regulation and oversight you claimed to be against having earlier in your post!

Please stop watching crackpots on youtube and look into the history of why and how our financial regulations came to be. They exist for good reason due to many hard learned lessons over the centuries.

it only invalidates the nonsense cryptobros pushed, which idgaf about

I'm not talking about ideological premise, I'm talking about the actual engineering and technology tradeoffs. No offense, but do you even have a background in software? I would expect people in this sub to know better, even crypto-proponents.

and a voting system that only a handful of experts can audit, can?!

Systems with a paper trail visible to the voter are still widely used and what many of us advocate for. They can be audited by laypeople at scale, understood by laypeople, and are harder to compromise at scale without being noticed than people think, in part due to the first two.

[-]

fire_in_the_theater@reddit

Who's "we" here? Those exist for very good reasons - reasons so good

yes, they do. but if we can avoid having to do so using computable math, that is preferred. it's very expensive to go to court and bring up documents and etc, etc ... if we can build systems that avoid having to do so as much as possible, that's a good thing.

This is the kind of misunderstanding of security I'd expect from laypeople, not r/programming.

i still think a distributed transaction ledger that we agree on saves us a lot of various kinds of effort, especially when it comes to international situations.

it's also the very kinds of regulation and oversight you claimed to be against having earlier in your post!

i'm not entirely against central oversight, but we still want to design systems which avoid the use of after-the-fact corrections as much as possible. we shouldn't desire the use of oversight, and we should design our systems to need them as little as possible, and i really do think distributed ledgers can help with this.

another benefit of distributed ledgers is it becomes trivial to build not only a distributed ledger but a transparent one, especially if you have a trusted authority (govt) managing the identities operating on the ledger.

heck, the govt already manages to bunch of identities. instead it should be managing just one identity ... the one operating on govts ledger, and that ledger should support all the operations it needs to manage the govt.

I'm not talking about ideological premise,

i am tho

I'm talking about the actual engineering and technology tradeoffs. No offense, but do you even have a background in software?

gaslighting isn't a good sign of well reasoned arguments.

Systems with a paper trail visible to the voter are still widely used and what many of us advocate for

i still can't actually audit the system, all i know at that point is it's showing me my vote back to me.

personally i'd rather an open source distributed ledger based on zk-proofs where anyone could audit the actual code used to submit and validate transactions.

cryptobros give blockchains a bad rap, but the only part is really agree with them is that blockchains are the future for transactions.

[-]

stormdelta@reddit

i am tho, we should continue to seek building an ideal society... and losing sight of that isn't a tradeoff worth making. might even get us killed if we lose sight of idealism for too long.

You keep dodging the point.

Literally, the entire point of a public blockchain is to have a specific type of decentralized ledger that does not rely on central authorities or third-party gatekeepers. It makes enormous technical tradeoffs to have this property.

If central authority and gatekeepers are acceptable to have, if some trusted party has the ability to override the state, then those extreme technical tradeoffs are unnecessary and pointless.

I seriously can't stress this enough, and it's becoming clear you do not understand what public blockchains even are.

if we can avoid having to do so using computable math, that is preferred. it's very expensive to go to court, find/bring all legal documents and etc, etc ... if we can build systems that avoid having to do so as much as possible, that's a good thing.

We already do use software to improve things for the most part, and for the areas we could do better, public blockchains either don't help, only provide an illusion of helping, or actively make things worse.

For example, how do you even imagine this would help with legal processes or disputes? If we want to require cryptographic signatures on documents, we could already do that without a public blockchain and there would be no value added by using one, in part because identity validation and management would necessarily already involve a central authority.

gaslighting isn't a good sign of well reasoned arguments.

I don't think you know what gaslighting even means. And I said what I did because you seem to have deep misunderstandings about the tech that I normally associate with laypeople, not programmers.

i still can't actually audit the system, all i know at that point is it's showing me my vote back to me.

Many places including the US have a whole process around volunteering to help oversee and run the election process.

personally i'd rather an open source distributed ledger based on zk-proofs where anyone could audit the actual code used to submit and validate transactions.

Only a small number of cryptography experts would even be qualified to audit that code, and even if those people were able to be trusted completely by everyone somehow (I certainly wouldn't), that still gives no way for a layperson to have any confidence in it, it's a black box in an era where people are already worried about the integrity of the electoral process.

cryptobros give blockchains a bad rap, but the only part is really agree with them is that blockchains are the future for transactions.

Almost nobody is using them for transactions or as currency outside of illegal transactions, even after trillions of dollars and countless man-hours were wasted trying to make it work.

[-]

jl2352@reddit

The ’value’.

We used to operate that way back in the Victorian era. Where most deals were basically a handshake, and there was zero recourse for when you got swindled. We built the protections in modern banking systems to get away from that.

[-]

barrows_arctic@reddit

We built the protections in modern banking systems to get away from that.

I mean, that's cryptocurrency in a nutshell: hyper-libertarians re-learning, one painful step at a time, why we invented banking regulations in the first place.

[-]

fire_in_the_theater@reddit

The ’value’.

i'm referring to market value, not existential value.

[-]

I’m not sure even a cold wallet would have avoided this, as you need to make sure you are signing the transaction to the correct address, which would have been obfuscated by this

[-]

stormdelta@reddit

How does anything think crypto is a viable alternative if that is the case?

Most don't (they're just grifters/fraudsters), and the few who still genuinely do don't understand anything about how security actually works in the real world. There's a reason actual experts like Bruce Schneier have long been critical of it.

The whole premise requires that there is no central or third-party gatekeeper to the network. Meaning any kind of authentication must be self-contained sole proof of identity, and necessarily conflates possession with ownership, as any outside authorization requires some kind of external trust or gatekeeper. Nor can any failure be revoked or rolled back, because again the whole point is no third-party trust.

It's a bit like building an indestructible impenetrable door, and then acting shocked when the thief just goes in through the window and unlocks the door from the other side.

[-]

grauenwolf@reddit

It's a bit like building thousands of indestructible impenetrable doors, and then acting shocked when the thief just presses a button and every vault mails its contents directly to the criminal.

this is hurting my brain - what? example?

[-]

paul_h@reddit

For something like the Token2 Bio3, enhancements would be:

Credential wrapping & transfer protocol. That's a secure way to encrypt credentials from Key A -> Key B.
User-gated export. That's Biometric/PIN + physical confirmation (button press) to approve sync. The Biu3 already has that.
Hub-assisted option (optional). A small offline hub with lcd screen + buttons could mediate the sync process, removing reliance on any PC/phone OS tools. It would need 4x AA cells I guess.
Cross-certification. Keys declare themselves part of the same “identity set,” so relying parties don’t need to see both separately.

Token2 could make that today with very similar hardward and call it the Bio4.

[-]

Somepotato@reddit

That would be inherently insecure, they're by design unconable

[-]

paul_h@reddit

I dream of being able to periodically sync two or more inherently secure hardware key-holding devices AFTER enrolling one with a site.

[-]

slvrsmth@reddit

So the solution is to always have n+1 devices logged in everywhere? With the +1 supposedly stored in a safe? Or get an additional purpose-built device?

I understand the idea passkeys are trying to solve, but the whole device-specific private key business is keeping me well away from using them. Where I currently use a password manager with network-synced database, I would need at least a password manager with browser integration. And hold on, would I need the password manager to integrate with every app on my phone? Or every login is now o-auth webview?

Either I don't understand the whole thing (likely), or the people behind passkeys have never lost or destroyed a device.

[-]

Somepotato@reddit

For apps and sites that support passkeys, your os will via Bluetooth use your phone to authenticate you.

I use a yubikey in a safe, plus my phone for general use. Hasn't been a problem yet.

[-]

Advocatemack@reddit (OP)

The maintainer doesn't yet have control of his NPM account

[-]

BugBaba_dev@reddit

The maintainer still trying to get access back to his account in order to assess what actually happened.

[-]

ClonedY@reddit

So, there is a single maintainer on which Millions of websites are dependent for their security?

[-]

BugBaba_dev@reddit

Not exactly. Most popular packages have multiple maintainers or backups, but sometimes smaller packages are managed by just one person.

The issue is that these smaller packages can be dependencies inside bigger ones - like a tiny screw in a huge machine. So if that one screw breaks, it can affect millions of websites.

soo.... yes. there's one single dude who can take down/compromise nearly every webpage.

There's a reason to not use version ranges.

[-]

Substantial-Pack-105@reddit

I got to be that dude for a while. I had an open source library, getting like 10k downloads a week, until it one day it became a dependency in a major, well-known application monitoring service. Suddenly, my code was being deployed into hundreds of thousands of servers overnight.

[-]

njmh@reddit

There's a reason to not use version ranges.

Yup, always version lock and consider using tools like dependabot.

Also, leftpad taught me to always ask myself "Do I really need a package for this?"

[-]

fullup72@reddit

sure, and then dependabot auto-updates you into a hijacked version, just that you don't know it yet but it's mandatory per company policy because dependabot raised a flag against your "outdated" version.

And sure, you will say "just review the PR carefully!", but when dependabot keeps raising 10 to 15 PRs per day because every dependency is on an update flurry you end up just rubber stamping whatever dependabot suggests (and if those deps are not pinned themselves, you still pull updated versions of their deps).

[-]

BugBaba_dev@reddit

Kinda, yeah. It’s like one guy holding a single Jenga block that’s propping up half the internet.

If his account gets hacked or he pushes bad code, millions of sites can break overnight.

Pinning versions isn’t a magic fix either — it’s like duct-taping the Jenga tower. Looks stable, still collapses if the wrong block goes missing.

On the other hand, when you roll your own utilities, you may inadvertently make yourself vulnerable to exploits and not get the advantage of security fixes issued by well-maintained open source dependencies.

On the gripping hand, exploits are usually researched and pursued based on return on investment, and that means open source libraries are more likely to be targeted for having a larger cross section than your singular site where everything is bespoke.

So it's all complicated.

[-]

ShinyHappyREM@reddit

you may inadvertently make yourself vulnerable to exploits and not get the advantage of security fixes issued by well-maintained open source dependencies

...

for functionality that takes less than a minute to write yourself

[-]

Forward_Ability9865@reddit

Are you really suggesting that small functions are never exploited? it only takes one character to go from a fully safe code to one that is exploitable on every front. Not argumenting against the importance for less dependancy, but your argument is just very wrong and dangerous.

[-]

falconfetus8@reddit

We're not talking about cryptography libraries here, we're talking about micro packages like is-even. With functions that small, the chance of an accidental vulnerability is far lower than the chance of its maintained becoming compromised.

If your own utility function has a vulnerability in it, you at least have the ability to fix it yourself, rather than hoping Joe Schmo is motivated enough to fix it for free. You accept a modicum of responsibility, and in exchange gain a lot more security.

Not all npm libraries are like that.

Microlibs are a legacy artifact (i agree a wrong one) of reducing clients bundle size, nowadays almost all bundles can do decent tree shaking so if you use 1 function of a library it doesn't bundle the whole library, just the dependency chain.

Also a lot of seemingly simple functions in js can be written in ugly but highly optimised ways which shouldn't really be part of your own codebase. Ofc you are welcome to write and maintain your own library but the work adds up. We live in a world where pumping out apps faster and faster is the norm and a requirement, yes security often suffers because of it but especially around npm many have learned how to strengthen your supply chain and prevent such things to get in easily. The real issue i see in this attack is how web3 still has little direct browser integration and how incredibly unsafe it is, given how easily an injected js code into a library can drain your wallet.

[-]

coderemover@reddit

Because most of the time you don’t have the time to implement good enough util. That doesn’t apply to trivial stuff like leftpad but good luck implementing a state of the art hashmap, parsing library, embedded database system or ORM. So dependencies are inevitable, and you have to figure out a safe way to use them anyway. Once you have a good system of including dependencies, it can be also used for simple stuff, because why not? You can and should vet any code you depend on anyway, and it’s trivial to check leftpad vs something bigger like an embedded database.

[-]

EnGammalTraktor@reddit

WDYM Dude!? Every hip project needs a "is-arrayish" import!

[-]

coppercactus4@reddit

This is why JavaScript is a hot mess. I do both frontend and backend in c# and it's just a night and day difference using a language that has batteries included. There are hundreds of first party libraries written by Microsoft that come with the language. Of course there is a package manager (NuGet) but projects would have tens of references not thousands. Transitive dependencies are usually that big (except for the Microsoft ones).

[-]

that's web development

[-]

lollaser@reddit

welcome to npm land

[-]

AegisToast@reddit

There are several single maintainers on which millions of websites are dependent.

There was an incident a few years ago where one dev pulled his packages entirely off npm, and because a huge majority of major packages were dependent on some of them, he took down like half the internet for a few hours.

Kind of crazy, but modern tech is basically just devs building on top of other devs’ work, who built theirs on someone else’s, and on and on. There are lots of potential single points of failure.

[-]

fullup72@reddit

the infamous left-pad incident, caused by taking the "don't reinvent the wheel" mantra to an extreme and going as far as using packages like is-even because x % 2 === 0 is too much work for some people, and what if the definition of "even" changes and you need to modify your entire codebase!?

[-]

idiotsecant@reddit

https://xkcd.com/2347/

[-]

JayWelsh@reddit

What is the mitigation for this? Is it enough to do an `npm audit fix`?

[-]

BugBaba_dev@reddit

As far as I know, npm is working on two things:

Fixing the vulnerabilities (what the community is working on right now).
Creating a patch to neutralize the malware, so even if someone runs it, it becomes harmless - including any systems that may have already been affected.

[-]

[-]

oorza@reddit

This was a social engineering attack. There's a reason the nukes take two people to launch. Every system where one person can make executive actions in isolation is vulnerable to this type of attack.

[-]

rdtsc@reddit

most forks would quickly go stale

Like that is-arrayish package which had its last version published 7 years ago?

mandatory 2FA for maintainers

The author had 2FA enabled…

[-]

BugBaba_dev@reddit

A stable package like "is-arrayish" staying untouched for years is fine - it just means the code has not needed changes.

But if thousands of people forked it, fixes and security patches would get scattered across many copies, breaking CVE tracking and making it harder to keep users safe. That fragmentation creates more risk, not less.

And you are right - 2FA alone is not bulletproof. In this attack, the maintainer had 2FA enabled, but attackers stole publish tokens or CI credentials, bypassing it entirely.

That’s why npm and GitHub have started rolling out trusted publishing (short-lived OIDC tokens instead of static tokens) and signed releases (package provenance) alongside 2FA - a layered defence to stop future supply chain attacks.

[-]

ClownPFart@reddit

The maintainer is a dumbass who fell for an obvious phishing email (hurr .help tld, looks legit)

Then again he's a npm package maintainer so obviously he's a dumbass

web devs lol

[-]

BugBaba_dev@reddit

The maintainer’s account has been restored, and all packages published by him should now be back to normal.

[-]

Advocatemack@reddit (OP)

Response from maintainer on HackerNews (personal note: Its great to have a maintainer that has been so responsive and owned up quickly, we all make mistakes)

https://news.ycombinator.com/item?id=45169657

Hi, yep I got pwned. Sorry everyone, very embarrassing.

More info:

- https://github.com/chalk/chalk/issues/656

- https://github.com/debug-js/debug/issues/1005#issuecomment-3...

Affected packages (at least the ones I know of):

- ansi-styles@6.2.2

- debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST)

- chalk@5.6.1

- supports-color@10.2.1

- strip-ansi@7.1.1

- ansi-regex@6.2.1

- wrap-ansi@9.0.1

- color-convert@3.1.1

- color-name@2.0.1

- is-arrayish@0.3.3

- slice-ansi@7.1.1

- color@5.0.1

- color-string@2.1.1

- simple-swizzle@0.2.3

- supports-hyperlinks@4.1.1

- has-ansi@6.0.1

- chalk-template@1.1.1

- backslash@0.2.1

It looks and feels a bit like a targeted attack.

Will try to keep this comment updated as long as I can before the edit expires.

---

Chalk has been published over. The others remain compromised (8 Sep 17:50 CEST).

NPM has yet to get back to me. My NPM account is entirely unreachable; forgot password system does not work. I have no recourse right now but to wait.

Email came from support at npmjs dot help.

Looked legitimate at first glance. Not making excuses, just had a long week and a panicky morning and was just trying to knock something off my list of to-dos. Made the mistake of clicking the link instead of going directly to the site like I normally would (since I was mobile).

Just NPM is affected. Updates to be posted to the `/debug-js` link above.

Again, I'm so sorry.

[-]

bzbub2@reddit

So....just guessing at whole account stealing procedure.... it seems like he must have clicked fake link, tried to login on fake link, then he entered the 2fa information to wrong site as well, then hacker took that info, logged into real npm site as him, got control of the account, changed email and password and 2fa settings on his account, then blasted out new versions. Given how easy it is to fall prey to this...like these fake websites that mimic original ones... are there any technical solutions to avoid this happening?

[-]

Middle_Citron_1201@reddit

Passkeys are (in most conditions) unphishable. That’s one of the reason security folks are so passionate about them. To be able to trick a browser or other software into signing a pass key challenge that isn’t authentic you’d have to already compromise the developer’s environment to a level that you might not even need to phish them.

[-]

Passkeys or webauthn (fido2). These forms of 2FA are bound to the website so a fake site cannot intercept the credentials. A TOTP is vulnerable to being intercepted.

[-]

Yadobler@reddit

I remember the maintainer of hibp got his personal blog mailing list leaked (pretty ironic) by the same MO: very tired / jetlagged and on mobile, missed the very hidden subtle signs that one wouldn't notice unless constant paranoia

[-]

Advocatemack@reddit (OP)

The original phishing email came from support@npmjs[.]help

it is very likely there will be more comrpomises from phishing campaigns from this email like what we saw last month with compromises coming from phishing emails from the domain support@npnjs[.]com

[-]

-Y0-@reddit

I wonder can you use similar looking, but different letters in your TLD? E.g. cyrilic со followed by latin m.

[-]

tsimionescu@reddit

Browsers have a large set of heuristics that try to recognize such cases and replace the Unicode domain name with a punycode version to avoid confusing users, at least for some common domain names such as google.com.

[-]

laplongejr@reddit

I recall doing an example of the attack for one of our final group exams.
At the time browsers had no fix yet, so the only mainstream browser safe against it was... Internet Explorer.

"Wait, how can IE be the only one to have fixed that?"
"They didn't fix it. They are so late the internationalized domains aren't supported yet, so the domain has 0 chance of fooling the user"

Curious, I asked GTP what the most popular .help domains were ... all came back as redirects to porn. Need a better source.

The most obvious self.help is for sale.

[-]

Advocatemack@reddit (OP)

More info on phishing email here -> https://github.com/orgs/community/discussions/172738

[-]

kranker@reddit

The links are also leading to npmjs.help, the domain was registered 3 days ago.

OMG this single function library uses one of his other packages as a dependency

var isArrayish = require('is-arrayish');

I don't understand the culture around NPM packages.

[-]

KerrickLong@reddit

I don't understand the culture around NPM packages.

This part of the culture basically comes down to "the standard library should really include this. I'll publish it so others don't also have to write it."

[-]

shevy-java@reddit

In a way this also described left-pad. You don't see this in ruby and python because these languages are better designed than JavaScript. Nobody would have a use case for something like left-pad there; in ruby I just tend to either use % with the format specifier e. g. '%.3f' % '3.0'.to_f # => '3.000' or for simpler cases e. g.

x = "abc"; x.ljust(33, '_') # => "abc______________________________"

Python has something similar. JavaScript evidently has had a need for left-pad, which is a tragic comedy. JavaScript is the monty python of programing languages, but less funny. This dead parrot was always a horrible parrot.

[-]

KevinCarbonara@reddit

In a way this also described left-pad. You don't see this in ruby and python because these languages are better designed than JavaScript.

This is the part that bothers me. So many people turned left-pad into an issue of "Developers who use Javascript are stupid and lazy" instead of "The developers who created Javascript are stupid and lazy and the users are having to fix the language for them"

[-]

wutcnbrowndo4u@reddit

It's both?

It's ridiculous that left-pad would even exist, but a dev operating in that environment is being "stupid and lazy" to add a breaking dependency for 5 lines of simple code.

[-]

KevinCarbonara@reddit

It's ridiculous that left-pad would even exist, but a dev operating in that environment is being "stupid and lazy"

No, they're not. That's what standard libraries are for. And that's the role that NPM fulfills.

[-]

wutcnbrowndo4u@reddit

No, because stdlibs don't add a meaningful dependency on top of the language itself. That first-class citizenship is what makes them stdlibs, and they're accompanied by an attendant seriousness around how distribution is managed. Npm is nothing close to that.

Again, you're framing it in terms of what concepts map to each other, which obscures more than it illuminates. The incentive math is as simple as:

does saving five lines of simple code come at the cost of a new critical dependency that a random dev can break on a whim ->

-> you shouldn't do it then

[-]

KevinCarbonara@reddit

No, because stdlibs don't add a meaningful dependency on top of the language itself.

You're moving the goalposts. That behavior is the same among devs in any language. The deficiency lies within the language and its ecosystem, not the developers.

[-]

wutcnbrowndo4u@reddit

Not moving the goalposts at all: I'm explaining why it's inaccurate to claim that "npm is the stdlib of the JS ecosystem". You have the same dynamic when you depend on a random pip pkg, but not when you depend on the Python stdlib

The deficiency lies within the language and its ecosystem, not the developers

And yes, Javascript is a horrifically deficient ecosystem. That is in no way relevant to the developer's job of behaving sanely within that ecosystem.

If somebody insisted on using malloc/delete and had memory issues destroying their c++ software, it would be weak tea to say "oh well it's a deficiency in c++ that it isn't memory-safe". Possibly true, completely irrelevant to the choices you should be making as a developer.

Remember, we're not talking about rolling your own crypto here. We're talking about five lines of string-handling code

[-]

KevinCarbonara@reddit

Not moving the goalposts at all: I'm explaining why it's inaccurate to claim that "npm is the stdlib of the JS ecosystem".

But it's the closest thing the JS ecosystem has and developers are making do, which was precisely my point.

[-]

wutcnbrowndo4u@reddit

Right, but I'm saying that "making do" would be "writing 5 lines of string-parsing code instead of adding a breaking dependency to your app".

That goes back to what I said in my prev comment: the tortured logic of drawing false equivalences in order to justify irrational behavior doesn't stand up to the straightforward fact that adding a dependency on leftpad is an obviously and extremely bad idea, not worth the stability/velocity tradeoff in any sane scenario.

I'm certainly not suggesting that npm (or pip) never be used! But it's absolutely "stupid and lazy" (to go back to the orig pt of this subthread) to make that trade-off in the left-pad case, which is why that case was so illuminating.

[-]

tsimionescu@reddit

That is certainly not true. For example, in Java, instead of myriad tiny packages, people either roll their own utils, or pick up additional utils libraries, like apache-commons or guava. You won't find a "letf-pad" or "is-arrayish" on Maven, certainly not one with hundreds of millions of downloads.

[-]

KevinCarbonara@reddit

For example, in Java, instead of myriad tiny packages, people either roll their own utils, or pick up additional utils libraries, like apache-commons or guava.

Or they use third party technologies like Lombok or Spring to help make up for the deficiencies inherent to the language. You're proving my point.

You won't find a "letf-pad" or "is-arrayish" on Maven

https://projectlombok.org/

[-]

Zomgnerfenigma@reddit

There was plenty of time since left pad to fund an org that fixes all that. I guess no one cared?

[-]

KevinCarbonara@reddit

There's not a lot of investment in Javascript because it's a garbage language. But it's in heavy use because it's what everyone knows. It's a Catch-22.

[-]

SwiftOneSpeaks@reddit

This is a bit unfair. JS lives in a unique environment seeking nearly 100% backwards compatibility. The core language is slow to evolve because they can't just roll back in a later version. It is generally pretty reasonable to decide your python code requires a recent version of Python that has addressed common oversights in the original core library, because your python code only worries about the computer running the cost. But JS runs in the browser. Every browser that visits your site. It spent 10 years having to worry about IE 6.

JS (ES) is nonetheless still around, unreplaced, still improving (slowly), and something that basically every person in industrial nations uses daily. Incidentally, padStart (left pad) was added 8 years ago.

I know it's easy to dump on JS, and JS has real issues, and a lot of the benefits of the mon-JS web are too often left behind, but just mocking JS (or JS devs, though you personally didn't do that, thank you) names is not helping yourself or anyone else to learn anything.

[-]

grauenwolf@reddit

Java lives in a unique environment seeking nearly 100% backwards compatibility.

C# lives in a unique environment seeking nearly 100% backwards compatibility.

C++ lives in a unique environment seeking nearly 100% backwards compatibility.

Rust lives in a unique environment seeking nearly 100% backwards compatibility.

Python lives in a unique environment seeking nearly 100% backwards compatibility.

[-]

therve@reddit

None of those serve code that is executed by a third party runtime.

[-]

grauenwolf@reddit

C++ and Java has multiple implementations of the runtime. C# used to as well. I think Python does, but I haven't looked into it recently.

Not that it matters because this isn't an argument for not having a standard library.

[-]

Luxalpa@reddit

Not that it matters because this isn't an argument for not having a standard library.

I think it does matter, because Rust has a very similar problem for the same reason. The Rust standard library has a very strong committment to backwards compatibility (although they at least got the edition mechanism), and in turn, it also has the same effect where only the most elementary elements and utilities are in it, but anything more complex (like you see in Go a lot) is in third party libraries.

It's possible that these effects are actually unrelated, but I wanted to put it in here, because I think it's quite possible that they are indeed related.

[-]

grauenwolf@reddit

You haven't actually demonstrated a problem. At most you've added one more decision by the Rust team that i disagree with.

[-]

Luxalpa@reddit

You haven't actually demonstrated a problem.

Yes, I haven't, because that was not the task.

The problem that this is solving is backwards compatibility. I can install a Rust library that was unmaintained for 9 years and it will just work with the newest compiler, without any modifications or bug hunting. This is true for JavaScript code as well. I was able to take my little website that I wrote in 2016 using the Angular 2 beta and just npm install it and it just works like it did back then.

Whether or not you care about this is a different story. But for example, I have a ton of old C++ code from my old days lying around here, and it depends on certain versions of Qt, MingW and qmake. Getting those to work under newer versions of MSVC alone is a big undertaking.

[-]

tsimionescu@reddit

I was able to take my little website that I wrote in 2016 using the Angular 2 beta and just npm install it and it just works like it did back then.

You can also take a Java program written for Java 1.0, and do javac my-file.java && java my-file.java and there's a very good chance it will start and run the exact same way it did back then. Same is true for C++ and C# and others as well.

But for example, I have a ton of old C++ code from my earlier days lying around here, and it depends on certain versions of Qt, MingW and qmake.

You're mixing up different issues here. There is no C++ package manager that could find the right version of Qt for your specific version - but if you could, that problem would go away. And the fact that MinGW and qmake have backwards incompatible changes that are outside the scope of the C++ standard is a completely separate issue.

[-]

Luxalpa@reddit

You can also take a Java program written for Java 1.0, and do javac my-file.java && java my-file.java and there's a very good chance it will start and run the exact same way it did back then. Same is true for C++ and C# and others as well.

Maybe that's true for a small toy program. But there's no chance for this to be true for any production scale enterprise program or library.

https://learn.microsoft.com/en-us/dotnet/core/compatibility/9.0?source=recommendations

If your legacy project depends on any of the things on this list, it will break (silently or loudly) after change. And that's just a single version. There's a reason why every fucking app installs its own version of .net framework as if it was a third party library.

[-]

grauenwolf@reddit

I can install a Rust library that was unmaintained for 9 years and it will just work with the newest compiler, without any modifications or bug hunting.

And how would having a standard library affect this?

I have plenty of old C# code from decades that just works in the newer version. The existence of a standard library didn't magically make that harder.

[-]

Luxalpa@reddit

This has nothing to do with existence of a standard library; every major language - including javascript - has one. This is only about the scope about this standard library.

The scope of the standard library affects this because adding more stuff to the standard library can be more easily done if you are allowed to later make changes to it. It is much harder to do however, if you are not allowed to do breaking changes later.

[-]

Sure but backwards compatibility means different things. Yes, any code written for python 3.6 will work for any future version of python 3.x assuming x>=6 (if they used features introduced in python 3.6). (Web) javascript's problem is that you don't get to control the end-user's client and version of javascript they are running.

In (web client-side) javascript, you often want to write code that will run on all your users' web browsers, regardless of how old or non-standard-compliant there browser is.

While most users will use a handful of modern browsers (e.g., chrome, safari, edge, firefox) that have been recently updated, there will be a handful of people on old devices using old browsers that you may be required to support. E.g., some random person browsing from the built in webclient on their smart TV, or someone using an old random phone, or people browsing on an e-reader, etc.

[-]

grauenwolf@reddit

In (web client-side) javascript, you often want to write code that will run on all your users' web browsers, regardless of how old or non-standard-compliant there browser is.

That's not true. Download yourself a copy of Netscape Navigator 4 if you don't believe me.

We will make a good faith effort to support older browsers using polyfills, which you can still do with a standard library.

In the simple case, the standard library is just another npm package that you reference no different than the ones we're doing now other than the fact that it's a lot more sane.

In the complex case the browser has the libraries built in and the package version would defer to the browser version if the browser version is high enough.

[-]

NoveltyAccountHater@reddit

Again, yes I'm well aware modern websites don't fully support the oldest web browsers or redirect some users to a simplified less-feature filled version to avoid having to polyfill everything.

But again, the problem that polyfills solve is that modern Javascript is often run by older clients that may not support all the latest features. This is fundamentally a different compatibility problem that doesn't exist in most other languages. You don't write Java 21 code and expect users to run code on older runtimes (because you tell the user installing the software to use the appropriate runtime or a future version). There are sometimes a couple analogs to polyfills in other languages (e.g., from __future__ import feature in python where say in py3.6 you can import f-strings from python 3.8), but this is a different type of compatibility issue.

[-]

grauenwolf@reddit

lechatsportif@reddit

seeking nearly 100% backwards compatibility

In practice seemingly no one actually prioritizes this goal. They seem to pay lip service to it happily breaking stuff until they can get around to it. If the community really cared about backward compatibility it would feel more java like.

[-]

danielv123@reddit

Where have they broken backwards compatibility?

[-]

ipaqmaster@reddit

ljust my beloved

[-]

jl2352@reddit

Is Arrayish is another example. As there are ways of making your own Array like objects.

You can also have multiple instances of the Array prototype in play. Meaning an object might be an instance of an Array, it’s just not an instance of your Array. This one is more of a weird factoid of how browsers work rather than JS, as that’s where it comes up.

[-]

csorfab@reddit

these languages are better designed than JavaScript

Yet Javascript was able to evolve in a way that it now accommodates most of the web on client and server alike, which is an impressive feat from a language that was hacked together in 2 weeks. Sure, some of this evolution came out of pure necessity, but it still illustrates the cleverness of the original design, even if there were some less fortunate choices made (which we can now completely ignore thanks to Typescript or other tools). Show me a competent engineer who would choose Ruby over Typescript for anything serious.

Don't get me wrong, I loved Ruby back in the day, but it provides, and even encourages so many footguns that JS could hide in shame.

[-]

wasdninja@reddit

JavaScript evidently has had a need for left-pad, which is a tragic comedy

const x = 'abc';x.padStart(33, '_') does the same thing. It's been around since 2017.

[-]

sad_bug_killer@reddit

The left-pad incident was in 2016

[-]

BubuX@reddit

by that logic, rust is doomed

[-]

SanityInAnarchy@reddit

There's that, but there's at least two other things:

One is, historically, it was easier to write a tool that bundles and minifies a bunch of tiny libraries, rather than one that removes unused code within a library. I don't think this is a good reason anymore, especially with TypeScript, but there was at least a point in time where single-function libraries mean the functions you don't use don't have to get shipped to everyone's browser anyway.

The other is, it's an easy way to get an impressive-looking Github portfolio, at least if no one actually looks at any of the hundreds of packages you've published to find out that they're each a single line of code.

[-]

psaux_grep@reddit

Also open PR’s to 100’s of open source projects to use your library instead of 3 lines of code and then when some of them gets approved you can get to brag about all the organizations using your code on account of using the project you pushed crap into.

[-]

danielv123@reddit

Swizzle is also just [].flat() so why 27 million (and growing) people download it every week is beyond me.

[-]

sysop073@reddit

I don't understand why so many people don't understand this. It's easier to import it than write it -- that's literally all there is to understand. It's only confusing for people who use languages with bad or non-existent package managers where it's hard to add a dependency, but for most newer languages/frameworks it's extremely easy so people just do it.

[-]

alienangel2@reddit

Nobody is saying they don't understand what the short-term reason for writing it was. They're saying they don't understand how so many people think it's not a disastrously bad idea to be introducing new dependencies in random executable code.

It's only confusing for people who use languages with bad or non-existent package managers where it's hard to add a dependency

Those other languages make it hard to add dependencies for a reason. They want people to have to explicitly spell out the dependency tree in one place so we don't have bullshit surprises like this.

It's not a "feature" that javascript plus NPM doesn't, it's a vulenerability due to a fundamental design gap.

[-]

sysop073@reddit

Nobody is saying they don't understand what the short-term reason for writing it was.

Oh, then I misunderstood; that's exactly what I thought they were saying.

Those other languages make it hard to add dependencies for a reason.

Nooooooooo no no. We're not giving languages like C credit for having terrible package support as though they predicted this problem 50 years ago and heroically avoided it. Most languages without package support just never bothered to implement it, they didn't consciously decide to leave it out.

It's perfectly possible to use third-party packages securely, I have to go through it on a regular basis at work, it's just hard so amateurs don't bother. People that use third-party dependencies in languages without support for it are just forced to check in a copy of the third-party code they can point their compiler at. Typically they do this without reading a single line of the code, and also never bother to update it, so this isn't exactly what I would call a win over proper dependency management.

[-]

RirinDesuyo@reddit

It's perfectly possible to use third-party packages securely, I have to go through it on a regular basis at work, it's just hard so amateurs don't bother

C# for example is pretty easy to add external dependencies, but developers don't do this most of the time. This is because the stdlib is very comprehensive enough that you devs have to double think adding a dependency is worth the maintenance cost or just creating the code yourself. You don't need to pull on-off libraries like these despite installing dependencies in nuget is as easy as js, usually you pull dependencies that deal with more complex tasks or domains (e.g. image manipulation, document parsing, web servers etc...). You can even see this on libraries published on nuget where the dependency tree usually collapses back to either System.* (BCL) or a first party package Microsoft.* and never really goes as deep as npm packages do.

[-]

5gpr@reddit

People that use third-party dependencies in languages without support for it are just forced to check in a copy of the third-party code they can point their compiler at. Typically they do this without reading a single line of the code, and also never bother to update it, so this isn't exactly what I would call a win over proper dependency management.

You're absolutely right, but even in languages with proper dependency management, I question the programmer who uses third-party packages for (famously) left-padding a string or similar.

[-]

dodeca_negative@reddit

Totally makes sense as long as you never think about the consequences of your actions

[-]

sysop073@reddit

...right. Is that the part people were confused about, that lots of people are lazy and do whatever is easiest to solve the problem right in front of them? I thought this was widely known.

[-]

Whispeeeeeer@reddit

easier to import it than write it

But a good developer should always be cognizant of the maintenance load of a dependency. Dependencies require updates, potential API changes, etc. It might be easier, but it's not necessarily a good idea.

Not to mention, a lot of these packages are basically micro versions of functions within lodash which solves all of this more elegantly. And with tree-shaking I don't need to worry about the overhead.

[-]

djnattyp@reddit

It's also confusing for people who use languages with core libraries that provide more functionality and package managers that actually thought about security.

[-]

shevy-java@reddit

Great find. The:

I don't understand the culture around NPM packages.

and:

var isArrayish = require('is-arrayish');

actually reminds me of left-pad.

JavaScript is such a horrible joke of a programming language. I can't decide whether PHP is even worse nowadays.

[-]

lechatsportif@reddit

php is still worse. Javascript the language is still much better than Javascript the community.

[-]

Somepotato@reddit

well, JS has both a left pad and isArray function, so

[-]

cdb_11@reddit

The npm culture really is just crazy.

https://github.com/babel/babel/pull/1559

This was the entire source code at version 1.0, at the time this dependency was introduced:

'use strict';
var userHome = require('user-home');
var osTmpdir = require('os-tmpdir');

module.exports = userHome || osTmpdir();

Gone, got removed.

[-]

Whispeeeeeer@reddit

This particular exploit isn't necessarily an issue with NPM's implementation. These packages are popular and the maintainer was "pwned" due to a scam 2FA e-mail. Some of his packages are - admittedly - pretty ridiculous. Like is-arrayish has a bizarre amount of weekly downloads. Especially when JavaScript has Array.isArray() method these days. NPM has a strange history of micro-packages that tend to make these exploits easier to hide. I think the main issue with NPM is culture:

Installing packages without locked versions (this exploit would be less effective with that)
Reducing these small packages that solve problems that a basic dev should be able to solve without a 3rd party dependency
post-install scripts which can execute any shell command

[-]

SanityInAnarchy@reddit

Okay, I'll bite:

Especially when JavaScript has Array.isArray() method these days.

That only works for arrays. Maybe that's sufficient for your use case, and admittedly the readme isn't doing any favors:

isArrayish({__proto__: []}); // true

Okay, sure, Array.isArray would return false in that case, but why do you need to inherit from an array, especially with prototype inheritance?

Maybe this is a little more obvious with something like jQuery. Open this page in Old Reddit, open the JS console, and Arary.isArray($('p')) is false, but isArraryish($('p')) would be true.

But okay, maybe that's jQuery being jQuery, and we don't have to put up with jQuery anymore. After all, document.querySelectorAll() does a lot of what you want jQuery's $ to do, and returns a normal array.

But unfortunately, some of this madness is baked into the language at a level that's harder to remove: document.body.childNodes is a NodeList, which is arrayish, but not actually an array.

So, sure, is-arrayish is tiny. But this is probably what you actually want, rather than Array.isArray... and it's long enough that you wouldn't want to copy/paste that every time, but also short enough that you wouldn't want to pull in a giant pile of other dependencies just because you wanted that one helper function.

So I guess you could say the root cause is some ridiculous language-level design decisions in JS that make a function like this still a good idea. Or, culturally, the problem is that so many popular libraries are happy to take a dependency on some tiny library by some unknown dev... but I don't think that problem is unique to NPM.

[-]

cdb_11@reddit

First of all, you very likely don't actually need it at all. It's overly generic, and arguably the only place where it might really be needed, is public libraries that want to work for everyone. But in your code, you don't have to care about being generic. You only have to do what is needed for your code base. And only when Array.isArray no longer works for you, you write your own utility function that you control and does exactly what you need, and then you simply find-and-replace.

Build up a library of such functions over time, and copy it over to new projects. You could make it a real package, but then you lose flexibility and you can't easily change the code and interfaces without the risk of breaking your other projects. Public libraries don't have this advantage. With a private library you never have to worry about the issues that third party dependencies bring in -- you don't worry about updating it, about breaking changes, about whether it gets removed or compromised. Of course there are few cases when it still might be worth it. But with your own code, the worst thing that can happen is that you have a bug, and then you fix it, just like anywhere else in your code. You could use existing libraries as a starting point, I believe virtually all of them are licensed under MIT, so you can just copy them to your library.

By the way, I swear I saw people having an argument in some JS library about whether NaNs should be considered a number. Do you honestly want these people to make decisions how your code should work for you?

[-]

Whispeeeeeer@reddit

That's a great write-up and my comment was coming from a bit of ignorance as to why someone might do this. But I would say that it's still ridiculous to have an entire package dedicated to this one purpose. In other languages, they typically have helper libraries to "polyfill" these missing pieces of the vanilla features of a language. The JS equivalent might be lodash.

I would argue, as well, that if you're trying to check if something is array-ish, your code is probably pretty ugly. If you're consuming an object which isn't natively a JS array and is - instead - a NodeList you should handle it as a NodeList rather than trying to treat it like an array. Idk. I'm perhaps a little pedantic, but I just get the ick from this kind of programming. Who is grabbing potentially multiple types of lists and treating them the same? Isn't a NodeList fundamentally quite different from an array of Nodes? In Java, you can treat a LinkedList like an ArrayList using the List object type because they share the same parent properties. But obviously JavaScript isn't doing that. So they shouldn't be treated as the same type.

I think it's far more reasonable to find a snippet on StackOverflow that can do that rather than pull in a dependency for something that is relatively trivial.

[-]

Gil_berth@reddit

You can use the array method forEach() to iterate over a NodeList. If you need more methods of arrays, you can convert a NodeList to an array using Array.from(). All this can be found in mdn in the first screen of the NodeList article, but people rather download a npm package than read documentation...

[-]

SanityInAnarchy@reddit

Erm... that solves a different problem than the one this library does? This is about detecting if it's like an array (which includes weird things like NodeList). Once you know it's like an array, you can of course do all those other things with it.

[-]

balefrost@reddit

But to be fair, it only checks a very small number of things to determine that it's "array-ish".

https://github.com/Qix-/node-is-arrayish/blob/master/index.js

I mean, I can just paste it here:

module.exports = function isArrayish(obj) {
    if (!obj || typeof obj === 'string') {
        return false;
    }

    return obj instanceof Array || Array.isArray(obj) ||
        (obj.length >= 0 && (obj.splice instanceof Function ||
            (Object.getOwnPropertyDescriptor(obj, (obj.length - 1)) && obj.constructor.name !== 'String')));
};

Something is "array-ish" if it has:

A length property
The length is > 0
An int-based key or a splice function

And there's some additional special-case handling for strings, which seems odd to me because Strings have length properties and indexing operators, and otherwise seem to be array-ish to me, but I guess not in this worldview.

So what's the use case for this function? Presumably I want to know that I can use an arbitrary value as if it is an array.

So like maybe I want to do something like:

if (isArrayIsh(someObj)) {
    result = Array.from(someObj);
}

I guess that works in a bunch of cases:

Array.from(['a', 'b', 'c'])
Array.from({length: 3, [0]: 'a', [1]: 'b', [2]: 'c' })
Array.from(document.querySelectorAll("div"))

But what about this?

isArrayish({ length: 0 })
// undefined?!
Array.from({ length: 0 })
// an empty array

isArrayish({ length: 3 })
// undefined?!
Array.from({ length: 3 })
// A 3-element array whose elements are all empty

isArrayish(document.querySelectorAll("h2"))
// undefined?!
Array.from(document.querySelectorAll("h2"))
// an empty array; my page happens to not have any h2 elements

Well, I guess we can make it happy by forcing the issue:

isArrayish({length: 0, splice() {}})
// true

So like, if isArrayish won't even tell me that the value will work withArray.from - perhaps the simplest function that accepts array-ish values - what good is it?

But I'm really getting hung up on the or a splice function part. What does splice have to do with anything? Splice is explicitly a mutating operation. But there are a ton of uses of array-like objects that don't require mutation (Array.from being a good example). So... why even look for splice at all? Is it a hack to be more inclusive of array-like objects whose length is 0 (since there won't be a property called -1)?

Like, I get the idea that dynamically-typed languages employ informal protocols. If it looks like a duck and quacks like a duck and all that. But in order to be useful, you have to define what "duck-ish" means. And if you want "duck-ish" to be generally useful, you need to define it in such a way that it's useful to a wide variety of use cases.

It looks to me like isArrayish was maybe useful to the author in their other libraries, so they broke it out into a standalone package. It doesn't look like it was "designed" so much as "hacked together a bit at a time". It certainly doesn't look generally useful.

Like, I don't know that this particular library was the inspiration, but it certainly seems like it could have contributed to the wonderful farce that is https://github.com/jezen/is-thirteen.

[-]

SanityInAnarchy@reddit

And there's some additional special-case handling for strings, which seems odd to me because Strings have length properties and indexing operators, and otherwise seem to be array-ish to me, but I guess not in this worldview.

Because when you're expecting the argument to your function to be kinda like an array, you probably don't expect to iterate through it character-by-character.

Like, suppose you had a function that could be called like this:

ping(['google.com', 'bing.com', '1.1.1.1']);
ping({hosts: ['google.com'], ttl: 50, count: 10});

You could check Array.isArray, but you want to be able to support other things like arguments lists or NodeList or whatever. Calling the function like this:

ping('google.com');

...is probably an error. Or you could even make your function a bit more ergonomic and special-case that, since the majority of the time, someone probably just wants to ping a single host to see if it's up, and not set any of the other options.

But I'm really getting hung up on the or a splice function part. What does splice have to do with anything?

Well, here's when it was added. It looks like it was added with the length check.

I don't know why this specifically, but my best guess is that this is to avoid things that merely have a length property (since plenty of things have lengths and aren't arrays), but still allow things that merely adopt a bunch of relevant Array properties, either by using __proto__ to inherit from some existing array object, or by using worse hacks like Object.assign (a bunch of early JS libraries implemented something similar), or to support mocks, etc. splice would make sense as a relatively-unusual method name, so length and splice both strongly indicate that this is trying to be an array.

But yep, it's a hack:

It doesn't look like it was "designed" so much as "hacked together a bit at a time".

And I think you make a good case that, often, someone reaching for this really wanted something iterable, which is what Array.from accepts... though, again, I think you'd very often want to special-case strings.

[-]

balefrost@reddit

Because when you're expecting the argument to your function to be kinda like an array, you probably don't expect to iterate through it character-by-character.

I guess it depends on what the function does. Both of these are reasonable-ish:

obj = ['f', 'o', 'o']
...
Array.prototype.map.call(obj, x => x.charCodeAt(0))

obj = 'foo'
...
Array.prototype.map.call(obj, x => x.charCodeAt(0))

I guess my point is that, for some uses, strings are array-ish. Your point is that, in other cases, you want to treat strings as not array-ish. Those both seem valid in different contexts. But personally, I think I'd err on the side of the less-restrictive version. If a caller also wants to prohibit strings, they can opt to do that. Or there could be a different helper function with a more precise name. isArrayish seems to promise something other than it delivers.

[-]

SanityInAnarchy@reddit

If you're consuming an object which isn't natively a JS array and is - instead - a NodeList you should handle it as a NodeList rather than trying to treat it like an array.

I mean, most likely you're treating it as an iterable instead. (Java has this idea as the Iterable<T> interface.) Depends on the use case... though I also can't think of a single time I wanted to treat something like a NodeList, back when I was writing code that actually dealt with those enough for this to be annoying. Either I want to pretend it's an array, or I want to turn it into an array.

In other languages, they typically have helper libraries to "polyfill" these missing pieces of the vanilla features of a language. The JS equivalent might be lodash.

I think this is probably the right way to do it, though I'm not sure lodash would really fit the modern approach. But with JS, tiny packages makes a certain amount of sense. Keep in mind that every bit of code in your app, including all of its library code, is getting shipped to the client every time someone wants to just load a webpage. "Compiling" a JS app is basically just cating it together in the right order, and then minifying it.

Lodash adds 4kb to every page load, even if you only need a single function out of it. Plus some extra time for the client to gunzip and parse it. Oh, and it's 24kb for the full release. Plus, for better or worse, NPM handles the diamond dependency problem by allowing multiple versions of the same library to be "linked" into the same app. You can even reference multiple versions in the exact same source file. All of which means, if two popular libraries depend on two different versions of lodash, suddenly it's 48kb... and so on.

But even the dumbest of JS "compilers" can figure out that it only needs to include libraries that you actually explicitly depend on.

So even if it's stupidly wasteful to have to download hundreds of tiny dependencies onto a dev laptop, single-function packages, at least at a certain point in time with certain limited dev tools, could've led to smaller JS "binaries", and thus faster page loads.

I think modern JS tools try to do a little better here, but JS makes it hard because of how absurdly dynamic it is. But Typescript completely solves this -- the ts compiler is perfectly capable of detecting unreachable functions and stripping them from a production build. I think it also gets rid of most of the reasons for a function like is-array, too.

I think it's far more reasonable to find a snippet on StackOverflow...

I'd much rather take a dependency than this. Gives you a clear license, authorship, and a way to update it.

But these days, I'd rather add a bigger library.

[-]

rdtsc@reddit

Lodash adds 4kb to every page load, even if you only need a single function out of it.

https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaking

[-]

SanityInAnarchy@reddit

I know it's a long post, but I did address this:

I think modern JS tools try to do a little better here...

Also, if you look at the second sentence of the thing you linked...

It relies on the import and export statements to detect if code modules are exported and imported for use between JavaScript files.

Historically, this allowed it to trim modules, but that still only gets you to a function per module.

[-]

billccn@reddit

querySelectorAll() doesn't return an array though. It returns a NodeList which is another legacy thing.

[-]

MrDilbert@reddit

Fucksake, can someone make NodeList implement Iterator so we can be done with this?

[-]

Those are all iterators. This isn’t a language level limitation. Asking if something is array-like is only useful because that was the iterator convention before we had a real iterators.

We’ve had real iterators for 10 years now.

There is no need to be dynamic in this case. Even if you didn’t want to look at things as iterators, the two examples you listed make up 99% of the use cases for this function, and checking for them explicitly is a lot clearer than using this weird function, if you actually have a need to do that which I’m sceptical you do

[-]

SanityInAnarchy@reddit

Problem is, there are iterables that are not array-like and probably shouldn't be treated as such. For example, is-arrayish explicitly carves out an exception for strings -- you can iterate over a string to get each character, but that probably isn't what you wanted.

The point of being dynamic here is a level of polymorphism that was probably more popular before Typescript, where you might have a function that might do different things if you give it a string vs an array vs an object.

It's borderline, but certainly at the time, and I think still today, this function still saves enough boilerplate to be worthwhile, even if I wish the language didn't need it.

[-]

xTheBlueFlashx@reddit

I created an object with custom .length and .splice properties, and the function returned true.

let fakeArray = {};
fakeArray.length = 4;
fakeArray.splice = () => 'Fake Array Splice';
isArrayish(fakeArray); //should return true

[-]

Caraes_Naur@reddit

The JS community is overall low-skill, has a huge chip on its shoulder, and is still trying to convince us that this DOM-fiddling toy language can run with the big dogs.

NPM is:

One part "package" "manager" (using loose definitions of both)
One part language shim
One part code snippet landfill

Installing packages without locked versions (this exploit would be less effective with that)

Agreed, but I also think on top of locked dependency files in lockfiles they should also have locked signers so that any new version of a locked dependency that isn't signed by the same author would be easily apparent.

[-]

rubeyi@reddit

Totally. It's hard to talk about this stuff without it just sounding like "back in my day..."

but as a polyglot and someone who came of age before JS took over, I think a lot is wrong with the engineering culture around web dev.

Case in point, my "favorite" GitHub issue: * Node occasionally gives multiple files/folders the same inode

In summary, Node devs were storing filesystem inodes as numbers, and then the inodes (which are not numbers) were subject to precision loss.

A couple of my favorite comments:

Personally, I would prefer if Node fixed this properly going forward.

hey, me too! samesies!

this will break comparison for inodes whose bit pattern result in NaN, since NaN != NaN

man, that'd suck... if they were numbers!

Again, these were not garden-variety web app devs, they were the maintainers of nodejs. It took 3 months of bickering to land on a fix, and the fix involved continuing to store inodes as numbers. (It just so happened that JS added a BigInt library around that time.)

The problem is the JS ecosystem, and the average level of talent, and there's no fixing that. All you can do is minimize the amount of libraries you drag in, and from time to time (like I had to today) rip a bunch of things out because you woke up and, yay, NPM has crypto rootkits now.

[-]

vengeful_bunny@reddit

Most JS repo makers don't upload the node_modules tree, to save space, and in the hope that when the consuming dev runs "npm install", and they get the latest versions, the newer versions are better. That's a problematic assumption. I'm not recommending it to others, and these are private repos so perhaps it's not relevant to NPM packages, but I upload everything to my repos including the node_modules tree. I've gotten burned too many times when cloning to my cloud servers because some upgraded package broke something else critical to my build.

[-]

Shne@reddit

Installing packages without locked versions (this exploit would be less effective with that)

Except that's exactly what package-lock.json has done for a long time now.

[-]

Largest NPM compromise in history so far.

[-]

andrewfenn@reddit

Could happen to any language and yet it's always them..

[-]

RackemFrackem@reddit

Yes, "in history" generally means "in history so far" and not "in history and future".

Advocatemack@reddit (OP)

This is a little self-promoting. Aikido Research team publish all our findings on intel.aikido.dev usally this takes 30 minutes from when a malicious package is uploaded (it is a AI based detection pipeline we use)
We created an open-source tool called SafeChain https://www.npmjs.com/package/@aikidosec/safe-chain This wraps around NPM and each tiome you run npm install it checks for malicious packages and blocks them. So in this case it would have prevented you from installing malicious packages from 30 minutes after the malware was published, (the malicious packages were live for 4 - 6 hours)

[-]

NoSweet595@reddit

How are the affected versions identified and published at the source? I see the maintainer's own list of affected versions in social posts but I can't tell whether sources corroborate it or merely reformulate it.

Even if Aikido did the whole threat intelligence on it, there should be a caption on the affected versions table that indicate the source, even if it's their own intel.

[-]

freecodeio@reddit

what I've learned from modern attacks is that as long as you don't have a crypto wallet you're safe

[-]

todo_code@reddit

What I've learned is thank God for crypto. All those idiots can just go be in a corner and not effect me.

[-]

wasabichicken@reddit

But they do. The cryptbros' number crunching amounts to some 68 TWh annually, or about the energy consumption of a medium-sized European country. That energy is heating the world you and I live in, contributing to global warming.

Like leaded fuel, it's one of the things I wish had never been invented.

[-]

phlipped@reddit

note: the energy consumption (and corresponding heat release) is not a significant contributor to global warming in itself - it's the CO2 that gets released to make the energy in the first place that causes global warming

[-]

freecodeio@reddit

yes because all crypto miners run on clean energy like windmills

[-]

phlipped@reddit

Sigh, not what I said or implied.

Op originally implied that the heat from the energy being consumed contributes to global warming, which is not true. If it WERE true, then renewables wouldn't help combat climate change - they release just as much heat energy as any other source.

Op has since edited their comment to clarify that it is the PRODUCTION of energy which causes global warming, which IS true most of the time (i.e for carbon-fuel based energy production).

[-]

Rattle22@reddit

Op originally implied that the heat from the energy being consumed contributes to global warming, which is not true

Crypto is a lot more important than cat photos.

Think we'll have to agree to disagree on that.

[-]

wottenpazy@reddit

Luckily cat photos can also be stored on a distributed blockchain more permanently than relying on a single entity. Your cat photos can now be stored indefinitely thanks to the collective efforts of humankind and our new intergenerational technology.

[-]

gefahr@reddit

I know you're trolling, but, who is paying to host and serve someone else's unreadable cat pictures?

You're just describing a git repo backed by torrents, but with more compute wasted.

[-]

wottenpazy@reddit

I'm not trolling I just occasionally have to point out ridiculous thinking because I think Bitcoin is extremely important.

who is paying to host and serve someone else's unreadable cat pictures?

I don't understand this question and your torrent + git repo analogy doesn't work since torrents don't store the actual file data and bad actors can easily poison the data. There are other decentralized storage mechanisms (Filecoin) but I can't guarantee the longevity of Bitcoin (the example was slightly tongue-in-cheek since Bitcoin is better designed for storing receipts than jpegs, which is important enough).

[-]

gefahr@reddit

But torrent nodes do store the actual data, trackers don't.

Git inclusion is because git is a blockchain, and gives you the content-addressable piece with its hashes.

[-]

wottenpazy@reddit

Git is not even close to a blockchain, it's just a Merkle tree without any decentralized consensus mechanisms. Someone still has to merge. Torrents do not have any of the necessary security mechanisms to block bad actors from poisoning swarms since there's a substantially lower cost to the bad actor to do so than the good actors maintaining the file. Bitcoin solves both of this and is already deployed around the world and has been working for 15+ years.

[-]

balefrost@reddit

and has been working flawlessly for 15+ years

I guess it remains to be seen if anybody's wallet was affected by this particular attack, but people certainly have had various crypto assets stolen by malicious actors, with AFAIK no recourse unless the majority of nodes decide to fork.

I wouldn't call that "working flawlessly".

[-]

stormdelta@reddit

not the other thousands of energy consuming ones?

Bitcoin even more so than most cryptocurrency incentivizes wasting power that scales not with actual use (the actual use doesn't even scale at all, a separate problem), but with the price. Which is the thing nearly every cryptobro wants to go up, even though it has no effect on the actual supposed utility. A normal datacenter scales energy based at least somewhat on actual loads and usage.

Worse, crypto mining hardware and setups are so specialized that they have no other purpose. A normal datacenter typically has more general purpose hardware that can be used for many different kinds of software loads.

And all of that is assuming I think bitcoin has any reason to exist, I very much don't. The only purpose cryptocurrency serves is illegal transactions, and while not all illegal transactions are unethical, monero addresses those niche edge cases better than bitcoin does and isn't as prone to speculative manipulation/gambling.

[-]

wottenpazy@reddit

If the price goes up then people are finding it more useful. An auditable, truly fixed supply of something is extremely useful, perhaps even in ways we cannot imagine. The fact that you can move it around digitally is just a bonus add.

I won't address the facetious argument that bitcoin just facilitates illegal transactions since I just demonstrated a way that it does not. Do you think the boomers are buying Bitcoin ETFs to pay for drugs and crime? There are thousands of individuals and companies stockpiling it as collateral to borrow against because it is such a hard asset.

Monero is not a fixed supply asset nor do I have any problems with it existing. Maybe one day Bitcoin will get an zero-knowledge proof L2 privacy layer, that would be pretty cool.

[-]

stormdelta@reddit

If the price goes up then people are finding it more useful.

Useful for what? It sucks as an actual currency: besides all the security problems that have already been covered extensively, bitcoin in particular literally can't scale, is very slow, and very expensive to actually use.

It's so bad at being a currency even compared to other cryptocurrencies that it's easier to buy grey market drugs now with monero than bitcoin.

An auditable, truly fixed supply of something is extremely useful, perhaps even in ways we cannot imagine.

And you wonder why people think you're in a cult.

since I just demonstrated a way that it does not.

No, you didn't. You just said it was useful without even giving an example.

Do you think the boomers are buying Bitcoin ETFs to pay for drugs and crime?

ETFs are traditional finance. Meaning these people aren't even actually buying bitcoin, so whatever properties it supposedly has or enables aren't even relevant. The SEC should never have approved these, but it's become compromised and fraud is being allowed to run rampant (cryptocurrency is just one of many examples).

There are thousands of individuals and companies stockpiling it as collateral to borrow against because it is such a hard asset.

No, they're engaging in speculative gambling betting that the price will go up. That's not the same thing at all.

[-]

hawaii_dude@reddit

It bothers me that leaded fuel is still used.

[-]

wottenpazy@reddit

Since when do you get to dictate what other people use energy (they are paying for) on? Crypto may not matter to you, but it can matter to someone else.

[-]

Ok-Interaction-8891@reddit

Yes, like human traffickers, drug and arms dealers, and other black market transactors.

The point is that the mining and transacting of cryptocurrency is a massive waste of energy for a currency that doesn’t need to exist, that isn’t better than previous currencies, and that makes it that much harder to direct energy and resources to where they’re actually needed. Burning energy on crypto is irresponsible and foolish, particularly when over six hundred million people live without electricity and about one third of all people live without a clean source of fuel (like electricity) to cook with. That is to say, they have to burn solid fuel to cook food; yikes.

Playing this little game where we pretend that what we do doesn’t have downstream consequences on many other people and the planet is childish and ignorant.

[-]

wottenpazy@reddit

Luckily Bitcoin mining is the best way we've discovered to get electricity to those people since it makes energy development more cost-neutral by incentivizing energy production.

[-]

stormdelta@reddit

Even if what you said made an ounce of sense, that argument only holds if bitcoin fails later and frees up the excess energy production for something actually useful.

[-]

todo_code@reddit

I meant have an effect on, on my phone, going quick

[-]

BugBaba_dev@reddit

Crypto: where your wallet cries faster than you can say HODL 😅

[-]

Decent_Ad_9615@reddit

affect*

https://fastcode.io/2025/09/02/the-hidden-vulnerabilities-of-open-source/

https://fastcode.io/2025/09/02/the-hidden-vulnerabilities-of-open-source/

^ great recap of that whole ordeal

[-]

Ok-Quarter-8787@reddit

I found out about this attack because I had just run ncu; npm i on a project I am working on and the vulnerabilities were printed on the screen. I quickly deleted all node modules. But today i ran the installer again and ran ncu again in case packages had been updated. No updates. I reinstalled everything and ran npm audit and I get 0 vulnerabilities??? Have the packages been fixed?

[-]

pat_trick@reddit

Another lesson in "don't click on shit in your email, always manually visit the site in question".

[-]

Middle_Citron_1201@reddit

That advice is about as useful as abstinence only education

Sure. It works and if you’re someone who’s actually going to do that then that’s a good you have protected yourself.

It is not actually use useful advice to give people in general if we all know, it will never be followed

[-]

pat_trick@reddit

It's one step of many, not the only tool in the entire toolkit.

[-]

wottenpazy@reddit

Click to activate your 5% reward categories!

My bank, quarterly

This is a perfect example of why updating as aggressively as possible is not really a good default.

[-]

teerre@reddit

Do you understand the concept of an exception?

[-]

emperor000@reddit

Sigh. Never mind.

[-]

Fit_Sweet457@reddit

I'm not arguing against version-locking, I get why it's best practice and I do it too. The point I don't get is how it's supposed to help with attacks like this.

At my company not only we verify NPM modules that we use, but we also manually download and place them in our special node modules directory so that you can't even update a package by accident.

That's the first time I've ever heard of a policy like this, and I've seen a quite a few projects at different large companies. I have a hard time imagining how one could do this for larger projects like React or Next.js without having to dedicate multiple full-time employees just for reviewing dependencies.

[-]

freecodeio@reddit

You are not verifying for functionality, you are verifying for obfuscated code, suspicious code, use of networking. And can be done once per package.

[-]

gefahr@reddit

I think because of some of the features of JavaScript, it's quite hard to statically assert something like "this package doesn't use networking."

according to https://github.com/github/advisory-database/issues/6099, the list of affected versions was set to be wider than what was actually correct

[-]

SoInsightful@reddit

For fun, I checked out the is-arrayish. Apparently this is arrayish:

isArrayish({ length: 1, splice() {} });
// true

Not a single explanation of what this is supposed to be good for. Just "Check if an object can be used like an Array", which the object above very obviously cannot.

If you install this dependency as a direct dependency and use it in your production app, I honestly think you deserve to have a small amount of crypto stolen from your wallet.

[-]

Ashamed-Simple-8303@reddit

Left-pad all over. The entire set of packages sound like something simple you should not depend upon. But I assume some big ass libraries do and you sont even know you are using this bs.

[-]

One_Being7941@reddit

CCP again.

[-]

dodeca_negative@reddit

But I thought having an app built out of a tree of 10,000 micro packages that I mostly don’t even know I’m using was a good thing

[-]

SwiftOneSpeaks@reddit

No, no, it's much better to import a single massive library that is 10,000 times bigger. /s

Does anyone know if simply installing these dependencies on a dev system without running any code will have compromised the system? Were there any post install scripts?

Typically I had just installed puppeteer which pulled a bunch of these deps in and then failed the NPM audit which lead me here. I was shocked to see the reports on github only posted 2 hours ago at the time.

[-]

paulomadronero@reddit

No. This is how it works:
You create a webapp and use one of these as a dependency in the front end code.
You did a prod release of your webapp with one of the compromised packages built on it.
One of your users uses your compromised webapp.
When the webapp launches, the malicious packages start doing their thing.

[-]

ClownCombat@reddit

Like, could you describe a usecase where it can affect a user, even if the website or webapp does nothing with crypto wallets?

[-]

jdprgm@reddit

it wouldn't. and it seems odd how poorly the actual issue has been explained probably just to sensationalize it. i guess they could have just forced any websites that deployed this malware to trigger wallet prompts but that would have been too sus if like rottentomatoes randomly was trying to interact with your wallet.

[-]

[-]

starm4nn@reddit

You could even have it work similar to .net framework where there are multiple standard libraries.

If these become popular enough they can become standard language features.

[-]

Whispeeeeeer@reddit

I think they might just need to create a new subset of packages that are given a special designation. The packages should have rules like:

"New versions can't be published without a PR from multiple people"

clicking on an npmjs[.]help phishing link, okay, sure.

and then? do you not use a password manager? do you think "huh, my password manager doesn't autofill anything for this url, let me just manually get the password out of my password manager and paste it in anyway"?

[-]

danielv123@reddit

Its shocking how many sites won't work well with password managers.

[-]

ROGER_CHOCS@reddit

I despise apps and websites that don't work bitwarden..

[-]

chalks777@reddit

According to this report only about 36% of people in 2024 were using a password manager.

So how does it "injects itself into browser"

It modifies standard library methods.

Does running npm install somehow infects browser or does this malicious code only work on the page it gets executed?

Only works on the page. And as long as you're not doing any crypto related thing, it does nothing.

[-]

fupaboii@reddit

More specifically, you’d need to be doing crypto related things on the domain that has the affected code, correct?

[-]

the_horse_gamer@reddit

yes, it hooks into window.crypto, fetch, and XMLHttpRequest on the current domain (more accurately in the current realm due to the existence of iframes, but that shouldn't matter in most cases)

the first is a standard API for generating cryptographically secure random numbers

the other two are standard APIs for sending and receiving data over http. the malware checks for crypto-related requests and redirects them to a different domain.

for the largest ever attack on npm, we sure got lucky.

npm ls --all

or

pnpm list --depth Infinity

perhaps?

[-]

chalks777@reddit

even better you can specify the package you want to know about

npm ls chalk

Or if you're not sure what to worry about, you can npm audit which will give you a list of things to worry about.

[-]

BugBaba_dev@reddit

This incident came from a maintainer account takeover, and malicious releases of popular npm packages (like chalk, debug, color, plus related deps) were pushed. The bad versions have been yanked/flagged and clean releases are being restored. There is no way to “remote-neutralise” what’s already on a machine - you stop future runs by uninstalling/locking to safe versions and upgrading.

Pattern matches recent attacks: phished maintainer -> malicious versions -> npm and maintainers remove the bad versions and mark them as unsafe -> users have to update to clean versions and audit their systems locally. (as we also saw with the July “is” compromise and the late-Aug Nx incident).

[-]

Level-Farmer6110@reddit

man i saw 198 critical sec vulnerabilities and thought i messed up pretty bad, thank God its not my fault :sob:

[-]

Advocatemack@reddit (OP)

UPDATE: We have found another package from a different maintainer that has been compromised. https://www.npmjs.com/package/proto-tinker-wc/v/0.1.87

This one isn't that big but proves that the phishing campaign has compromised multiple maintainers.

[-]

Jonno_FTW@reddit

That package has already been removed

[-]

Selentest@reddit

npm ls -all | grep -E 'backslash@0.2.1|chalk-template@1.1.1|supports-hyperlinks@4.1.1|has-ansi@6.0.1|simple-swizzle@0.2.3|color-string@2.1.1|error-ex@1.3.3|color-name@2.0.1|is-arrayish@0.3.3|slice-ansi@7.1.1|color-convert@3.1.1|wrap-ansi@9.0.1|ansi-regex@6.2.1|supports-color@10.2.1|strip-ansi@7.1.1|chalk@5.6.1|debug@4.4.2|ansi-styles@6.2.2|proto-tinker-wc@0.1.87'

[-]

Selentest@reddit

To quickly check dependency tree

[-]

redditrasberry@reddit

I love it!

But also the irony: the solution to having downloaded random code from the internet is to download and run more random code from the internet :-)

[-]

Selentest@reddit

But it doesn't download anything, unless I'm missing some obvious joke here?

[-]

Foghkouteconvnhxbkgv@reddit

I'm not even sure I have this downloaded but someone told me this was happening. Is there something I should be doing to isolate this or something?

[-]

moeanimuacc@reddit

Do we not know what's the actual risk for affected devices?

Is the session, the browser, the machine or even the network fucked? The CVE says to burn the machine but as far as I can tell from articles and these threads the attack was extremely niche.

So do we know what's actually compromised? Are keys and secrets on a machine safe? Local files? .envs? Browser inputs and saved credentials? Is there a risk for a backdoor to have been set by the attacker?

[-]

Ikeeki@reddit

I feel like this happens at least once a year and especially in the Npm ecosystem.

Everything okay over there?

[-]

urbrainonnuggs@reddit

Is my favorite package 'is-odd' safe?

[-]

Steadexe@reddit

Only is-even, oh wait it depends on is-odd

[-]

redditrasberry@reddit

hmm, make sure to check is-odd-or-even as well, they both depend on that

[-]

Dazzling_Marzipan474@reddit

Just heard this and I'm definitely not a developer.

But why is 1 person in charge of so much stuff? Also how did they get phished? That's like the most basic scam. They didn't verify the email with anyone? Like wtf?

[-]

sparr@reddit

How many of those 2B downloads are without a version specified?

[-]

npm doesn't allow reuploading different code for an existing version of a package after 24 hours

[-]

Ythio@reddit

If 2.0.0 is the current version, 1.2.0 is an old version, I don't see why I can't push a 1.2.1 and if your version specified is \^1.2.0 or <1.3.0, you will get it.

[-]

Shne@reddit

I'm pretty sure that hasn't been the case for several years now. Npm will generate a package-lock.json file automatically, and both npm ci and npm install will get the version to install from there over package.json.

Of course, if you don't commit your package-lock.json file, you could be compromised in the way you describe.

[-]

Ythio@reddit

Largest NPM Compromise in History - Supply Chain Attack

Or, in other words, Tuesday

[-]

stormdelta@reddit

If you can't be bothered to write something yourself why do you expect us to read it?

You should have just linked to the actual report and not added all this meaningless generated noise.

[-]

How the Malware Works (Step by Step)

At first I thought this was yet another fake exploit report due to this AI-generate cancer, but apparently it's real... and yet we're still using AI to generate shit about it?

[-]