-
-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include checksum of dependency in dub.selections.json #1723
Comments
I would like to see this work for dependencies to all kinds of files including pre-built libraries ( Then all dependencies could be queried using their content hash rather name and have them be renamed if needed. |
When should the selections file be tagged with the hash and should it be automatic or hidden behind a flag? I'm thinking short term behind a flag and long term automatic. |
No switch. It needs to be transparent for users across versions. |
Ok, great. So the dub.selections.json file will be changed automatically for every dependency upon initial build? |
No only in the project being built. We can't change dependencies selections. We might want to consider an explicit upgrade otherwise we'll have to blindly accept the checksum I think (?). |
How should the {
"fileVersion": 1,
"versions": {
"concepts": "0.0.8"
}
} to {
"fileVersion": 1,
"versions": {
"concepts": {"version": "0.0.8", "sha256": "$INITIAL_FILE_CONTENT_SHA256_DIGEST"}
}
} ? For comparison note that we currently have, for instance "windows-headers": {"repository":"git+https://github.com/kinke/windows-headers.git","version":"4922dbdf2057ed239c21c4b3161accb7a0695e01"}, |
|
Actually perhaps none. Since we already accept objects we can make the checksum optionals. |
|
This is valid: {
"fileVersion": 1,
"versions": {
"bitblob": {"path":"submodules/bitblob/"},
"vibe-d": {"version":"v0.9.5"},
}
} So the field type of an entry in |
So for the hashing shall we use something like {
"fileVersion": 1,
"versions": {
"bitblob": {"path":"submodules/bitblob/", "checksum":"..."},
"vibe-d": {"version":"v0.9.5", "checksum":"..."},
}
} or {
"fileVersion": 1,
"versions": {
"bitblob": {"path":"submodules/bitblob/", "sha256":"..."},
"vibe-d": {"version":"v0.9.5", "sha256":"..."},
}
} |
diff --git a/source/dub/recipe/selection.d b/source/dub/recipe/selection.d
index 097f735b..bfa50a11 100644
--- a/source/dub/recipe/selection.d
+++ b/source/dub/recipe/selection.d
@@ -26,6 +26,7 @@ private struct SelectedDependency
@Optional @Name("version") string version_;
@Optional string path;
@Optional string repository;
+ @Optional string checksum;
public void validate () const scope @safe pure
{ That would be enough to ensure future-proofness. |
How about using [a subset of] the Sub-Resource Integrity standard: https://www.w3.org/TR/SRI/#introduction This should allow it to be future-proof and compatible with a variety of tools, which could be useful e.g. for packaging. Also, what exactly will be checksummed? One simple answer is the ZIP file that one gets from |
The selections file only contains version numbers. However, a malicious library author could repoint a tag to a different version, wreaking havoc amongst users.
For example:
By verifying the checksum as part of the second download, this issue is mitigated: the library user needs to audit the dependency only the first time they download it.
The text was updated successfully, but these errors were encountered: