Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .envrc
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
use nix
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
use nix
use nix
watch_file .envrc.private
if [[ -f .envrc.private ]]; then
source_env .envrc.private
fi

Copy link
Member

@Mic92 Mic92 Jun 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And in .envrc.private people than can do things like:

export GITHUB_TOKEN=$(rbw get gitlab.com-token)

or whatever they like to also add to their nixpkgs development workflow.

We would than add .envrc.private to .gitignore.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a bit more flexible than restricting the choice to dotenv, where one could only add hardcode static secrets.

Copy link
Member Author

@infinisil infinisil Jun 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main problem with this seems to be that it doesn't require the user to confirm it if the .envrc.private file changed, see direnv/direnv#348. Especially in Nixpkgs this considerably increases the attack surface, since we run so many update scripts, which could populate .envrc.private file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this different from changing shell.nix to add a shellHook or changing any code in nixpkgs?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess at least the shell.nix is being code owned by the security team, so if somebody does something sketchy they'd be notified. Can't do the same here. Ping @NixOS/security for input

Copy link
Member

@Mic92 Mic92 Jun 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not add .envrc.private than as well to the code owner list?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway. Not the hill, I want to die on.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not add .envrc.private than as well to the code owner list?

Unless I'm missing something, code owners only work when you commit the file to GitHub, which defeats the point of it :P

Anyways, I don't want to say No to this, just that I'm personally not sure about the security impact of it. So I'd say let's go with a more minimal solution without .private for now, which we can then still change in a backwards-compatible way later if necessary.

1 change: 1 addition & 0 deletions .github/CODEOWNERS
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@
# Develompent support
/.editorconfig @Mic92 @zowoq
/shell.nix @infinisil @NixOS/Security
/.envrc @infinisil @NixOS/Security

# Libraries
/lib @infinisil
Expand Down
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@ tags
/doc/manual.pdf
/source/
.version-suffix
.direnv

.DS_Store
.mypy_cache
Expand Down