From 6c05d98015a6f24499caed1235d985588712b2bd Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 28 May 2020 19:04:36 -0400 Subject: [PATCH 01/11] minimal-daemon: Copy template --- rfcs/0000-minimal-daemon.md | 58 +++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 rfcs/0000-minimal-daemon.md diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md new file mode 100644 index 000000000..43569cf57 --- /dev/null +++ b/rfcs/0000-minimal-daemon.md @@ -0,0 +1,58 @@ +--- +feature: (fill me in with a unique ident, my_awesome_feature) +start-date: (fill me in with today's date, YYYY-MM-DD) +author: (name of the main author) +co-authors: (find a buddy later to help out with the RFC) +shepherd-team: (names, to be nominated and accepted by RFC steering committee) +shepherd-leader: (name to be appointed by RFC steering committee) +related-issues: (will contain links to implementation PRs) +--- + +# Summary +[summary]: #summary + +One paragraph explanation of the feature. + +# Motivation +[motivation]: #motivation + +Why are we doing this? What use cases does it support? What is the expected +outcome? + +# Detailed design +[design]: #detailed-design + +This is the core, normative part of the RFC. Explain the design in enough +detail for somebody familiar with the ecosystem to understand, and implement. +This should get into specifics and corner-cases. Yet, this section should also +be terse, avoiding redundancy even at the cost of clarity. + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +This section illustrates the detailed design. This section should clarify all +confusion the reader has from the previous sections. It is especially important +to counterbalance the desired terseness of the detailed design; if you feel +your detailed design is rudely short, consider making this section longer +instead. + +# Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +# Alternatives +[alternatives]: #alternatives + +What other designs have been considered? What is the impact of not doing this? + +# Unresolved questions +[unresolved]: #unresolved-questions + +What parts of the design are still TBD or unknowns? + +# Future work +[future]: #future-work + +What future work, if any, would be implied or impacted by this feature +without being directly part of the work? From c41d80ad0027820cc7f69a97525f260f34e6020e Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 28 May 2020 22:51:36 -0400 Subject: [PATCH 02/11] minimal-daemon: First draft --- rfcs/0000-minimal-daemon.md | 49 ++++++++++++++++++++++--------------- 1 file changed, 29 insertions(+), 20 deletions(-) diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md index 43569cf57..776075dff 100644 --- a/rfcs/0000-minimal-daemon.md +++ b/rfcs/0000-minimal-daemon.md @@ -1,7 +1,7 @@ --- -feature: (fill me in with a unique ident, my_awesome_feature) -start-date: (fill me in with today's date, YYYY-MM-DD) -author: (name of the main author) +feature: minimal-daemon +start-date: 2020-5-28 +author: John Ericson co-authors: (find a buddy later to help out with the RFC) shepherd-team: (names, to be nominated and accepted by RFC steering committee) shepherd-leader: (name to be appointed by RFC steering committee) @@ -11,48 +11,57 @@ related-issues: (will contain links to implementation PRs) # Summary [summary]: #summary -One paragraph explanation of the feature. +`nix-daemon` should be a separate executable. # Motivation [motivation]: #motivation -Why are we doing this? What use cases does it support? What is the expected -outcome? +With flakes and other development, we are moving towards a more "batteries included" Nix command line. +We don't want any of those features in the daemon, however, because the daemon is a special trusted process that we should strive to be as simple as possible. +\[This is comparable to compilation pipeline, with a concise intermediate representation nicer user-facing features "desugar" into.\] + +There are many things we could do about this, but I mainly want to establish some rough consensus around the problem while taking a small step to signal that consensus. +Originally, each Nix command was its own executable, but then we combined them into one executable. +I think this is fine for the main user-facing + +\[This RFC is completely separate from the ongoing IPFS work.] # Detailed design [design]: #detailed-design -This is the core, normative part of the RFC. Explain the design in enough -detail for somebody familiar with the ecosystem to understand, and implement. -This should get into specifics and corner-cases. Yet, this section should also -be terse, avoiding redundancy even at the cost of clarity. +- `nix-daemon` will be a separate executable that only links the nix libraries it needs. + \[At this time, those libraries are `libnixutil`, `libnixutil`, and `libnixrust`, but this is subject to change.\] + +- `nix-daemon` should never need to understand the expression language and depend `libnixexpr`. # Examples and Interactions [examples-and-interactions]: #examples-and-interactions -This section illustrates the detailed design. This section should clarify all -confusion the reader has from the previous sections. It is especially important -to counterbalance the desired terseness of the detailed design; if you feel -your detailed design is rudely short, consider making this section longer -instead. +I certainly hope there are no interactions! +One of the bad things we should seek to prevent with this is the daemon unintentionally growing dependencies on more of the code base. # Drawbacks [drawbacks]: #drawbacks -Why should we *not* do this? +Not much. +Build rules perhaps are slightly more complex as there are both separate and independent executables. # Alternatives [alternatives]: #alternatives -What other designs have been considered? What is the impact of not doing this? + - Do nothing. + + - Something more invasive. + But I much rather save that for later. # Unresolved questions [unresolved]: #unresolved-questions -What parts of the design are still TBD or unknowns? +No known unknowns. # Future work [future]: #future-work -What future work, if any, would be implied or impacted by this feature -without being directly part of the work? +There's lots of future work we could do in the vain of modality. +But there's also different, conflicting directions we could go in. +The point of this small step is to punt on all that for now. From 90853b4c6802b945d5358fa95c8d35b0c7d867eb Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 29 May 2020 01:01:50 -0400 Subject: [PATCH 03/11] minimal-daemon: Typos --- rfcs/0000-minimal-daemon.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md index 776075dff..a2cf923a3 100644 --- a/rfcs/0000-minimal-daemon.md +++ b/rfcs/0000-minimal-daemon.md @@ -17,12 +17,12 @@ related-issues: (will contain links to implementation PRs) [motivation]: #motivation With flakes and other development, we are moving towards a more "batteries included" Nix command line. -We don't want any of those features in the daemon, however, because the daemon is a special trusted process that we should strive to be as simple as possible. -\[This is comparable to compilation pipeline, with a concise intermediate representation nicer user-facing features "desugar" into.\] +We don't want any of those features in the daemon, however, because the daemon is a special trusted process that we should strive to keep as simple as possible. +\[This is comparable to a compilation pipeline, with a concise intermediate representation nicer user-facing features "desugar" into.\] There are many things we could do about this, but I mainly want to establish some rough consensus around the problem while taking a small step to signal that consensus. Originally, each Nix command was its own executable, but then we combined them into one executable. -I think this is fine for the main user-facing +I think this is fine for the main user-facing commands, but not good for the daemon. \[This RFC is completely separate from the ongoing IPFS work.] From 6ebd13ec50f9da3aec3373cce3ad87c8186f3431 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 29 May 2020 01:03:12 -0400 Subject: [PATCH 04/11] minimal-daemon: Typo --- rfcs/0000-minimal-daemon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md index a2cf923a3..e0af921b1 100644 --- a/rfcs/0000-minimal-daemon.md +++ b/rfcs/0000-minimal-daemon.md @@ -62,6 +62,6 @@ No known unknowns. # Future work [future]: #future-work -There's lots of future work we could do in the vain of modality. +There's lots of future work we could do in the vain of modularity. But there's also different, conflicting directions we could go in. The point of this small step is to punt on all that for now. From fd23bd38c3cd5a0a188c3128648b1cd64c66dc01 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 29 May 2020 09:54:12 -0400 Subject: [PATCH 05/11] minimal-daemon: Fix Typos Co-authored-by: Cole Helbling --- rfcs/0000-minimal-daemon.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md index e0af921b1..c820b3681 100644 --- a/rfcs/0000-minimal-daemon.md +++ b/rfcs/0000-minimal-daemon.md @@ -18,7 +18,7 @@ related-issues: (will contain links to implementation PRs) With flakes and other development, we are moving towards a more "batteries included" Nix command line. We don't want any of those features in the daemon, however, because the daemon is a special trusted process that we should strive to keep as simple as possible. -\[This is comparable to a compilation pipeline, with a concise intermediate representation nicer user-facing features "desugar" into.\] +\[This is comparable to a compilation pipeline, with a concise intermediate representation that nicer user-facing features "desugar" into.\] There are many things we could do about this, but I mainly want to establish some rough consensus around the problem while taking a small step to signal that consensus. Originally, each Nix command was its own executable, but then we combined them into one executable. @@ -30,7 +30,7 @@ I think this is fine for the main user-facing commands, but not good for the dae [design]: #detailed-design - `nix-daemon` will be a separate executable that only links the nix libraries it needs. - \[At this time, those libraries are `libnixutil`, `libnixutil`, and `libnixrust`, but this is subject to change.\] + \[At this time, those libraries are `libnixutil`, `libnixstore`, and `libnixrust`, but this is subject to change.\] - `nix-daemon` should never need to understand the expression language and depend `libnixexpr`. @@ -62,6 +62,6 @@ No known unknowns. # Future work [future]: #future-work -There's lots of future work we could do in the vain of modularity. +There's lots of future work we could do in the vein of modularity. But there's also different, conflicting directions we could go in. The point of this small step is to punt on all that for now. From 3e718eabffc2b4a3a3bd4c5607f8239b492e026b Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 29 May 2020 10:35:15 -0400 Subject: [PATCH 06/11] minimal-daemon: Mention security --- rfcs/0000-minimal-daemon.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md index c820b3681..d8278a303 100644 --- a/rfcs/0000-minimal-daemon.md +++ b/rfcs/0000-minimal-daemon.md @@ -24,6 +24,10 @@ There are many things we could do about this, but I mainly want to establish som Originally, each Nix command was its own executable, but then we combined them into one executable. I think this is fine for the main user-facing commands, but not good for the daemon. +Finally, it's probably best not to give the daemon---a long lived process running with elevated privileges---access to tons of dead code. +C++ doesn't exactly prevent memory errors, and that dead code just more fodder to be used in some low-level attack. +There are other solutions to this in the long term, but this is the easiest solution in the short term. + \[This RFC is completely separate from the ongoing IPFS work.] # Detailed design From b80b61a3bb86fd7921840fd6ab830f841fb3302a Mon Sep 17 00:00:00 2001 From: John Ericson Date: Fri, 29 May 2020 18:24:40 -0400 Subject: [PATCH 07/11] Update rfcs/0000-minimal-daemon.md Co-authored-by: Cole Helbling --- rfcs/0000-minimal-daemon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md index d8278a303..2e1e72b95 100644 --- a/rfcs/0000-minimal-daemon.md +++ b/rfcs/0000-minimal-daemon.md @@ -25,7 +25,7 @@ Originally, each Nix command was its own executable, but then we combined them i I think this is fine for the main user-facing commands, but not good for the daemon. Finally, it's probably best not to give the daemon---a long lived process running with elevated privileges---access to tons of dead code. -C++ doesn't exactly prevent memory errors, and that dead code just more fodder to be used in some low-level attack. +C++ doesn't exactly prevent memory errors, and that dead code is just more fodder to be used in some low-level attack. There are other solutions to this in the long term, but this is the easiest solution in the short term. \[This RFC is completely separate from the ongoing IPFS work.] From 469085c0c023a786068d5501a62d03ed3735a05e Mon Sep 17 00:00:00 2001 From: John Ericson Date: Tue, 9 Jun 2020 00:18:16 -0400 Subject: [PATCH 08/11] Update rfcs/0000-minimal-daemon.md --- rfcs/0000-minimal-daemon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md index 2e1e72b95..f1c953240 100644 --- a/rfcs/0000-minimal-daemon.md +++ b/rfcs/0000-minimal-daemon.md @@ -47,7 +47,7 @@ One of the bad things we should seek to prevent with this is the daemon unintent # Drawbacks [drawbacks]: #drawbacks -Not much. +Installation is slightly bigger as the two binaries (`nix` and `nix-daemon`) have some redundancy. Build rules perhaps are slightly more complex as there are both separate and independent executables. # Alternatives From 33e50791671af0604843c03ce7be697102b78272 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Mon, 29 Jun 2020 13:41:14 -0400 Subject: [PATCH 09/11] minimal-daemon: Address of a few of @asymmetric's comments --- rfcs/0000-minimal-daemon.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md index f1c953240..f4cd6a4eb 100644 --- a/rfcs/0000-minimal-daemon.md +++ b/rfcs/0000-minimal-daemon.md @@ -25,11 +25,10 @@ Originally, each Nix command was its own executable, but then we combined them i I think this is fine for the main user-facing commands, but not good for the daemon. Finally, it's probably best not to give the daemon---a long lived process running with elevated privileges---access to tons of dead code. +All of the other commands entry points and library functions they use, such as the Nix evaluator, are in the same process even though the daemon should never need to use them. C++ doesn't exactly prevent memory errors, and that dead code is just more fodder to be used in some low-level attack. There are other solutions to this in the long term, but this is the easiest solution in the short term. -\[This RFC is completely separate from the ongoing IPFS work.] - # Detailed design [design]: #detailed-design @@ -55,8 +54,8 @@ Build rules perhaps are slightly more complex as there are both separate and ind - Do nothing. - - Something more invasive. - But I much rather save that for later. + - Something more invasive, such as packaging the libraries and commands separately, or intending the libaries for widespread public consumption. + But I much rather save that for later, as such steps would be far more controversial. # Unresolved questions [unresolved]: #unresolved-questions @@ -66,6 +65,6 @@ No known unknowns. # Future work [future]: #future-work -There's lots of future work we could do in the vein of modularity. -But there's also different, conflicting directions we could go in. +I think most people for this will have future plans they wish to persue in the name of modularity. +But I don't expect everyone to agree on waht exactl those plans should be. The point of this small step is to punt on all that for now. From 465c4d308e710c84b53abb15895635b0a17c1474 Mon Sep 17 00:00:00 2001 From: Linus Heckemann Date: Thu, 27 Aug 2020 15:15:05 +0200 Subject: [PATCH 10/11] Add shepherd team metadata --- rfcs/0000-minimal-daemon.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md index f4cd6a4eb..86da70287 100644 --- a/rfcs/0000-minimal-daemon.md +++ b/rfcs/0000-minimal-daemon.md @@ -3,8 +3,8 @@ feature: minimal-daemon start-date: 2020-5-28 author: John Ericson co-authors: (find a buddy later to help out with the RFC) -shepherd-team: (names, to be nominated and accepted by RFC steering committee) -shepherd-leader: (name to be appointed by RFC steering committee) +shepherd-team: Eelco Dolstra, Théophane Hufschmitt, Finn Behrens +shepherd-leader: Eelco Dolstra related-issues: (will contain links to implementation PRs) --- From d033cb289a9446f3d480a7c5c755249de46b4612 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Sat, 5 Dec 2020 22:48:24 -0500 Subject: [PATCH 11/11] Update rfcs/0000-minimal-daemon.md Co-authored-by: Jonathan Ringer --- rfcs/0000-minimal-daemon.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0000-minimal-daemon.md b/rfcs/0000-minimal-daemon.md index 86da70287..96beddade 100644 --- a/rfcs/0000-minimal-daemon.md +++ b/rfcs/0000-minimal-daemon.md @@ -66,5 +66,5 @@ No known unknowns. [future]: #future-work I think most people for this will have future plans they wish to persue in the name of modularity. -But I don't expect everyone to agree on waht exactl those plans should be. +But I don't expect everyone to agree on what exactly those plans should be. The point of this small step is to punt on all that for now.