Add trust-tarballs-from-git-forges setting #10340
Conversation
github-actions
bot
added
the
fetching
| If disabled, GitHub flakes are only considered locked if a | ||
| `narHash` attribute is specified, | ||
| e.g. `github:NixOS/patchelf/7c2f768bf9601268a4e71c2ebe91e2011918a70f?narHash=sha256-PPXqKY2hJng4DBVE0I4xshv/vGLUskL7jl53roB8UdU%3D`. | ||
| )"}; |
There was a problem hiding this comment.
This should be marked experimental (under fetch-tree perhaps?); I don't want to need to have it long term.
There was a problem hiding this comment.
I don't think it should be experimental. It could be removed (made a no-op) in the future if it's no longer needed.
After all, what's the experimental behaviour? The "true" or "false" case?
There was a problem hiding this comment.
I wasn't there for the rest of the call Monday, but I consider this thing mostly a monkey patch because the other stuff for the fetchers hasn't been done yet.
In the end I think:
-
When there are no submodules, everything should be trustlesss and ergonomic with a single hash. We record all the Merkle proofs we need.
-
When there are submodules, the user should explicitly opt into fetching them or pruning them. And git vs github hardly matters because the real issue is not some service lying, but the fetched thing not corresponding to the hash used to fetch it with.
There was a problem hiding this comment.
Why wouldn't it be experimental? It only makes sense as part of fetchTree anyways, right?
There was a problem hiding this comment.
It's already implicitly behind fetch-tree. But we have a bunch of settings (access-tokens, allow-dirty, warn-dirty, ...) that are also fetcher-specific but not marked as experimental.
|
|
||
| If disabled, GitHub trees are only considered locked if a | ||
| `narHash` attribute is specified, | ||
| e.g. `github:NixOS/patchelf/7c2f768bf9601268a4e71c2ebe91e2011918a70f?narHash=sha256-PPXqKY2hJng4DBVE0I4xshv/vGLUskL7jl53roB8UdU%3D`. |
There was a problem hiding this comment.
| e.g. `github:NixOS/patchelf/7c2f768bf9601268a4e71c2ebe91e2011918a70f?narHash=sha256-PPXqKY2hJng4DBVE0I4xshv/vGLUskL7jl53roB8UdU%3D`. | |
| e.g. `github:NixOS/patchelf/7c2f768bf9601268a4e71c2ebe91e2011918a70f?narHash=sha256-PPXqKY2hJng4DBVE0I4xshv/vGLUskL7jl53roB8UdU%3D`. | |
| This `narHash` is not guaranteed to be required in future versions. |
Not a promise, which we should be careful about, especially in reference docs, but some expectation management is in order.
There was a problem hiding this comment.
I don't think we have to document that requirements could be loosened in the future, since that wouldn't break anything.
|
What makes github so special here? |
|
@Ma27 This setting does apply to all the GitHub-like fetchers, but I couldn't think of a better name for it. |
"Forge" would be the term. |
If enabled, GitHub flakerefs don't require a content hash, a Git revision is enough. Fixes NixOS#10297.
edolstra
changed the title
Ehh, should've taken a closer look I guess 😅 I'm wondering though if it'd make sense to restrict the trust to a configurable list of hosts in the future though, e.g. just the org's GitLab. Just a suggestion though, doesn't necessarily need to be part of this PR I think. |
roberth
added
the
backport 2.21-maintenance
|
Successfully created backport PR for |
Motivation
If enabled, GitHub flakerefs don't require a content hash, a Git revision is enough.
Fixes #10297.
Context
Priorities and Process
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.