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
When using a proxy, it's useful for vgo to be able to fetch go.mod files without fetching the whole module. The go.mod file is needed for dependency resolution also when the specific package being built does not depend on the module. However, go.mod files are not verified by go.modverify, and we want proxies to be untrusted.
Following untrusted go.mod can turn out to be a bad idea in a number of ways. An attacker might for example downgrade the user to a known vulnerable version, or to an old version including an attacker controlled transitive dependency. In general, allowing an attacker to change behavior is recipe for disaster.
This is a proposal for a hashing scheme that will allow the efficient verification of go.mod files without extending the go.modverify entries, by building a poor man Merkle tree.
And a new field ModVerifier is added to the .info JSON file, consisting of the module Hash1.
This way a client can verify a go.mod file with only the Hash1 from the .info file (effectively a Merkle tree inclusion proof) and the Hash2 from modverify, which did not get any bigger.
If a hash with version 1 is encountered in modverify, the whole package is fetched, and the hash is replaced with a version 2 hash. If the .info does not contain a ModVerifier, the whole package is fetched. Note that proxies can add ModVerifier on their own.
Alternatively, we can implement a full Merkle tree, which would allow us to verifiably fetch any file or directory from within a larger module, but I don't see this becoming necessary soon.
It is a bit unclear to me how much damage a proxy can do by faking .info responses, because those are going to be much harder to secure, but at least only affect the stage of adding dependencies, and not the reproducible build stage.
The text was updated successfully, but these errors were encountered:
When using a proxy, it's useful for vgo to be able to fetch go.mod files without fetching the whole module. The go.mod file is needed for dependency resolution also when the specific package being built does not depend on the module. However, go.mod files are not verified by go.modverify, and we want proxies to be untrusted.
Following untrusted go.mod can turn out to be a bad idea in a number of ways. An attacker might for example downgrade the user to a known vulnerable version, or to an old version including an attacker controlled transitive dependency. In general, allowing an attacker to change behavior is recipe for disaster.
This is a proposal for a hashing scheme that will allow the efficient verification of go.mod files without extending the go.modverify entries, by building a poor man Merkle tree.
A Hash2 is defined as:
And a new field ModVerifier is added to the
.info
JSON file, consisting of the module Hash1.This way a client can verify a go.mod file with only the Hash1 from the
.info
file (effectively a Merkle tree inclusion proof) and the Hash2 from modverify, which did not get any bigger.If a hash with version 1 is encountered in modverify, the whole package is fetched, and the hash is replaced with a version 2 hash. If the
.info
does not contain a ModVerifier, the whole package is fetched. Note that proxies can add ModVerifier on their own.Alternatively, we can implement a full Merkle tree, which would allow us to verifiably fetch any file or directory from within a larger module, but I don't see this becoming necessary soon.
It is a bit unclear to me how much damage a proxy can do by faking
.info
responses, because those are going to be much harder to secure, but at least only affect the stage of adding dependencies, and not the reproducible build stage.The text was updated successfully, but these errors were encountered: