max/nix-super
1
0
Fork 0
mirror of https://github.com/privatevoid-net/nix-super.git synced 2024-11-25 07:16:17 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

Remove store object content address reproducibility section

Browse source
This commit is contained in:
John Ericson 2024-05-20 09:04:15 -04:00
parent 1c75af969a
commit 4c91bc543c
1 changed files with 0 additions and 28 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
doc/manual/src/store/store-object/content-address.md
View file

@ -90,34 +90,6 @@ Only SHA-1 is supported at this time.
If [SHA-256-based Git](https://git-scm.com/docs/hash-function-transition) If [SHA-256-based Git](https://git-scm.com/docs/hash-function-transition)
becomes more widespread, this restriction will be revisited. becomes more widespread, this restriction will be revisited.
### Reproducibility
The above system is more complex than it needs to be to support all types of file system objects and references, owing to accretion of features over time.
However, there's a lot of value in supporting old expressions and reproducing the same hashes with any version of Nix.
Still, the fundamental property remains that if one knows how a store object is supposed to be hashed
--- all the non-Hash, non-references information above
--- one can recompute a store object's store path just from that metadata and its content proper (its references and file system objects).
Collectively, we can call this information the "content address method".
By storing the "Content address method" extra information as part of store object
--- making it data not metadata
--- we achieve the key property of making content-addressed store objects *trustless*.
What this is means is that they are just plain old data, not containing any "claim" that could be false.
All this information is free to vary, and if any of it varies one gets (ignoring the possibility of hash collisions, as usual) a different store path.
Store paths referring to content-addressed store objects uniquely identify a store object, and given that object, one can recompute the store path.
Any content-addressed store object purporting to be the referee of a store object can be readily verified to see whether it in fact does without any extra information.
No other party claiming a store object corresponds to a store path need be trusted because this verification can be done instead.
Content addressing currently is used when adding data like source code to the store.
Such data are "basal inputs", not produced from any other derivation (to our knowledge).
Content addressing is thus the only way to address them of our two options.
([Input addressing](@docroot@/glossary.md#gloss-input-addressed-store-object), is only valid for store paths produced from derivations.)
Additionally, content addressing is also used for the outputs of certain sorts of derivations.
It is very nice to be able to uniformly content-address all data rather than rely on a mix of content addressing and input addressing.
This however, is in some cases still experimental, so in practice input addressing is still (as of 2022) widely used.
[fso-ca]: ../file-system-object/content-address.md [fso-ca]: ../file-system-object/content-address.md
[sp-spec]: @docroot@/protocols/store-path.md [sp-spec]: @docroot@/protocols/store-path.md
[xp-feature-git-hashing]: @docroot@/contributing/experimental-features.md#xp-feature-git-hashing [xp-feature-git-hashing]: @docroot@/contributing/experimental-features.md#xp-feature-git-hashing