Some packages have dist.tarball as http and not https


(Karan Thakkar) #1

What I Wanted to Do

Generate a pkglock with no packages having an http resolved url

What Happened Instead

Some packages in the pkglock had http urls. Specifically, these two packages (onetime@1.1.0 and compression@1.7.2) have their dist.tarball fields as http instead of https.

Reproduction Steps

Use the package.json in this gist to generate the pkglock:


  1. Versions:
{ npm: '5.6.0',
  ares: '1.10.1-DEV',
  cldr: '32.0',
  http_parser: '2.8.0',
  icu: '60.1',
  modules: '57',
  napi: '3',
  nghttp2: '1.32.0',
  node: '8.11.3',
  openssl: '1.0.2o',
  tz: '2017c',
  unicode: '10.0',
  uv: '1.19.1',
  v8: '6.2.414.54',
  zlib: '1.2.11' }
  1. npm info onetime@1.1.0 dist.tarball gives npm info compression@1.7.2 dist.tarball gives

npm install downgrading resolved packages from https to http registry in package-lock.json
(Kat Marchán) #2

npm view info for both of these packages:

# onetime
➜ npm view onetime@1.1.0 dist.tarball
➜ npm view onetime@latest dist.tarball

# compression
➜ npm view compression@1.7.2 dist.tarball # this is also latest

It looks pretty isolated to specific packages at some specific versions. Might be worthwhile to throw a follower at the registry and find any others with weird data like this.

(Kat Marchán) #3

As far as making sure you’re fetching these from https goes: because of the way the main registry works, you should be able to replace the http with https and it’ll Just Work™. I’ve forwarded this to the @services-team in the meantime so they can take a look and see if there’s any others. Not sure why this happened.

(Karan Thakkar) #4

Perfect! That’s what we have right now: a precommit hook to replace http with https. :slight_smile:

(Karan Thakkar) #5

Hello, just wanted to provide more info that I came across today. In a previous version of our pkglock, I can see that the dist.tarball for onetime@1.1.0 is So maybe something happened in the registry at some point in time that it started returning http urls instead of the old https ones.

(Kat Marchán) #6

yeah we already figured out what it is and know how to fix it. It turns out to have affected certain package versions of many packages, so we need to run a pretty big job before it’s fixed. It only happened for a little while, and it was pretty easy to scan for. Hang tight and it’ll be fixed eventually.

(Jeremy Thomerson) #7

@zkat what’s the status here? This is a pretty significant problem … it’s a bit shocking to see so many issues around the internet for this problem and it not getting the attention it deserves.

(Andrew Goode) #8

Is this the cause of the issue here? npm install downgrading resolved packages from https to http registry in package-lock.json

I’m still seeing specific versions of packages resolving to http, so I assume it’s still an issue. Any updates?

Here are some examples:

$ npm info minimist dist.tarball

$ npm info stream-combiner dist.tarball

$ npm info got@6.7.1 dist.tarball

$ npm info pause-stream dist.tarball

(Bjorn Stromberg) #9

@services-team Can we get an update on this? It’s been over two months and we’re still getting http instead of https in our tarball URIs.

$ npm info create-hash dist.tarball

 $ npm info browserify-rsa dist.tarball

(Julien Vanier) #10

My projects are also affected by some packages returning http registry links.

$ npm show onetime@1 dist.tarball
onetime@1.0.0 ''
onetime@1.1.0 ''

$ npm show lodash@4.17 dist.tarball
lodash@4.17.0 ''
lodash@4.17.1 ''
lodash@4.17.2 ''
lodash@4.17.3 ''
lodash@4.17.4 ''
lodash@4.17.5 ''
lodash@4.17.9 ''
lodash@4.17.10 ''
lodash@4.17.11 ''