Skip to content
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.

Sign up for GitHub

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

Polykey secrets env integration #289

Open
wants to merge 1 commit into
base: staging
Choose a base branch
from
Open

Polykey secrets env integration #289

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
2 changes: 1 addition & 1 deletion flake.nix
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -106,7 +106,7 @@
shellHook = ''
echo "Entering $(npm pkg get name)"
set -o allexport
. ./.env
. <(pk secrets env Polykey-CLI:.)
Copy link
Member

Choose a reason for hiding this comment

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

This should just be Polykey-CLI, no need for :..

Also again, this assumes we have a vault called Polykey-CLI, let's also make this command fail-safe, so that even if the vault doesn't exist, it can continue.

The usual way to do this is with || true when the command returns a non-zero exit code.

Also note that set -o allexport ensures that all variables declared afterwards is exported.

If the pk secrets env command produces exported variables, that isn't necessary anymore. This is why I wanted to ensure that sourcing doesn't do that by default.

The final thing is the lack of a vault schema making this very implicit, we are essentially injecting arbitrary global variables - whereas what we want is a schema defining what we expect to be in the vault. We have an issue for this too.

Also pk is an alias, the official program command should be polykey.

Another thing is that this assumes polykey exists in the development shell o r available in the CLI. I usually ensure that the program exists by adding it to nativeBuildInputs.

Would this be a problem for user-space Polykey?

Remember we have:

  1. System deployed Polykey - system configuration service
  2. User deployed Polykey - home manager service
  3. Project deployed Polykey?

A command running by itself without an agent - I wonder how that should work?

Copy link
Member

Choose a reason for hiding this comment

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

@tegefaulkes @aryanjassal I want to ensure that our secrets env is foolproof when we have this running...

And by bootstrapping PK from PK... need to examine all the potential problems.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'll create a new issue for discussing the spec of the secrets env command changes. There are things that need to be hashed out.

Copy link
Contributor

Choose a reason for hiding this comment

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

This should just be Polykey-CLI, no need for :..

This is being tracked in #312

set +o allexport
set -v
${lib.optionalString ci ''
Expand Down