coding-conventions.chapter.md: update to account for #89885 #191378
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
This PR: #89885 ensures that fetches are done securely (i.e. without
--insecure
) when thehash
parameter is one of the four special "fake" hashes. However the manual was not updated in that PR. This commit updates the manual to account for the already-merged changes from that PR.ping @matthewbauer
Future-proofing
It would probably be a good idea if Nix didn't print out the complete unexpected hash of insecure fetches on the console, in order to deter people from copy-and-pasting it. For example, by default the error message printed to the console could deliberately garble a few characters in the middle of the hash by replacing them with an invalid character like
.
unless--option dammit-give-me-the-footgun
is set.The question is how to communicate to Nix that the fetch was insecure. I see two possibilities:
Nix adopts the nixpkgs convention that if expected-hash is
""
,lib.fakeHash
,lib.fakeSha256
, orlib.fakeSha512
then the unexpected-hash was computed over something which was fetched securely. This could be considered a layering violation.A new derivation attribute
__insecure
for FODs is added, which tells Nix that the fetch was performed insecurely. Since this would appear only on FODs it shouldn't affect any outpath addresses. It should probably also be allowed on__impure
derivations, and be inherited by FODs which depend on__insecure __impure
derivations.@edolstra if either of these approaches sounds acceptable to you I will implement it.
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes