GeezerVison

Somewhere in here powershell.config.json should have a JSON Schema... though.. since JSON schema is still in draft... I'm torn on whether to fight for that or not.

https://tools.ietf.org/html/draft-handrews-json-schema-00

Actually the RFC describe the schema implicitly.
Current API implementation uses string typed approach - we can secure without strong scheme check.
So we'd need the scheme explicitly only if we'd introduce configuration cmdlets like Test-PSConfig, Get-PSConfig, Set-PSConfig.

Ilya (@iSazonov) that's not what I meant... I meant that the JSON file should have a publicly available schema. The JSON Schema defines all the object properties, their acceptable types, etc. This schema can then be linked in the powershell.config.json with the $schema property. Then in editors like VSCode you can have auto completion and selections available. This schema would require updating when new settings are made available in powershell.config.json.

More info http://json-schema.org

Steve Lee (@SteveL-MSFT) Time is over. Could we continue?

Removing Review - Committee as there's additional comments now

Ilya (@iSazonov) Can you update this for how -settingfile should work. I'm not sure how it works currently fits in properly with this spec.

Travis Plunk (@TravisEz13) I added a comment about -settingfile.

I find it a bit inconsistent that this config file is using JSON while other PowerShell config files like module manifests use .psd1. Why choose JSON here?
And if JSON is chosen, I find it weird that properties are PascalCase. I realise that is the convention for PowerShell code and C#, but JSON is JavaScript Object Notation, and the convention is camelCase.

Felix Becker (@felixfbecker) I think JSON was chosen for the file to be portable outside of PowerShell. JSON has very strong and widespread tooling and if your configuration is broken and you can't start PowerShell, a PSD1 parser will be harder to come by. In the time since PowerShell modules were conceived, JSON has risen to dominance as a widespread, simple, well-supported and relatively safe way to encode this kind of simple structured data.

On the convention note, JSON doesn't seem to have an agreed convention and PascalCase allows a lower representational gap between the JSON file and the internal classes/settings it represents.

Travis Plunk (@TravisEz13) Dongbo Wang (@daxian-dbw) What security setting can be in the config that we need to worry about? Or for simplicity, we should consider all settings as security?

I suggest the algorithm:

• at startup
  • PowerShell Core has explicit defaults for all config settings (secure by default that allow avoid the need to crash at startup)
  • PowerShell Core tries to read the config and get settings
  • if any error then keep "current settings" that is defaults at the time and logging a warning (The logging will allow us to get feedback if users see something strange in the logs.).
• at runtime
  • PowerShell Core tries to read the config async every n-minutes (5?) (Windows applies GPO every 90 minutes by default and we could implement a callback but seems . )
  • if any error then keep "current settings" and logging a warning

I suggest open the config with options "For Read" and "Share.ReadWrite". Latest allow us avoid a trouble (keeping current settings) if file already locked by another process for write long time. The above algorithm allows us to do it safely because no need to crash.

Another thing that might be worth addressing in this is path handling in the config file. Since JSON is a static asset, writing a redistributable config file that works on all platforms is not possible if all paths are taken as literal.

Should PowerShell do any kind of handling for paths here? And what about environment or automatic variables?

I can imagine a desire for something like:

{
    "PSModulePath": "${env:windir}\\System32\\WindowsPowerShell\\v1.0\\Modules"
}

I can also imagine wanting to write something like:

{
    "PSModulePath": "$HOME/PowerShell/Modules<sep>$PSHOME/Modules"
}

and have it work on Windows, Linux and macOS with <sep> being the right path separator, $HOME and $PSHOME resolving properly, and the / in the paths working on Windows.

Finally, another question is, should we handle relative paths at all? Possibly as relative to the config file itself?

Ilya (@iSazonov) Secure by default is difficult to achieve. We would have to generate a unique encryption key and setup protected event logging. We would need to store that configuration somewhere. What happens if we cannot store that? How do we know if we have already setup a default? Using a hardcoded default would be insecure. How do we secure the key we generate?

Using a hardcoded default would be insecure. How do we secure the key we generate?

Travis Plunk (@TravisEz13) Under "secure by default" I meant that we hardcode the secure defaults internally in code.

not possible if all paths are taken as literal.

Rob Holt (@rjmholt) We can process literal paths in PowerShell (LiteralPath parameter). I don't see problems.
As for env variables and relative paths I don't know.

We can process literal paths in PowerShell (LiteralPath parameter).

By "literal" I mean, interpreting the path verbatim as .NET would, rather then resolving it in PowerShell. As far as I know, we currently just pass the paths straight to .NET APIs, but to get a cross-platform config we'd want to do /-\ conversion etc etc.

And thinking on it more, it might be worth having a short whitelist of variables like $HOME and $PSHOME that we guarantee usage of.

we currently just pass the paths straight to .NET APIs, but to get a cross-platform config we'd want to do /-\ conversion etc etc.

Currently .Net Core does the normalization on Windows. Sample https://source.dot.net/#System.Private.CoreLib/shared/System/IO/Path.Windows.cs,220

Currently .Net Core does the normalization on Windows. Sample https://source.dot.net/#System.Private.CoreLib/shared/System/IO/Path.Windows.cs,220

Absolutely, but in PowerShellEditorServices I've seen bugs where a \ in *nix isn't treated like a path separator. That's all I mean there.

Hey Ilya (@iSazonov), we would love to take a hard look at an updated version of this. Would you mind giving it a read to make sure it makes sense with what's happened in the last year, as well as to fix the broken table you have near the beginning? Thanks!

Joey Aiello (@joeyaiello) Table was fixed. I added new section about defaults. I set out my vision. Your team can make changes to speed up the work if necessary.

Ilya (@iSazonov) is any of this one still relevant now that RFC0041 has been merged? If so, can you scope it to those changes? If not, can you close this PR?

Sorry, I know we've dragged our feet on this one, but I'm fairly certain a lot of this thinking served as the basis for RFC0041. Thanks for going through this exercise to help guide that one.

Joey Aiello (@joeyaiello) Please look this https://github.com/PowerShell/PowerShell-RFC/blob/master/4-Experimental-Accepted/RFC0041-Policy.md#acknowledgement
I am not sure that I understand that is "a slightly different purpose" of the RFC0041 and that was rejected in the PR but this says that RFC0041 does not cover all from the PR.

I'm not sure the underlying motivation of the PR matters so much as the implementation as it exists.

Is there an aspect of this RFC that you'd still like to offer forward that wasn't in RFC0041?

Joey Aiello (@joeyaiello) After reviewing RFC0041 and the PR I find 2 gaps:

1. GPP (group policy preferences). I think it is important for Enterprises. But this was rejected by MSFT team so I leave this to your team.
2. Issue Some cmdlets and config require writing to $PSHOME\SessionConfig folder PowerShell#9278 should be addressed in new RFC and code