New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trustless remote building for input-addressed drvs #3921
Trustless remote building for input-addressed drvs #3921
Conversation
b5f5779
to
6fa196c
Compare
aa6e71b
to
46bb107
Compare
Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
46bb107
to
cbc4344
Compare
c91c7d1
to
9dd28a6
Compare
Whether it fails or not, it is no a new test so we have to leave it.
…nsystems/nix into trustless-remote-builder-simple
src/nix-daemon/nix-daemon.cc
Outdated
@@ -278,14 +279,26 @@ static int _main(int argc, char * * argv) | |||
printVersion("nix-daemon"); | |||
else if (*arg == "--stdio") | |||
stdio = true; | |||
else return false; | |||
else if (*arg == "--trust") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this flag do? What are we trusting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stdin
. When we have a Unix domain socket we can do getPeerInfo
, but we can't do that with stdin so currently we just always trust stdin
(that is, if we aren't just proxying stdin another daemon, as is the common case with ssh-ng
).
This provides a way to not trust stdin, which is useful for testing. I could make these flag --trust-stdin
/ --no-trust-stdin
for clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have generalized the flag so it also works in the Unix domain socket case; it forces the trust one way or the other instead of checking the user viaauthPeer
.
src/build-remote/build-remote.cc
Outdated
// If we don't know whether we are trusted (e.g. `ssh://` | ||
// stores), we assume we are. This is neccessary for backwards | ||
// compat. | ||
if (std::optional trust = sshStore->isTrustedClient(); (!trust || *trust) || drv.type().isCA()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
C.f. The huuuuuge comment by me in wopBuildDerivation
in src/libstore/daemon.cc
. All of this follows from that pretty simply.
And only enable in the tests that need it. This makes it less of a sledgehammer.
We finally test the status quo of remote build trust in a number of ways. We create a new experimental feature on `nix-daemon` to do so. PR NixOS#3921, which improves the situation with trustless remote building, will build upon these changes. This code / tests was pull out of there to make this, so everything is easier to review, and in particular we test before and after so the new behavior in that PR is readily apparent from the testsuite diff alone.
Making this draft not because it is not ready, but because I pulled out #8230 as preparatory PR we should merge first for better reviewing. |
We finally test the status quo of remote build trust in a number of ways. We create a new experimental feature on `nix-daemon` to do so. PR NixOS#3921, which improves the situation with trustless remote building, will build upon these changes. This code / tests was pull out of there to make this, so everything is easier to review, and in particular we test before and after so the new behavior in that PR is readily apparent from the testsuite diff alone.
It handles failures more correctly; I am glad we have it now!
695befa
to
ab5ca60
Compare
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-04-17-nix-team-meeting-minutes-49/27379/1 |
OK, this is now quite small and easy to review! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed in Nix team meeting.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
🎉 🎉 🎉 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-05-08-nix-team-meeting-minutes-53/27967/1 |
Motivation
Fixes #2789.
Input-addressed outputs cannot be safely pushed to a remote builder without trusting the client. This makes trustless remote building without experimental features completely useless in practice. Making them work is widely requested.
The solution is simple: when not trusted, instead of using
buildDerivation
(which sends a mereBasicDerivation
and requires trust, usebuildPaths
and send the entireDerivation
and its closure).Context
Known failure mode
We still cannot copy input-addressed paths to a remote builder safely. In that case, this still fails (see the should-fail test). The manual work around is to tell the remote builder to build that path first, so it already has it. This can be done with
nix-build --store <them> --eval-store <us>
.That is manual and tedious, but in may real world cases can be avoided in practice. (e.g. when remote builders are always used, and the remote builders trust one another, this won't arise.)
Seems good enough to start with.
Depends on #8230for testing with untrusted remote store.Depends on #7515for knowing whether the remote store trusts usChecklist for maintainers
Maintainers: tick if completed or explain if not relevant
tests/**.sh
src/*/tests
tests/nixos/*
Priorities
Add 👍 to pull requests you find important.