fix:read spaces in secretPath

[shafiqihtsham]

Description

When creating a secret, secretPaths should be able to handle spaces and not throw an error.

Issues Fixed

• Fixes Support spaces in secret paths #199
• REF ENG-335

Tasks

• 1. Support spaces within secret paths.
• 2. Added tests testing this functionality.

Final checklist

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

[CMCDragonkai]

Why was this closed @shafiqihtsham

[shafiqihtsham]

I closed this PR because I was confused on the exact requirements the issue was asking for specifically what characters we should allow on the paths. Also I wasn't too sure if someone else was going to work on this as I didn't formally ask to be assigned to it.

I can reopen and work on it again as well as implement the needed fast check test, but I need help understanding what you meant by "least common characters" as to my understanding Unix only forbids / in paths where for Windows its
< > : " / \ | ? * . @CMCDragonkai

[CMCDragonkai]

LCD - lowest common denominator I think I was referencing that. "least" is not the right word here.

How about the "common set of characters" between all 3 operating systems allowed in a file path/name.

[CMCDragonkai]

But one has to fast check this, and also deal with "ingress" - which is relevant to #32.

[tegefaulkes]

I'm going to re-open this. I don't want it to get lost in the issue tracker.

[tegefaulkes]

Two things to address still

1. Make sure the regex matches the unix defined path format.
2. Add a fast check test for the parser along with a fast check test for end to end creating and getting secrets with a generated secret name.

[tegefaulkes]

Looking into it, it seems that unix file names are very permissive. They allow everything except null and /. I did some testing and found that isometric-git is a bit indiscriminate between / and \ so we can't allow either of these as part of the file name.

So I'm changing the allowable file path to be ([^\0\\]+) and I'm adding a fast-check test for testing it. The test is end to end create and read a secret with a generated secret path. It's slow so I'm limiting the runs to 5.

[tegefaulkes]

Oh, this PR is forked off of Polykey-cli I'm going to make a new branch to address this.

[tegefaulkes]

Superseded by #217