Create a store path per in repo secret/var to be copied, this prevents
unused secrets from being leaked.
For example the `root-password` generator contains both the hashed and
unhashed password but only the hash is used.
Previously if a user started the app and the last opened clan directory does not exist anymore, it would still show the clan screen but without any machines.
This changes catches this case and throws the user back to the clan selection page
Since this project is an ever growing monorepo, having derivations depending on the whole repo leads to bad CI performance, as the cache is busted on every commit.
-> We never want any derivations depend on the whole repo
...except: the test that tests that nothing depends on the whole repo, which is added by this commit.
For now only add this check to packages to allow contributors to build it locally.
We might want to add it to the CI later once all occurrences are fixed.
Extends how we parse the contents of `SOPS_AGE_KEY` / `SOPS_AGE_KEY_FILE` / `keys.txt`, allowing a user to prepend a comment before any `AGE-PLUGIN-` secret key entry to indicate its corresponding public key.
For example:
```
AGE-PLUGIN-FIDO2-HMAC-xxxxxxxxxxxxx
```
The comment can use any prefix (e.g. `# public key: age1xxxx`, `# recipient: age1xxx`) as we are looking directly for `age1xxxx` within the line.
This change is necessary to support `age` plugins as there is no unified mechanism to recover the public key from a plugin's secret key.
If a plugin secret key does not have a preceding public key comment, an error will be thrown when attempting to set a secret.
This is a great refactor of the select functionality in the flake class.
This now uses the same parser as the nix code, but runs it in python for
nice stacktraces.
Also we now have a maybe selector which can be used by prepending the
selector with a ?
Tests have been expanded to make sure the code is more stable and easier
to understand
We cannot support dynamic hashInvalidation.
This means the invalidation can change *after* or *before* a 'vars generate'
But not during the generation itself. This causes heavy performance overhead.
Additionally this introduces a fixed-point-iteration (compare: fixed-point-iteration vs. fixed-point-function)
This iteration takes ~ 1min for two bare-bones machine with 1 generator (see: checks/data-mesher)
Invalidation doesn't need to be done after each generator is executed.
We cannot interpolate values from other generators into another
generator. The generators are executed in order. The finalScript of each
generator stays constant.
After the complete closure is generated the caller of generate may
decide to invalidate the flake cache