mirror of https://github.com/privatevoid-net/nix-super.git synced 2024-11-15 10:46:15 +02:00

John Ericson eb7d7780b1 Rename doc/manual{src -> source}

This is needed to avoid this
https://github.com/mesonbuild/meson/issues/13774 when we go back to
making our subproject directory `src`.

2024-10-14 11:21:24 -04:00

4.3 KiB

Raw Blame History

Content-Addressing Store Objects

Just like File System Objects, Store Objects can also be content-addressed, unless they are input-addressed.

For store objects, the content address we produce will take the form of a Store Path rather than regular hash. In particular, the content-addressing scheme will ensure that the digest of the store path is solely computed from the

file system object graph (the root one and its children, if it has any)
references
store directory
name

of the store object, and not any other information, which would not be an intrinsic property of that store object.

For the full specification of the algorithms involved, see the specification of store path digests.

Content addressing each part of a store object

File System Objects

With all currently supported store object content addressing methods, the file system object is always content-addressed first, and then that hash is incorporated into content address computation for the store object.

References

With all currently supported store object content addressing methods, other objects are referred to by their regular (string-encoded-) store paths.

Self-references however cannot be referred to by their path, because we are in the midst of describing how to compute that path!

The alternative would require finding as hash function fixed point, i.e. the solution to an equation in the form
digest = hash(..... || digest || ....)
which is computationally infeasible. As far as we know, this is equivalent to finding a hash collision.

Instead we just have a "has self reference" boolean, which will end up affecting the digest.

Name and Store Directory

These two items affect the digest in a way that is standard for store path digest computations and not specific to content-addressing. Consult the specification of store path digests for further details.

Content addressing Methods

For historical reasons, we don't support all features in all combinations. Each currently supported method of content addressing chooses a single method of file system object hashing, and may offer some restrictions on references. The names and store directories are unrestricted however.

Flat

This uses the corresponding Flat method of file system object content addressing.

References are not supported: store objects with flat hashing and references can not be created.

Text

This also uses the corresponding Flat method of file system object content addressing.

References to other store objects are supported, but self references are not.

This is the only store-object content-addressing method that is not named identically with a corresponding file system object method. It is somewhat obscure, mainly used for "drv files" (derivations serialized as store objects in their "ATerm" file format). Prefer another method if possible.

Nix Archive

This uses the corresponding Nix Archive method of file system object content addressing.

References (to other store objects and self references alike) are supported so long as the hash algorithm is SHA-256, but not (neither kind) otherwise.

Git

Warning

This method is part of the git-hashing experimental feature.

This uses the corresponding Git method of file system object content addressing.

References are not supported.

Only SHA-1 is supported at this time. If SHA-256-based Git becomes more widespread, this restriction will be revisited.

4.3 KiB Raw Blame History