You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I hit spurious shasum checking errors consistently with npm so my vision is clouded by disliking this validation. I presume the npm problems are due to a lag between the availability of the published package and the updated shasum (is npm serving them from different caching endpoints?). I've not encountered a case yet or heard of reports where a node-pre-gyp download from https S3 was partial or corrupt. This certainly may be because we don't validate it (what this ticket was about) however I'm strongly inclined now to leave this feature off until someone steps up with a proposal that isboth:
solid security-wise
will not create a potential for spurious errors - e.g. only breaks when the network causes truncation of downloads or the binaries are actually tampered with.
Activity
springmeyer commentedon Oct 17, 2014
I hit spurious shasum checking errors consistently with npm so my vision is clouded by disliking this validation. I presume the npm problems are due to a lag between the availability of the published package and the updated shasum (is npm serving them from different caching endpoints?). I've not encountered a case yet or heard of reports where a node-pre-gyp download from https S3 was partial or corrupt. This certainly may be because we don't validate it (what this ticket was about) however I'm strongly inclined now to leave this feature off until someone steps up with a proposal that isboth: