README examples seem too complex

[573]

First of, I really am very thankful this project exists and finally I can approach automated secrets provisioning in a step by step manner - reading all the valuable information here taught me a lot on the way.

Please allow me to give two proposals.

For someone starting hands-on but new in the field of secret provisioning, the README adds lot of cognitive overload to the table.

I.e., novelty load: Instead of immediately starting with an example .sops.yaml that adds multiple keys one should start with minimal viable example (I added one at the bottom here) - all the rest should go in a wiki, templates, an examples folder, a manual or in a section called Further research or something.

Also, when .sops.yaml is already not working one will not be able to read from the output nix-shell -p sops --run "sops secrets.yaml" will pose (most certainly it will not "start your configured editor"), what is possibly going wrong.

I.e., an example should not deem to avoid [...] add[ing] secrets.yml to the nix store when as correctly stated in the issue tracker

sops.defaultSopsFile = ./secrets.yaml;

defaultSopsFile must always be a relative path inside the git repository when using flakes unless your provide --impure (which you shouldn't really).

/run/secrets/... refers to the path that the secret will later be placed on.

Originally posted by @SuperSandro2000 in #733

That being a flakes design "flake" or not, at least the example should prominently mention that impurity tax as well. It is by now clear to me that reproducibility and secret privacy are not exactly proportional, but even more so this project should be as transparent about this as possible.

minimal working .sops.yaml - if that works - one can add complexity freely:

creation_rules:
    - age: age1***