npm missing sha512 integrity

alexjeffreys_3320

When publishing or mirroring npm packages, the package only contains the sha1 based ".shasum" field and is missing the sha512 ".integrity" field.

I am trying this on proget free 5.3.24. It can easily be reproduced by using an "npm view" command on any package from a proget feed, either private, uploaded, or mirrored.

e.g.

npm view abbrev@1.1.1 --registry http://proget.local/npm/npm-mirror/
npm view abbrev@1.1.1 --registry https://registry.npmjs.org/

[snip]

dist
.tarball: https://registry.npmjs.org/abbrev/-/abbrev-1.1.1.tgz
.shasum: f8f2c887ad10bf67f634f005b6987fed3179aac8
.integrity: sha512-nne9/IiQ/hzIhY6pdDnbBtz7DjPTKrY00P/zvPSm5pOFkl6xuGrGnXn/VtTNNfNtAfZ9/1RtehkszU9qcTii0Q==

This ".integrity" metadata not being available on proget.

Is this not supported? If not, is this on the development roadmap?

Thank you

stevedennis

Hi @alexjeffreys_3320 ,

Why don't we put together a Feature Request for this?

To start with, how would adding .integrity metadata help? Is this for another tool integration? I understand that sha512 > sha1, but if you've already got a secure connection to ProGet, then you can already trust the packages you downloaded.

Thanks,
Steve

alexjeffreys_3320

Hi @stevedennis

When I have been installing packages via registry.npmjs.org, npm is utilising the sha512 integrity for pretty much all packages. If I then set my default registry to switch to using proget, the npm install fails.

So in my case, I have been developing against the main npm registry (other than some private packages) and I'm setting up proget as part of a ci process which I want to use proget as the primary source for all packages.

I guess my workaround today would be to delete the package-lock.json and run a fresh npm install against proget registry, but this is not ideal - I don't really want to force all developers to MUST use proget instead of the core registry (for open-source packages).

I'm just trying to look at when the main npm registry started to roll out sha512 - I think around npm v5. It's pretty much the de-facto standard, so I would hope this is a strong argument for a feature request to be worked on, and hopefully not difficult to implement either.

So far as security is concerned, I guess it's fine if the whole trust model is "implicitly trust proget". If I've developed something and locked in to packages I've used from the core npm registry, I can no longer (easily) check that the packages proget has in its registry are authentic?

How should this proceed then, by creating a Feature Request?

Many thanks in advance

Alex

stevedennis

Thanks @alexjeffreys_3320,

So basically, npm install can fail when you transition projects from npmjs.org to ProGet. I can see that being inconvenient, since you'd have to redo the lock file.

In theory it should be an easy fix to do, right? But just wanted to understand why

We can just use this thread as a feature request, I've already marked it that internally, and it'll get evaluated from here. That'll take a few days, but we'll try to respond within a week about the status! Please stay tuned

alexjeffreys_3320

@stevedennis - that's great, many thanks!

stevedennis

FYI @alexjeffreys_3320 this is currently targeting 5.3.26, which is planned for April 2 (PG-1914) - we'll update if it gets tricky or problematic