Idea: Release the SecretManagement and SecretStore modules with PowerShell

[mgreenegit]

Summary of the new feature / enhancement

As a user, I have a consistent need to manage secure strings without exposing them in scripts and other automation artifacts. To rely on this capability in PowerShell, I need it to always be available without the need to add the installation to every new project, or finding workarounds to add it in the tools of my choice that run PowerShell.

Proposed technical implementation details (optional)

This experience would align with other modules that are released with the "default" installation footprint of PowerShell. There is no need to merge the source repo's or manage the projects as a single entity. When the PowerShell packages are built, the latest Microsoft.PowerShell.SecretManagement and Microsoft.PowerShell.SecretStore modules would be included.

[kilasuit]

Yes please

[fMichaleczek]

Agree

[Amir-Mir]

This would be great. Please do add these module with PS7.

[tristanbarcelon]

Would they be installed in the "built-in" Modules folder, e.g., %PROGRAMFILES%\PowerShell\7\Modules in Windows to avoid being uninstalled from the cmdlet?

[guidooliveira]

That would be super useful

[JustinGrote]

As long as there's still pursuit of breaking out all the subsystems and having a "slim" powershell option, I'm fine with a "batteries included" version that includes SecretManagement, it follows with the philosophies of .NET and the BCL.

[kilasuit]

@JustinGrote there is under this issue which is still in the consider bucket

[JustinGrote]

@JustinGrote there is under this issue which is still in the consider bucket

There's lots of subsystems (remoting, etc.) that can be stripped out too and is a work item, that's more what I want slim to be rather than a simple repackaging.

[LeonarddeR]

I'd really appreciate this!

[jaamarcelis]

Wow, great idea!

[halape]

Yes, please. That'd be really neat. Not to mention an extra push to migrate to PS7. :)

[cblackuk]

Absolutely yes!!! Then yes, after that yes, and then yes please :-) Maybe not in that order, but that would be an awesome addition. What a fantastic idea!

[namangoel19]

This will be awesome. This is general problem and having a separate package is pain.

[hongbiao1]

Awesome!!!

[jborean93]

I'm going to have to go against the curve here and say -1 (the following is a cleaned up version of my Twitter posts https://twitter.com/BoreanJordan/status/1550006497752788992)

This seems to be going against the general way of working in PowerShell where new contributions outside of the existing set of builtin cmdlets and engine details are being redirected to 3rd party modules and the PSGallery. One of the harder aspects of this is getting buy in to people willing to use modules and it seems like MS is coming across a similar problem with SecretManagement and SecretStore. To me it's a bit annoying that the pwsh team now is trying to just bypass these challenges by just bundling the modules with the default install making it even less likely to look at modules and the extras it provides.

If the problem is people are not allowed or don't know how to install modules the answer isn't to bundle it with pwsh but to figure out what those blockers are and come up with solutions to make it easier for pepole. You help make this less of a problem and it will result in more people willing to use modules rather than rely on what comes out of the box. This means more people will want to try and contribute code to pwsh itself rather than go their own way and result in a poorer ecosystem overall.

Another counterpoint is that when you bundle things then people become reliant on the version it came with. Now my code will need to continue to support older versions of these modules because of the bulk of the users will be relying on what comes in box and will never upgrade things. On the extreme end of the scale we saw this with Pester where WinPS shipped with v3. If these stay truly independent then the bulk of the users will more than likely follow along with the latest version out there. Pwsh will also be constrained with whatever version it can bundle as people will be expecting no breaking changes in minor releases which means either;

• SecretManagement will have long lived minor released 1.2.x will live on for the life of the pwsh release it was bundled with, or
• The version included in a pwsh release will stagnate and people will be stuck on that old version unless the next 7.x release of pwsh is out

In addition to that it might make the SecretManagement team less likely to take on larger or potentially breaking changes as they are now expected to be backwards compatible just like people expect pwsh 7.x to mostly be backwards compatible with 6 and earlier.

TLDR: If you want to encourage a vibrant ecosystem you need to be part of it and drive the adoption of things not in the box.