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
Locally computed integrity values would allow projects to use the strongest available cryptographic hash for all the dependencies they have. In particular, when a registry doesn't support strong integrity values (i.e. sha1) a locally computed integrity value (e.g. using sha512) could improve the project's security.
Example
Currently, installing any package from GitLab's npm registry always results in a sha1 integrity value (source). A concrete example:
There is, as far as I'm aware no mechanism for npm to instead put a sha512 hash in the lockfile.
How
Current Behaviour
Whenever the npm CLI puts integrity values in the lockfile, it uses the integrity value provided by registry.
Desired Behaviour
High level
The npm CLI should put locally computed integrity values -- computed using the "strongest" available, or a specified, hashing algorithm -- in the lockfile.
Flow
The npm CLI performs the installation process as it currently works (including, presumably, checking if the registry provided integrity value matches the package content).
The npm CLI recomputes the integrity value using the "strongest" available or the specified hashing algorithm and puts that value in the lockfile.
Of course, if the registry provided value is already using that algorithm, the implementation could skip recomputing it.
Configuration
At a minimum I would like to see an option that allows users to specify what hashing algorithm to use when installing.
I personally think it would make sense for the npm CLI to default to a "stronger" algorithm when no such option is provided. In the current state, where sha1 and sha512 are supported, this would mean defaulting to sha512. But, in case there's any concerns about this point, I don't think it's crucial.
Miscellaneous
I want to point out that this change opens the npm CLI up to cryptography downgrade attacks (i.e. a project could end up with only "weak" sha1 hashes even when only fetching packages from a registry that provides "strong" sha512 hashes). I personally think the trade-off (being able to use stronger hashes when the registry only provides weak ones) is worth it, particularly since the option value is not the result of a negotiation (like in networking).
I'm not suggesting any of this should automatically be applied to pre-existing, say sha1, integrity values in the lockfile (though I wouldn't mind it if there was some mechanism in the CLI to upgrade pre-existing integrity values). Though I would note that it might confuse users if they specify that sha512 hashes should be used only to find out that there's still (pre-existing) sha1 hashes in their lockfile.
Motivation ("The Why")
Locally computed integrity values would allow projects to use the strongest available cryptographic hash for all the dependencies they have. In particular, when a registry doesn't support strong integrity values (i.e.
sha1
) a locally computed integrity value (e.g. usingsha512
) could improve the project's security.Example
Currently, installing any package from GitLab's npm registry always results in a
sha1
integrity value (source). A concrete example:results in the following entry in
package-lock.json
:There is, as far as I'm aware no mechanism for npm to instead put a
sha512
hash in the lockfile.How
Current Behaviour
Whenever the npm CLI puts integrity values in the lockfile, it uses the integrity value provided by registry.
Desired Behaviour
High level
The npm CLI should put locally computed integrity values -- computed using the "strongest" available, or a specified, hashing algorithm -- in the lockfile.
Flow
Configuration
At a minimum I would like to see an option that allows users to specify what hashing algorithm to use when installing.
I personally think it would make sense for the npm CLI to default to a "stronger" algorithm when no such option is provided. In the current state, where
sha1
andsha512
are supported, this would mean defaulting tosha512
. But, in case there's any concerns about this point, I don't think it's crucial.Miscellaneous
sha1
hashes even when only fetching packages from a registry that provides "strong"sha512
hashes). I personally think the trade-off (being able to use stronger hashes when the registry only provides weak ones) is worth it, particularly since the option value is not the result of a negotiation (like in networking).sha1
, integrity values in the lockfile (though I wouldn't mind it if there was some mechanism in the CLI to upgrade pre-existing integrity values). Though I would note that it might confuse users if they specify thatsha512
hashes should be used only to find out that there's still (pre-existing)sha1
hashes in their lockfile.References
The text was updated successfully, but these errors were encountered: