-
Notifications
You must be signed in to change notification settings - Fork 208
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
Lockfiles update #236
Comments
It might make sense to copy the
"node_modules/@azure/core-http/node_modules/tough-cookie": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/tough-cookie/-/tough-cookie-4.0.0.tgz",
"integrity": "sha512-tHdtEpQCMrc1YLrMaqXXcj6AxhYi/xgit6mZu1+EDWUn+qhUf8wMQoFIy9NXuq23zAwtcB0t/MjACGR18pcRbg==",
"dependencies": {
"psl": "^1.1.33",
"punycode": "^2.1.1",
"universalify": "^0.1.2"
},
"engines": {
"node": ">=6"
}
},
|
One note on the structure. I think i'd prefer change to omit the That way the 'resolved' property is something that can actually be placed into a ie
|
I think the resolved property should point to the exact SHA rather that the major.minor.patch semver label. While the patch version should be immutable, nothing prevents it from being mutated. The lockfile should point to the exact SHA. Instead of Before:
After:
|
I was using an outdated example, sorry about that. We are already using the hash in To add dependencies for a devcontainer.json, e.g.: {
"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
"features": {
"ghcr.io/codspace/dependson/C": true
}
} We could just list them without options, but including any version information. E.g.: {
"features": {
"ghcr.io/codspace/dependson/A": {
"version": "2.0.1",
"resolved": "ghcr.io/codspace/dependson/a@sha256:932027ef71da186210e6ceb3294c3459caaf6b548d2b547d5d26be3fc4b2264a",
"integrity": "sha256:932027ef71da186210e6ceb3294c3459caaf6b548d2b547d5d26be3fc4b2264a",
"dependsOn": [
"ghcr.io/codspace/dependson/E"
]
},
"ghcr.io/codspace/dependson/C": {
"version": "2.0.0",
"resolved": "ghcr.io/codspace/dependson/c@sha256:db651708398b6d7af48f184c358728eaaf959606637133413cb4107b8454a868",
"integrity": "sha256:db651708398b6d7af48f184c358728eaaf959606637133413cb4107b8454a868",
"dependsOn": [
"ghcr.io/codspace/dependson/A",
"ghcr.io/codspace/dependson/E"
]
},
"ghcr.io/codspace/dependson/E": {
"version": "2.0.0",
"resolved": "ghcr.io/codspace/dependson/e@sha256:9f36f159c70f8bebff57f341904b030733adb17ef12a5d58d4b3d89b2a6c7d5a",
"integrity": "sha256:9f36f159c70f8bebff57f341904b030733adb17ef12a5d58d4b3d89b2a6c7d5a"
}
}
} Each entry in the lockfile's |
In this example, how would the lockfile pin a dependency at that is both (1) in the user's Say Given the following `devcontainer.json {
"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
"features": {
"ghcr.io/codspace/dependson/c": {},
"ghcr.io/codespace/dependson/e:3": {}
}
} That will result in the following dependency graph: flowchart
3992d6[ghcr.io/codspace/dependson/c]
aaaaaa[ghcr.io/codspace/dependson/e:3]
3992d6[ghcr.io/codspace/dependson/c] --> cbd9ef[ghcr.io/codspace/dependson/a]
cbd9ef[ghcr.io/codspace/dependson/a] --> 58daac[ghcr.io/codspace/dependson/e:2]
3992d6[ghcr.io/codspace/dependson/c] --> 58daac[ghcr.io/codspace/dependson/e:2]
I think we need to take the output of the dependency algorithm and write an entry for each Feature (perhaps deduping the ones that only vary by options). |
Agreed. The graph does not need to be captured, but the transitive set of all features that were installed (including multiple versions of the same feature if multiple were installed) need to be recorded in the lock file as a flat list. The proposed syntax in #236 (comment) doesn't work for this since you'd have a collision, but the syntax in #236 (comment) where the version is included in the key would work. |
I think we agree (my example wasn't good). The feature identifiers in the {
"features": {
"ghcr.io/codspace/dependson/a": {
"version": "1.2.1",
"resolved": "ghcr.io/codspace/dependson/a@sha256:...",
"integrity": "sha256:...",
"dependsOn": [
"ghcr.io/codspace/dependson/e:2"
]
},
"ghcr.io/codspace/dependson/c": {
"version": "2.0.1",
"resolved": "ghcr.io/codspace/dependson/c@sha256:...",
"integrity": "sha256:...",
"dependsOn": [
"ghcr.io/codspace/dependson/a",
"ghcr.io/codspace/dependson/e:2"
]
},
"ghcr.io/codspace/dependson/e:2": {
"version": "2.3.4",
"resolved": "ghcr.io/codspace/dependson/e@sha256:...",
"integrity": "sha256:..."
},
"ghcr.io/codspace/dependson/e:3": {
"version": "3.2.4",
"resolved": "ghcr.io/codspace/dependson/e@sha256:...",
"integrity": "sha256:..."
}
}
} E.g., |
I think the OCI identifier and the tarball URL are both case-insensitive. Since the casing can vary between |
Yes I know
Pada tanggal Kam, 20 Jul 2023 22.38, Christof Marti <
***@***.***> menulis:
… Closed #236 <#236> as
completed.
—
Reply to this email directly, view it on GitHub
<#236 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWMKQNRRJEO4V6WHGNIDV2DXRFGILANCNFSM6AAAAAAX3PJPDM>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Continuing from #101.
Default Behavior
Stated goals in the proposal: Reproduceablity, security, cachability.
The security goal is to protect the community from malicious code being injected after the lockfile has been written. For this the lockfile needs to be enabled by default.
The lockfile will prevent new bugs and new malicious code from propagating, but it will also prevent bug fixes and security updates from propagating. We could expand "disallowed features" to also support "deprecated/disapproved feature versions".
Supporting
dependsOn
Notes
NPM's
package-lock.json
and Yarn'syarn.lock
are similar in their approaches. Both support having multiple versions of the same package (at runtime each version can run separately). Notable difference:package-lock.json
v2 lays out thenode_modules
folder structure in the lockfile including checksums.package-lock.json
v1 refers to dependencies with"requires"
which resolves to a single version. If a different version is required an additional"dependencies"
object is added alongside the package's"requires"
property.yarn.lock
uses a list of references as the top-level keys, each package lists dependencies refering to these references. If a different version is required, an additional top-level entry is added.Conclusion
The current proposal can be used for features with dependencies. One limitation is that if two feature references are resolved with the same feature version, there will be two entries in the lockfile referring to the same version. E.g.:
The proposal could be updated to avoid the redundancy, but that is not strictly necessary because the lockfile is managed by the tooling.
The text was updated successfully, but these errors were encountered: