flowchart TB
+
+ ci_cd_code[CI/CD as code]
+ git_repo[Git Repository]
+ inputs[Other inputs]
+ project[Project]
+
+ subgraph human[Interested Parties]
+ consumer[Consumer]
+ developer[Developer]
+ end
+
+ subgraph build[Hermetic and Reproducible Builds]
+ nix[Nix Package Manager]
+ nix_derivation[Nix Derivation SBOM]
+ nix_store_path[Nix Store Path - Built artifact]
+ nixpkgs_collection[Nixpkgs Collection]
+ nixpkgs_module_system[Module System]
+ end
+
+ subgraph makes[Makes]
+ makes_cli[Makes CLI]
+ makes_framework[Makes Framework]
+ end
+
+ subgraph slsa[Supply Chain Security]
+ slsa_provenance[SLSA Provenance Attestation]
+ end
+
+ consumer -- uses --> makes_cli
+ ci_cd_code -- uses --> makes_framework
+ ci_cd_code -- uses --> nixpkgs_collection
+ ci_cd_code -- uses --> inputs
+ developer -- uses --> makes_cli
+ developer -- maintains --> project
+ git_repo -- is fetched by --> makes_cli
+ git_repo -- contains --> ci_cd_code
+ makes_cli -- produces --> slsa_provenance
+ makes_cli -- uses --> nix
+ makes_framework -- uses --> nixpkgs_module_system
+ inputs -- is fetched by --> nix
+ nixpkgs_collection -- is fetched by --> nix
+ nixpkgs_module_system -- is fetched by --> nix
+ nix -- produces --> nix_derivation
+ nix -- produces --> nix_store_path
+ project -- has --> git_repoWe accept anything that benefits the community, +thanks for sharing your work with the world. +We can discuss implementation details here.
+Guidelines:
+/src/args/src/evaluator/modules/README.md or /docs/makes.nix or /makes/**/main.nix/.github/workflows/dev.ymlExamples:
+All of the code +that you submit to our code repository +will be licensed under the MIT license.
+Please add a Signed-off-by: Full Name <email> to your commits as explained here
+to signal that you agree
+to the terms of the following
+Developer Certificate of Origin.
Thank you!
+Once a pull request is opened in the repository, +a maintainer must follow the following steps +to review it:
+Decisions, approvals, code reviews, etc, +are made by the project maintainers:
+Discussions usually happen within the issues section.
+ + + + + + +A software supply chain framework powered by Nix.
+ + + + + + +A software supply chain framework powered by Nix.
"},{"location":"architecture/","title":"Architecture","text":"flowchart TB\n\n ci_cd_code[CI/CD as code]\n git_repo[Git Repository]\n inputs[Other inputs]\n project[Project]\n\n subgraph human[Interested Parties]\n consumer[Consumer]\n developer[Developer]\n end\n\n subgraph build[Hermetic and Reproducible Builds]\n nix[Nix Package Manager]\n nix_derivation[Nix Derivation SBOM]\n nix_store_path[Nix Store Path - Built artifact]\n nixpkgs_collection[Nixpkgs Collection]\n nixpkgs_module_system[Module System]\n end\n\n subgraph makes[Makes]\n makes_cli[Makes CLI]\n makes_framework[Makes Framework]\n end\n\n subgraph slsa[Supply Chain Security]\n slsa_provenance[SLSA Provenance Attestation]\n end\n\n consumer -- uses --> makes_cli\n ci_cd_code -- uses --> makes_framework\n ci_cd_code -- uses --> nixpkgs_collection\n ci_cd_code -- uses --> inputs\n developer -- uses --> makes_cli\n developer -- maintains --> project\n git_repo -- is fetched by --> makes_cli\n git_repo -- contains --> ci_cd_code\n makes_cli -- produces --> slsa_provenance\n makes_cli -- uses --> nix\n makes_framework -- uses --> nixpkgs_module_system\n inputs -- is fetched by --> nix\n nixpkgs_collection -- is fetched by --> nix\n nixpkgs_module_system -- is fetched by --> nix\n nix -- produces --> nix_derivation\n nix -- produces --> nix_store_path\n project -- has --> git_repoWe accept anything that benefits the community, thanks for sharing your work with the world. We can discuss implementation details here.
Guidelines:
/src/args/src/evaluator/modules/README.md or /docs/makes.nix or /makes/**/main.nix/.github/workflows/dev.ymlExamples:
All of the code that you submit to our code repository will be licensed under the MIT license.
Please add a Signed-off-by: Full Name <email> to your commits as explained here to signal that you agree to the terms of the following Developer Certificate of Origin.
Thank you!
"},{"location":"contributing/#review-process","title":"Review process","text":"Once a pull request is opened in the repository, a maintainer must follow the following steps to review it:
Decisions, approvals, code reviews, etc, are made by the project maintainers:
Discussions usually happen within the issues section.
"},{"location":"security/","title":"Security","text":"This section evaluates Makes using various standards and tries to address the security of Makes as an ecosystem using the three following categories:
This is what user can expect from Makes in terms of security, the notation is that of a Structured Assurance Case Model[^1].
The Makes CLI application is free of known security vulnerabilities.
The Python code of the Makes CLI application is free of known security vulnerabilities.
Proof:
You can check the SonarCloud pull requests list for Makes
You can check the pull requests history and see if the latest pull requests have a comment from SonarCloud. For example: PR 925, Comment 1256837172
Vulnerabilities count on SonarCloud is zero.
Proof:
The dependencies of the Makes CLI application are free of known security vulnerabilities.
Proof:
[^1]:
Rhodes, T. , Boland Jr., F. , Fong, E. and Kass, M. (2009), Software Assurance Using Structured Assurance Case Models, NIST Interagency/Internal Report (NISTIR), National Institute of Standards and Technology, Gaithersburg, MD, [online], https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=902688 (Accessed September 23, 2022)
"},{"location":"security/design-principles/","title":"Design Principles","text":""},{"location":"security/design-principles/#principle-of-least-privilege","title":"Principle of Least Privilege","text":"The Makes CLI is a python application that runs in user-space. The privileges required are:
Write access to the ${HOME}, which is normally owned by the user, so no extra privileges other than what the user already has are required.
${TMPDIR} environment variable, which is a functionality normally available to a user, so no extra privileges are required.(optional) privileges to create Kernel namespaces.
The Makes framework is simply a library that aids the developer in creating build scripts, so no privileges are required, the Makes framework is just source code that the user can opt-in to use.
When containers are built, they are build by assembling an OCI-compliant image (TAR files per each layer plus a JSON manifest), without resorting to privileged daemons like that of Docker. They are generated as any other build (hermetic, pure, etc) using information from the Nix Store.
The user is given the option to opt-out from this behavior, but this is enabled by default.
An user may opt-out from this behavior by setting environment variables, but user-owned folders are selected by default.
/nix/store are never published to the internet.A user may want to share artifacts with other users in order to improve performance by writing artifacts to a binary cache, so that other users can download the artifacts if they have already been built by other user, but this behavior requires configuring a read+write binary cache and setting the corresponding access secret.
A read-only binary cache (https://cache.nixos.org) and no write binary cache is the default configuration,
"},{"location":"security/design-principles/#principle-of-economy-of-mechanism","title":"Principle of Economy of Mechanism","text":"/nix/store and a personal installation of Nix. The /nix/store contents are not shared between users by default, unless the user configures a read+write binary cache and sets the corresponding binary cache secret.The SLSA framework helps organizations measure the level of assurance that the Software Artifacts they produce actually contain and use what they intended (integrity), by ensuring that the whole build and release process, and all of the involved sources and dependencies cannot be tampered with.
In this document, we use the version 0.1 of the specification.
Our current SLSA level is 2. The following is a detail of the levels achieved on each of the requirements:
Requirement Level Source - Version Controlled 4 Source - Verified History 4 Source - Retained Indefinitely 4 Source - Two Person Reviewed 3 Build - Scripted Build 4 Build - Build Service 4 Build - Build As Code 4 Build - Ephemeral Environment 4 Build - Isolated 2 Build - Parameter-less 4 Build - Hermetic 4 Build - Reproducible 4 Provenance - Available 4 Provenance - Authenticated 4 Provenance - Service Generated 4 Provenance - Non-Falsifiable 4 Provenance - Dependencies Complete 4 Common - Security 4 Common - Access 4 Common - Superusers 3For clarity, this is how SLSA definitions map into our infrastructure:
/proc, /dev, /dev/shm, and /dev/pts, and uses a private PID, mount, network, IPC, and UTS namespace to isolate itself from other processes in the system.Every change to the source is tracked on GitHub, using the Git version control system.
For example: PR 649.
Every change in the revision\u2019s history need to pass through a Pull Request.
In order to approve a Pull Request the reviewer need to be strongly authenticated into GitHub. The authentication process requires 2FA, and the dates of the change are recorded in the Pull Request.
Only users who were previously granted access by a platform Admin can review Pull Requests. External contributors can create a Pull Request without any special privileges, but it won't be merged until reviewers submit their approval.
For example: PR 649.
"},{"location":"security/slsa/#retained-indefinitely","title":"Retained indefinitely","text":"The revision and its change history are preserved indefinitely and cannot be deleted or modified (not even with multi-party approval). Additionally, the main branch is protected against accidental history overwrite using GitHub's branch protection rules.
At the moment, no legal requirement impedes us to preserve indefinitely our change history, and no obliteration policy is in effect. In fact, our source code is Free and Open Source Software: Anyone can download or fork the repository.
"},{"location":"security/slsa/#two-person-reviewed","title":"Two Person Reviewed","text":"Every change in the revision\u2019s history is agreed to by at least one trusted person prior to submission and each of these trusted persons are authenticated into the platform (using 2FA) first. Only project maintainers can merge Pull Requests and therefore append a change into the revision's history.
"},{"location":"security/slsa/#build-requirements","title":"Build Requirements","text":""},{"location":"security/slsa/#scripted-build","title":"Scripted Build","text":"All build steps were fully defined using GitHub Actions, Makes and Nix.
Manual commands are not necessary to invoke the build script. A new build is triggered automatically each time new changes are pushed to the repository.
For example:
All build steps run on GitHub Actions using GitHub hosted runners.
For example:
All build steps have been stored and versioned in the Git Repository.
For example:
According to the GitHub Actions documentation,
Additionally, the Nix package manager provides an ephemeral environment to each of the derivations. On Linux, the environment is a sandbox that Chroots into an empty temporary directory, provides private versions of /proc, /dev, /dev/shm, and /dev/pts, and uses a private PID, mount, network, IPC, and UTS namespace to isolate itself from other processes in the system.
Our build service ensures that the build steps run in an isolated environment free of influence from other build instances, whether prior or concurrent, by using containerization technologies.
Builds are executed using the Nix package manager, which prevents builds from accessing any external environment variables, network resources, sockets, or paths in the file system. and provides private versions of /proc, /dev, /dev/shm, and /dev/pts, and uses a private PID, mount, network, IPC, and UTS namespace to isolate the build from other builds happening concurrently in the system.
Input-addressed build caches are used to speed-up the pipeline.
"},{"location":"security/slsa/#parameter-less","title":"Parameter-less","text":"The build output cannot be affected by user parameters other than the build entry point and the top-level source location.
In order to modify the build output, a change to the source code must happen first.
"},{"location":"security/slsa/#hermetic","title":"Hermetic","text":"Builds are executed using the Nix package manager, which prevents builds from accessing any external environment variables, network resources, sockets, or paths in the file system.
All transitive build steps, sources, and dependencies are fully declared up front with immutable references.
For example:
The Nix package manager:
All of our build scripts are intended to be reproducible.
The reproducibility guarantees of our build scripts are that of the Nix package manager.
"},{"location":"security/slsa/#provenance-requirements","title":"Provenance Requirements","text":""},{"location":"security/slsa/#available","title":"Available","text":"Provenance is produced by Makes, and exposed by the build service as a JSON document together with the artifacts produced by the build.
Only builds that produce artifacts generate provenance, because if a build does not produce artifacts, then there wouldn't be something to verify the provenance of.
"},{"location":"security/slsa/#authenticated","title":"Authenticated","text":"The authenticity of the provenance comes from the fact that it can be downloaded from the build service itself, and therefore the authenticity claim is as strong as the Build and Source Requirements are secure.
The integrity of the provenance is displayed in the logs and generated by Makes.
"},{"location":"security/slsa/#service-generated","title":"Service Generated","text":"The data in the provenance is exposed by the build service, and is generated by Makes.
Regular users of the service are not able to inject or alter the contents because a build is fully determined and automated by its configuration, and the configuration comes directly from the source.
"},{"location":"security/slsa/#non-falsifiable","title":"Non-Falsifiable","text":"The provenance cannot be falsified by the build service's users:
The provenance contains all of dependencies that were available while running the build steps.
This is guaranteed by the fact that builds are hermetic (see Build - Hermetic). So for a build to succeed, all of its dependencies must be declared, and therefore the build tool (Makes and Nix) who fetched them at build time, have strong knowledge of their existence.
"},{"location":"security/slsa/#common-requirements","title":"Common Requirements","text":""},{"location":"security/slsa/#security","title":"Security","text":"Please read the Security page.
"},{"location":"security/slsa/#access","title":"Access","text":"Our build service (GitHub Actions) is SaaS, and we use GitHub hosted runners. Only some GitHub employees may have access to the runners. We cannot access the build service infrastructure physically nor remotely.
"},{"location":"security/slsa/#superusers","title":"Superusers","text":"Only a small number of platform admins may override the guarantees provided by SLSA. Particularly through disabling security options in the repository configuration page. Doing so does not currently require approval of a second platform admin.
"},{"location":"security/threat-model/","title":"Threat Model","text":""},{"location":"security/threat-model/#spoofing","title":"Spoofing","text":"Mitigation:
The installation command is given in plain-text, users can copy-paste it to avoid typos.
A user can mistype the target project to be built with Makes, and end-up building (and potentially running) a different (potentially malicious) project.
Mitigation:
$ m ., which is very unlikely to be mistyped.When referencing a project over the internet, the user is forced to use a git provider (github/gitlab), the owner account (which should be trusted by the user), the target repository, and a branch, commit or tag.
By using a commit, the user can force the integrity of the downloaded data to match what they expect.
Mitigation:
/nix as a read-only file system, and make the /nix/store only accessible by root and the nixbld group users, reducing an attack vector to the physical or local layer, which can be further protected by the use of frameworks like SLSA, and full disk encryption using LUKS.Mitigation:
/nix/store is individual per user, a user may write secrets to it, and then those secrets can be published to a binary cache that is publicly accessible.Examples of this include Nix idioms like:
[\n // Nix would load the secrets in plain-text to the `/nix/store`\n ./file-with-secrets-in-plain-text.txt\n\n // Nix would load the git repository to the `/nix/store`\n // This also applies to other builtins.fetch* that could\n // fetch private information\n (builtins.fetchGit {\n // Private repository (with potential intellectual property)\n url = \"git@github.com:company/secrets.git\";\n })\n]\nMitigation:
/nix/store is pushed to a binary cache by default. A user would need to configure the cache explicitly, and expose the corresponding secret in an environment variable./nix/store is mandatory. Please see https://cachix.org/ for more information.Makes has utilities for working with secrets in a way that they are only copied to the /nix/store in encrypted form, and then decrypted at runtime, where there are safe from disclosure.
For example: secretsForAwsFromEnv, secretsForAwsFromGitlab, secretsForEnvFromSops, secretsForGpgFromEnv, secretsForKubernetesConfigFromAws, and secretsForTerraformFromEnv.
However, we don't currently have a way to protect the user from using builtins.fetch*. If your workflow needs this, please avoid pushing artifacts to a public binary cache, or use a private binary cache instead.
Makes copies the contents of the git repository into a trusted control plane, and excludes all of the files that are not tracked by Git from this checkout. This means that if the file with secrets is inside the repository, but included in the .gitignore such that a git fetch of the given remote and revision would ignore it, Makes would not copy it into the trusted control plane, and therefore Nix wouldn't load it into the /nix/store.
This is what user can expect from Makes in terms of security, +the notation is that of a Structured Assurance Case Model[^1].
+The Makes CLI application is free of known security vulnerabilities.
+The Python code of the Makes CLI application + is free of known security vulnerabilities.
+Proof:
+You can check the + SonarCloud pull requests list for Makes
+You can check the + pull requests history + and see if the latest pull requests + have a comment + from SonarCloud. + For example: + PR 925, Comment 1256837172
+Vulnerabilities count on SonarCloud is zero.
+Proof:
+The dependencies of the Makes CLI application + are free of known security vulnerabilities.
+Proof:
+[^1]:
+Rhodes, T. , Boland Jr., F. , Fong, E. and Kass, M. (2009), +Software Assurance Using Structured Assurance Case Models, +NIST Interagency/Internal Report (NISTIR), +National Institute of Standards and Technology, +Gaithersburg, MD, [online], +https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=902688 +(Accessed September 23, 2022)
+ + + + + + +The Makes CLI is a python application that runs in user-space. + The privileges required are:
+Write access to the ${HOME},
+ which is normally owned by the user,
+ so no extra privileges
+ other than what the user already has are required.
${TMPDIR} environment variable,
+ which is a functionality normally available to a user,
+ so no extra privileges are required.(optional) privileges to create Kernel namespaces.
+The Makes framework is simply a library + that aids the developer in creating build scripts, + so no privileges are required, + the Makes framework is just source code + that the user can opt-in to use.
+When containers are built, + they are build by assembling an OCI-compliant image + (TAR files per each layer plus a JSON manifest), + without resorting to privileged daemons like that of Docker. + They are generated as any other build (hermetic, pure, etc) + using information from the Nix Store.
+The user is given the option to opt-out from this behavior, + but this is enabled by default.
+An user may opt-out from this behavior by setting environment variables, + but user-owned folders are selected by default.
+/nix/store
+ are never published to the internet.A user may want to share artifacts with other users + in order to improve performance + by writing artifacts to a binary cache, + so that other users can download the artifacts + if they have already been built by other user, + but this behavior + requires configuring a read+write binary cache + and setting the corresponding access secret.
+A read-only binary cache (https://cache.nixos.org) + and no write binary cache + is the default configuration,
+/nix/store
+ and a personal installation of Nix.
+ The /nix/store contents are not shared between users by default,
+ unless the user configures a read+write binary cache
+ and sets the corresponding binary cache secret.This section evaluates Makes using various standards +and tries to address the security of Makes as an ecosystem +using the three following categories:
+The SLSA framework +helps organizations measure +the level of assurance +that the Software Artifacts they produce +actually contain and use what they intended (integrity), +by ensuring that the whole build and release process, +and all of the involved sources and dependencies +cannot be tampered with.
+In this document, +we use the +version 0.1 of the specification.
+Our current SLSA level is 2. +The following is a detail of the levels achieved +on each of the requirements:
+| Requirement | +Level | +
|---|---|
| Source - Version Controlled | +4 | +
| Source - Verified History | +4 | +
| Source - Retained Indefinitely | +4 | +
| Source - Two Person Reviewed | +3 | +
| Build - Scripted Build | +4 | +
| Build - Build Service | +4 | +
| Build - Build As Code | +4 | +
| Build - Ephemeral Environment | +4 | +
| Build - Isolated | +2 | +
| Build - Parameter-less | +4 | +
| Build - Hermetic | +4 | +
| Build - Reproducible | +4 | +
| Provenance - Available | +4 | +
| Provenance - Authenticated | +4 | +
| Provenance - Service Generated | +4 | +
| Provenance - Non-Falsifiable | +4 | +
| Provenance - Dependencies Complete | +4 | +
| Common - Security | +4 | +
| Common - Access | +4 | +
| Common - Superusers | +3 | +
For clarity, +this is how SLSA definitions map into our infrastructure:
+/proc, /dev, /dev/shm, and /dev/pts,
+ and uses a private PID, mount, network, IPC, and UTS namespace
+ to isolate itself from other processes in the system.Every change to the source is tracked on GitHub, +using the Git version control system.
+For example: PR 649.
+Every change in the revision’s history +need to pass through a Pull Request.
+In order to approve a Pull Request +the reviewer need to be strongly authenticated into GitHub. +The authentication process requires 2FA, +and the dates of the change +are recorded in the Pull Request.
+Only users who were previously granted access +by a platform Admin can review Pull Requests. +External contributors can create a Pull Request +without any special privileges, +but it won't be merged +until reviewers submit their approval.
+For example: +PR 649.
+The revision and its change history +are preserved indefinitely +and cannot be deleted +or modified (not even with multi-party approval). +Additionally, +the main branch is protected +against accidental history overwrite +using GitHub's branch protection rules.
+At the moment, +no legal requirement +impedes us to preserve indefinitely our change history, +and no obliteration policy is in effect. +In fact, our source code is Free and Open Source Software: +Anyone can download or fork the repository.
+Every change in the revision’s history +is agreed to by at least one trusted person +prior to submission +and each of these trusted persons +are authenticated into the platform (using 2FA) first. +Only project maintainers can merge Pull Requests +and therefore append a change into the revision's history.
+All build steps were fully defined +using GitHub Actions, Makes and Nix.
+Manual commands are not necessary to invoke the build script. +A new build is triggered automatically +each time new changes are pushed to the repository.
+For example:
+ +All build steps run on GitHub Actions +using GitHub hosted runners.
+For example:
+All build steps have been stored and versioned +in the Git Repository.
+For example:
+ +According to the GitHub Actions documentation,
+Additionally,
+the Nix package manager
+provides an ephemeral environment to each of the derivations.
+On Linux,
+the environment is a sandbox
+that Chroots
+into an empty temporary directory,
+provides private versions
+of /proc, /dev, /dev/shm, and /dev/pts,
+and uses a private PID, mount, network, IPC, and UTS namespace
+to isolate itself from other processes in the system.
Our build service +ensures that the build steps +run in an isolated environment +free of influence from other build instances, +whether prior or concurrent, +by using containerization technologies.
+Builds are executed using the Nix package manager,
+which prevents builds
+from accessing any external environment variables,
+network resources, sockets,
+or paths in the file system.
+and provides private versions
+of /proc, /dev, /dev/shm, and /dev/pts,
+and uses a private PID, mount, network, IPC, and UTS namespace
+to isolate the build from other builds
+happening concurrently in the system.
Input-addressed build caches are used to speed-up the pipeline.
+The build output cannot be affected by user parameters +other than the build entry point +and the top-level source location.
+In order to modify the build output, +a change to the source code must happen first.
+Builds are executed using the Nix package manager, +which prevents builds +from accessing any external environment variables, +network resources, sockets, +or paths in the file system.
+All transitive build steps, sources, and dependencies +are fully declared up front with immutable references.
+For example:
+ +The Nix package manager:
+All of our build scripts are intended to be reproducible.
+The reproducibility guarantees of our build scripts +are that of the Nix package manager.
+Provenance is produced by Makes, +and exposed by the build service +as a JSON document +together with the artifacts produced by the build.
+Only builds that produce artifacts generate provenance, +because if a build does not produce artifacts, +then there wouldn't be something to verify the provenance of.
+The authenticity of the provenance +comes from the fact +that it can be downloaded +from the build service itself, +and therefore the authenticity claim +is as strong as the Build and Source Requirements are secure.
+The integrity of the provenance +is displayed in the logs +and generated by Makes.
+The data in the provenance +is exposed by the build service, +and is generated by Makes.
+Regular users of the service +are not able to inject +or alter the contents +because a build is fully determined +and automated by its configuration, +and the configuration comes directly from the source.
+The provenance +cannot be falsified by the build service's users:
+The provenance contains all of dependencies +that were available while running the build steps.
+This is guaranteed by the fact +that builds are hermetic +(see Build - Hermetic). +So for a build to succeed, +all of its dependencies must be declared, +and therefore the build tool (Makes and Nix) +who fetched them at build time, +have strong knowledge of their existence.
+Please read the Security page.
+Our build service (GitHub Actions) is SaaS, +and we use GitHub hosted runners. +Only some GitHub employees +may have access to the runners. +We cannot access the build service infrastructure +physically nor remotely.
+Only a small number of platform admins may override the guarantees provided by SLSA. +Particularly through disabling security options +in the repository configuration page. +Doing so does not currently require approval +of a second platform admin.
+ + + + + + + +Mitigation:
+The installation command is given in plain-text, + users can copy-paste it to avoid typos.
+A user can mistype the target project to be built with Makes, + and end-up building (and potentially running) + a different (potentially malicious) project.
+Mitigation:
+$ m .,
+ which is very unlikely to be mistyped.When referencing a project over the internet, + the user is forced to use a git provider (github/gitlab), + the owner account (which should be trusted by the user), + the target repository, + and a branch, commit or tag.
+By using a commit, +the user can force the integrity of the downloaded data +to match what they expect.
+Mitigation:
+/nix as a read-only file system,
+ and make the /nix/store only accessible by root
+ and the nixbld group users,
+ reducing an attack vector to the physical or local layer,
+ which can be further protected
+ by the use of frameworks like SLSA,
+ and full disk encryption using LUKS.Mitigation:
+/nix/store is individual per user,
+ a user may write secrets to it,
+ and then those secrets can be published to a binary cache
+ that is publicly accessible.Examples of this include Nix idioms like:
+[
+ // Nix would load the secrets in plain-text to the `/nix/store`
+ ./file-with-secrets-in-plain-text.txt
+
+ // Nix would load the git repository to the `/nix/store`
+ // This also applies to other builtins.fetch* that could
+ // fetch private information
+ (builtins.fetchGit {
+ // Private repository (with potential intellectual property)
+ url = "git@github.com:company/secrets.git";
+ })
+]
+Mitigation:
+/nix/store
+ is pushed to a binary cache by default.
+ A user would need to configure the cache explicitly,
+ and expose the corresponding secret
+ in an environment variable./nix/store is mandatory.
+ Please see https://cachix.org/ for more information.Makes has utilities for working with secrets in a way
+ that they are only copied to the /nix/store
+ in encrypted form,
+ and then decrypted at runtime,
+ where there are safe from disclosure.
For example:
+secretsForAwsFromEnv,
+secretsForAwsFromGitlab,
+secretsForEnvFromSops,
+secretsForGpgFromEnv,
+secretsForKubernetesConfigFromAws, and
+secretsForTerraformFromEnv.
However, we don't currently have a way to protect the user
+from using builtins.fetch*.
+If your workflow needs this,
+please avoid pushing artifacts to a public binary cache,
+or use a private binary cache instead.
Makes copies the contents of the git repository
+ into a trusted control plane,
+ and excludes all of the files
+ that are not tracked by Git
+ from this checkout.
+ This means that if the file with secrets is inside the repository,
+ but included in the .gitignore
+ such that a git fetch of the given remote and revision
+ would ignore it,
+ Makes would not copy it into the trusted control plane,
+ and therefore Nix wouldn't load it into the /nix/store.