feat: pk secrets env command

[CMCDragonkai]

Description

This introduces a prototype pk secrets env command to inject secrets into a command.

Right now we're going to do something simple as the kexec library is not ready (MatrixAI/Polykey-CLI#31), and plus we would probably need to make it ourselves to ensure cross platform behaviour.

For demo purposes (#504) it's sufficient to just do a subprocess.

Some differences from #265...

Instead of doing vault:secretpath:name we can do name=vault:secretpath.

This makes it closer to the behaviour of the env command.

We can add in flag -i|--ignore-environment and -C|--chdir like the env command too. Not sure if this fits our flag styles, since we would normally do -ie and -cd.

Issues Fixed

• Fixes The pk secrets env command for meeting Development Environment Usecase Polykey-CLI#31
• Supersedes Secret env command #265

Tasks

• 1. All tasks from The pk secrets env command for meeting Development Environment Usecase Polykey-CLI#31

Final checklist

• Domain specific tests
• Full tests
• Updated inline-comment documentation
• Lint fixed
• Squash and rebased
• Sanity check the final build

[ghost]

👇 Click on the image for a new way to code review

• Make big changes easier — review code in small groups of related files

• Know where to start — see the whole change at a glance

• Take a code tour — explore the change with an interactive tour

• Make comments and review — all fully sync’ed with github

  Try it now!

Legend

[CMCDragonkai]

I was looking at the parseSecretPath utility as this was used to parse <vaultName>:<secretPath> parameters.

The regex used here doesn't seem to be well thought out.

I traced what actually is the limitation of secretPath, anyway this is just a string that is passed to EFS.

EFS has no limitations with the string.

It does some things like:

• Coalescing consecutive slashes into 1 slash
• Trailing slash is considered to refer to a directory and is replaced with /. at the very end

But that's it, so that means the EFS strings are more flexible than even Linux FS path strings since they only restrict null characters (technically we could even have null characters).

However in our PK usecase allowing such arbitrary strings are a bad idea. The reason is when we are loading such files back on to the OS's FS, we will eventually hit problems with converting to to OS FS paths.

So it's better to focus on the lowest common denominator with respect to secretPath strings.

This means we combine the limitations of linux paths, windows paths and darwin paths together and create a regex in turn to match those kinds of paths.

Then the parseSecretPath should be changed to parseSecretAddress.

In the future this could be made closer to URI. In fact it makes more sense to just think of the vault name as just another component path. That is vaultName/secret/path. This is because the vault name itself is just a name of the directory in our root EFS.

But we should still call it parseSecretAddress otherwise we lose a distinction here with the remainder path.

So even the vault name itself is subject to the same requirements, however I think the vault name may have other limitations. I forgot if there was some reason we had to use a specialised vault ID, or if the vault name is just a string we put into the DB.

Thoughts @tegefaulkes?

[CMCDragonkai]

Here's a comparison of all the limitations: https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations.

If we keep it simple right now, this allows us [a-zA-Z0-9\/@$! #%\-_=+^&();,.{}\[\]']+.

So we can then change our regex to capture the first vault name group with the above, then everything subsequently afterwards.

[tegefaulkes]

I've been thinking of the vault path like it's a scp remote path. having the format vaultname:some/secret/path gives a clear distinction between local files and vault files. If we run with this semantic we can even have a generic copy command that can move a secret around.

• local fs -> vault : secrets cp local/path vault1:vault/path
• vault -> local fs : secrets cp vault1:vault/path local/path
• vault -> vault : secrets cp vault1:vault/path vault2:vault/path

You could even go crazy and reference secrets in a remote vault vault@nodeId:some/path but that seems doesn't really make sense.

[CMCDragonkai]

This can no longer be implemented here, it would need to be done as part of Polykey-CLI. Closing this PR, but the issue MatrixAI/Polykey-CLI#31 is still relevant.