Category Archives: Powershell

SecretManagement preview 6 and SecretStore preview 4

This post was originally published on this site

Two updated preview releases are now available on the PowerShell Gallery:

For more information on these modules check out these previous blog posts:

Before installing these modules, please uninstall the current preview versions of the modules and restart your PowerShell session.

To install these updates run the following commands:

Uninstall-Module Microsoft.PowerShell.SecretManagement -Force 
Uninstall-Module Microsoft.PowerShell.SecretStore -Force 
# Restart your PowerShell session 
Install-Module -Name Microsoft.PowerShell.SecretManagement -AllowPrerelease -Repository PSGallery 
Install-Module -Name Microsoft.PowerShell.SecretStore -AllowPrerelease -Repository PSGallery 
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault -AllowClobber

SecretManagement preview 6 updates

This update to SecretManagement improves the compatibility of the module with Windows PowerShell, and improved the usability of the module by providing more ways to unregister vaults and by setting the first registered vault as default as well a few other changes. Read the full list of changes below:

  • Improved compatibility with Windows PowerShell 5.1 (Issue #73)
  • The first extension vault added will automatically be designated the default vault (Issue #61)
  • Unregister-SecretVault -Name property now supports string[] type and wild cards (Issue #57#58)
  • Register-SecretVault now checks -VaultParameters hashtable for reserved Verbose entry and throws error if found
  • Set-DefaultVault now has a -ClearDefault parameter that designates no registered vault as the default vault
  • Register-SecretVault now supports a -Description parameter and registration information will include an optional extension vault description (Issue #46)

SecretStore preview 4 updates

This update to SecretStore focuses on updates which improve the compatibility with Windows PowerShell. Read the full list of changes below:

  • Improved compatibility with Windows PowerShell when creating new store files (Issue #28)
  • SecretStore binary is now built against net461 to provide full compatibility when run in PowerShell 6 or Windows PowerShell
  • System.IO.FileSystem.AccessControl.dll is now shipped with module to maintain compatibility with Windows PowerShell

Finding other available extension Vaults

To find other SecretManagement extension vault modules, search the PowerShell Gallery for the “SecretManagement” tag. Some community vault extensions that are available:

Thank you to everyone who has created vaults thus far!

Feedback and support

Community feedback has been essential to the iterative development of these modules. Thank you to everyone who has contributed issues, and feedback thus far! As we approach General Availability, targeted for later this year, for these modules now is the time to test the modules against your scenarios to request changes (especially breaking ones) and discover bugs. To file issues or get support for the SecretManagement interface or vault development experience please use the SecretManagement repository. For issues which pertain specifically to the SecretStore and its cmdlet interface please use the SecretStore repository.

Sydney Smith

PowerShell Team

The post SecretManagement preview 6 and SecretStore preview 4 appeared first on PowerShell.

Announcing PowerShell 7.1

This post was originally published on this site

We’re proud to announce the release of PowerShell 7.1, the latest major update to PowerShell 7. This release includes a number of improvements and fixes that build on top of the PowerShell 7.0 release in March and the recent GA release of .NET 5. Since then, the PowerShell Team (and many of you, our community contributors, thank you!) have been hard at work addressing some of the community’s top bug reports and feature requests.

What’s new in PowerShell 7.1?

For PowerShell 7.1, we decided to build on the foundation established in PowerShell 7.0 with a strong focus on community issues, especially where we could make additive changes and quality-of-life improvements without introducing instability or breaking changes. As a platform with over 115 million sessions per month, we’re absolutely committed to ensuring that PowerShell remains a stable and performant platform, even after significant version upgrades like 7.1.

For more details about what’s been added and fixed, make sure to check out the PowerShell 7.1 release notes.

Where can I get the latest version?

Our latest releases can always be found within the GitHub Releases for PowerShell.

For the first time, on Windows 10, you can also now pick up the latest version of PowerShell on the Microsoft Store.

More information on how to install across various platforms and architectures can be found at https://aka.ms/Install-PowerShell.

Why should I upgrade to PowerShell 7?

PowerShell 7 is the modern, cross-platform edition of PowerShell
built on top of .NET 5+ (formerly .NET Core). PowerShell 7 offers cross-platform support on Linux, macOS, and Windows, SSH-based remoting, parallelization, Docker containers, new operators and language features, and a massive long tail of small improvements and bug fixes.

If you’re still primarily a Windows PowerShell user, and you’re interested to learn more about the benefits and mechanics of moving to PowerShell 7, check out this doc on upgrading from Windows PowerShell to PowerShell 7.

What operating systems and distributions does PowerShell 7.1 support?

PowerShell 7.1 supports a wide variety of operating systems and platforms including:

  • Windows 8.1/10 (including ARM64)
  • Windows Server 2012 R2, 2016, 2019, and Semi-Annual Channel (SAC)
  • Ubuntu 16.04/18.04/20.04 (including ARM64)
  • Ubuntu 19.10 (via Snap package)
  • Debian 9/10
  • CentOS and RHEL 7/8
  • Fedora 30
  • Alpine 3.11+ (including ARM64)
  • macOS 10.13+

We also have community support for:

  • Arc Linux
  • Raspbian Linux
  • Kali Linux

Support lifecycle

PowerShell 7.1 is supported under the Microsoft Modern Lifecycle Policy for the same support timeline as .NET 5: currently 3 months after the release of .NET 6 in roughly one year.

This is in contrast to the PowerShell 7.0, an LTS release that will be supported until December of 2022.

For more information on the PowerShell 7 support lifecycle and requirements, check out https://aka.ms/PSLifecycle.

What else has the PowerShell Team been working on?

Over the last 6-12 months, you may have noticed that some of the more interesting new PowerShell Team functionality is being developed outside of the PowerShell repository within the PowerShell GitHub organization. In upholding our commitment to stability within the PowerShell language runtime, we’re doing as much of our fresh and experimental outside of the primary PowerShell project. Most of this work will live on the PowerShell Gallery, but some may eventually find its way back into the PowerShell project once the PowerShell Team is confident that it’s stable enough to reach the high stability bar that PowerShell 7 necessitates.

Some of these other projects and repositories include

Keep your eyes peeled on the PowerShell Team blog and @PowerShell_Team account on Twitter for more updates, previews, and developments on these efforts.

How can I give feedback

Please file issues in the PowerShell repository on GitHub to let us know about any features you’d like added or bugs that you encounter. Additionally, you can join us for the PowerShell Community Call on the 3rd Thursday of every month. The Community Call is a great opportunity to talk directly to the team, hear about the latest developments in PowerShell, and to voice your opinions into ongoing feature design.

And as always, we accept code, test, and documentation contributions in the form of pull requests on GitHub. If you’re interested in helping out on the project, check out our contribution guide.

Until next time!

Joey Aiello
Program Manager, PowerShell

The post Announcing PowerShell 7.1 appeared first on PowerShell.

Updating help for the PSReadLine module

This post was originally published on this site

Updating help for the PSReadLine module

You may have noticed an error message when trying to update the help for the PSReadLine module.

Error updating PSReadLine help

In the example above, I am trying to update help for the PSReadLine module on my Windows
computer. Take a close look at the error message. Notice the spelling of the module name in the
message:

Failed to update Help for the module(s) ‘PSReadline

In PowerShell 6 and higher, the PSReadLine module is spelled with a capital L character. But the
error message is using a lowercase letter.

The root cause of the error

The problem comes from Windows PowerShell 5.1. The version of the PSReadline module that shipped
in Windows PowerShell 5.1 used a lowercase letter in the name. The name of the module was changed
for the release of PowerShell 6. It now uses a capital L in the name.

The Update-Help cmdlet constructs the URL of the CAB file containing the updated help. The URL
path is case-sensitive. The updated help files use the new name with the capital L. PowerShell 6
and higher is installed side-by-side with Windows PowerShell. When you run Update-Help, the cmdlet
attempts to update the help for both versions of PowerShell. The name of the module that
Update-Help uses is based on the name of the folder where the help is stored. For Windows
PowerShell this is C:Program FilesWindowsPowerShellModulesPSReadline.

Note that only the update of help for the Windows PowerShell location is failing.

How to fix this problem

Fortunately the fix is simple. Just rename the folder to
C:Program FilesWindowsPowerShellModulesPSReadLine. To rename this folder, you must be sure to
close all Windows PowerShell sessions to release any open file handles on the directory. Use the
Windows File Explorer to rename the file. If you try to rename the folder from the command line, you
receive the following error message.

Rename-Item: Source and destination path must be different.

Rename module folder

 

The post Updating help for the PSReadLine module appeared first on PowerShell.

SecretManagement and SecretStore Updates

This post was originally published on this site

Two updated preview releases are now available on the PowerShell Gallery:

Before installing these modules please uninstall the current preview versions of the modules and restart your PowerShell session.

To install these updates run the following commands:

Uninstall-Module Microsoft.PowerShell.SecretManagement -Force 
Uninstall-Module Microsoft.PowerShell.SecretStore -Force 
#Restart your PowerShell session 
Install-Module -Name Microsoft.PowerShell.SecretManagement -AllowPrerelease -Repository PSGallery 
Install-Module -Name Microsoft.PowerShell.SecretStore -AllowPrerelease -Repository PSGallery 
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault -AllowClobber

SecretManagement Preview 5 Updates

This update to SecretManagement improves the usability of the module by adding name completers, and adding functionality to Unregister-SecretVault for vault extension authors as well a a few other changes. Read the full list of changes below:

  • Get-Secret -Name parameter now accepts arguments with wild card characters as literals (Issue #67)
  • The Verbose parameter switch is now passed to extension vault module functions as an AdditionalParameters name/value pair (Issue #66)
  • Get-SecretVault -Name parameter now takes a string[] type argument (Issue #59)
  • Test-SecretVault -Name parameter now takes a string[] type argument and accepts wild card characters (Issue #56)
  • Register-SecretVault now has a -PassThru parameter to return information on the secret vault just registered
  • When an extension vault is unregistered and if the vault provides a Unregister-SecretVault function, that extension vault function will be called before the extension vault is unregistered (Issue #60)
  • Vault name and Secret name completers have been added to the cmdlets (Issue #35)

SecretStore Preview 3 Updates

This update to SecretStore includes updates to the cmdlet interface based on user feedback and desire to optimize the usability of the vault. Read the full list of changes below:

  • Set-SecretStoreConfiguration now has a -PassThru parameter to write the store configuration object to the pipeline, and no longer writes the configuration object by default (Issue #25).
  • -PasswordTimeout value of zero now allows the provided password to be used only once (Issue #30).
  • When setting a password, an empty password is no longer accepted (Issue #31).
  • Set-SecretStorePassword now has a parameter set that takes old/new password arguments, to allow setting password by automation (Issue #26).
  • Reset-SecretStore now has a new -Password and -PassThru parameter.
  • Reset-SecretStore will now prompt immediately for a new password, if password authentication is selected and prompt interaction is allowed (Issue #34)

Finding other available extension Vaults

To find other SecretManagement extension vault modules, search the PowerShell Gallery for the “SecretManagement” tag. Some community vault extensions that are available:

Thank you to everyone who has created vaults thus far!

Feedback and Support

Community feedback has been essential to the iterative development of these modules. Thank you to everyone who has contributed issues, and feedback thus far! As we approach General Availability, targeted for later this year, for these modules now is the time to test the modules against your scenarios to request changes (especially breaking ones) and discover bugs. To file issues or get support for the SecretManagement interface or vault development experience please use the SecretManagement repository. For issues which pertain specifically to the SecretStore and its cmdlet interface please use the SecretStore repository.

Sydney Smith PowerShell Team

The post SecretManagement and SecretStore Updates appeared first on PowerShell.

PowerShell Working Groups

This post was originally published on this site

Since we open sourced PowerShell in 2016, PowerShell has been an immensely popular project on GitHub.
Every year,
700-1000 PRs and 1300-1500 issues are submitted to the PowerShell repo,
with roughly half of the PRs and 90% of the issues filed from the community.

We realize that some of these issues and PRs have been piling up and,
as the project has grown in popularity and community activity,
we sometimes struggle with the sheer volume of them.
Those of us on the PowerShell Committee have been discussing some ways that we think
we might be able to improve the efficiency of our decision-making process,
and to reduce bottlenecks that may be causing the increase in our overall backlog.

We set out with a couple of goals:

First, we wanted to increase the velocity of innovation in PowerShell,
but without compromising the stability of the engine and language that so many depend upon
within their critical infrastructure and automation environments.
It’s critical that anything we do in changing the management of the PowerShell project not jeopardize this.

We also noticed that a lot of contributor time is being spent on contributions and discussions that
are ultimately rejected by Maintainers or the Committee.
Despite being rejected for legitimate reasons (e.g. risky breaking changes),
we recognize that the rejection could happen before the contributor spends considerable time and effort.

To that end, we want to:

  1. increase the number of people who can make approve or reject proposals,
    especially where those people have domain-specific knowledge about a topic
  2. make those approvals and rejections more explicit, giving contributors confidence in moving forward
  3. make approvals and rejections earlier in the process to avoid unnecessary work for contributors and maintainers

Working Groups

To meet these goals, we are introducing the concept of Working Groups (WGs) within the PowerShell project
(including those repositories that contribute their modules into the PowerShell package).
You can think of WGs as subcommittees for specific areas within the PowerShell project.
Some of their responsibilities include:

  1. Fostering discussions in issues and pull requests
  2. Deciding whether feature proposals need request-for-comment (RFC) docs to be approved by the Committee
  3. Approving or rejecting feature proposals in issues
  4. Offering guidance and expertise in RFC discussions
  5. Triaging bugs filed as issues
  6. Reviewing code in pull requests

Initially, working groups will only consist of PowerShell Team members,
but we will be reaching out to high-impact community contributors over the next few months
to gauge their interest in joining WGs.

Issue Flow

There are two primary categories of issues that get filed in the PowerShell repository:
bugs and feature proposals.
Bugs and features will each be handled differently going forward.

Bugs

Bugs are the easy case. At a high-level, when a bug gets filed:

  1. A Maintainer will label the issue with the appropriate Working Group(s)
  2. Working Group members for those labels will review the bug to determine if it is a legitimate bug,
    by-design, external to the project, and/or worth spending time to fix
    (based on the value, complexity, risk, etc.)
  3. When a bug has been established as legitimate, Working Group members will establish the severity of the bug
    (i.e. the importance of fixing it)
  4. If and when a PowerShell Team member or contributor files a PR to fix the bug,
    at least one Working Group member will be responsible for reviewing the PR.

In practice, this is similar to how bugs are already handled today.
However, we’re hopeful that the addition of Working Group members outside of the PowerShell Team
will enable a greater number of bugs to be triaged and resolved appropriately,
as well as to unblock a number of bug fixes in PR that are of a lower priority.

Feature Proposals

Feature proposals are a little more complicated.

First and foremost, any new feature proposals should initially be filed
as issues, specifically using the issue template for feature
requests

(subject to some ongoing changes). This issue must include:

  • a description of the feature being proposed
  • the scenario for using the feature (i.e. why is the feature useful
    in the real world)
  • examples of how the feature might work in practice (including mandatory example script blocks and output)

Again, Maintainers will label the issue for the appropriate WGs in order to bring them into the issue for discussion.
Working Group members will facilitate a discussion with the community around the utility and design of the proposal,
as well as contributing their expertise on the feasibility and design consistency of implementing the proposal.

One pattern that we are noticing within the PowerShell repo today is the large number of proposals that could
be implemented outside of PowerShell itself (usually via external modules).
In keeping with our goal of maintaining stability in PowerShell,
we’d prefer that this experimentation happens via the PowerShell Gallery,
where modules can be published as prerelease,
and where semantic versioning can be used to communicate breaking changes.
Therefore, WGs will aggressively reject any feature proposals that can be implemented
externally from the repo.

WGs will also decide whether they believe the feature proposal requires an RFC,
based on the complexity, size, and potential impact of the proposal.
Where RFCs are not required, WGs will approve the proposal and then will review the eventual PR to implement it.
Where RFCs are required, contributors will be asked to submit RFCs.
Working Group members will participate heavily in the RFC discussion,
contributing their expertise to help the Committee make decisions on whether to accept the proposal.

Experimental Features

Experimental features are features shipped in PowerShell that are not officially supported as they may be
unstable or subject to change in the future.
(They’re turned on by default in preview branches and off by default in officially supported versions,
including release candidates.)

We introduced experimental features as a way to accelerate development and gather feedback in situations where
we’re unsure whether a specific approach is best,
and where we may want to change the behavior before users start depending on it in production.

In the past, we’ve largely used experimental features for new behavior that we already have a strong intent to eventually merge.
While we’ve caught certain issues that have prevented experimental features from being accepted as stable,
we believe the current perception is that these features will eventually become stable.

In the future, we’d like to use experimental features for experimenting
and gathering user feedback on whether a feature should exist at all,
with a more explicit assertion that many of them will never find their way to a supported GA release.
This means that we may be accepting more PRs into PowerShell as experimental features,
but that this acceptance is not necessarily long-term acceptance into PowerShell.

Instead, the RFC process will be used to convey full acceptance,
something that may happen long after code has been accepted as experimental.
And in fact, the feedback received around the experimental will be used by the Committee to inform the RFC decision.

What’s next?

Similar to the way we roll out functionality in PowerShell,
we’ll be taking a staged approach to rolling out these governance changes, taking feedback along the way.

In the near term, members of the PowerShell Team have been added to preliminary WGs,
and you’ll see Area issue labels change to reflect these WGs as we’ve defined them.
Members of these WGs will be responsible for triaging new issues under those labels,
reviewing PRs under those labels, and (eventually) working through the backlog of existing issues.
WGs will also be experimenting with various ways of organizing themselves,
including how they divvy up issues/PRs and how much consensus amongst themselves to make a decision.

Over the next couple months, we’ll introduce more of this process as official governance proposals within the RFC repo,
and update our existing governance language to reflect the new changes.
These changes may continue to evolve as we learn more about what does and doesn’t work.

The Committee will address existing RFCs on a case-by-case basis.
Some have already been extensively discussed as issues and/or RFC discussions,
and we may choose to move forward with experimental implementations or reject them altogether.

If folks feel that issues, pull requests, or RFCs aren’t being adequately addressed by WGs,
they should still feel free to mention @PowerShell/powershell-committee
or to request that a Review-Committee label be added.
In the future, we’ll have more guidance on how escalations and Committee reviews will work.

Eventually, we’ll reach out to contributors who may be interested in joining these Working Groups,
completing our original goal of increasing the number of people who can make decisions about specific areas of
PowerShell.

Thank you!

Thanks to our contributors and users for continuing to submit issues, pull requests, and RFCs to the PowerShell repo.
We appreicate your patience as we work towards this new model, and we encourage you to provide feedback as issues
in the PowerShell-RFC repo as we continue on this journey.

The post PowerShell Working Groups appeared first on PowerShell.

This post was originally published on this site

PowerShell Working Groups

Since we open sourced PowerShell in 2016, PowerShell has been an immensely popular project on GitHub.
Every year,
700-1000 PRs and 1300-1500 issues are submitted to the PowerShell repo,
with roughly half of the PRs and 90% of the issues filed from the community.

We realize that some of these issues and PRs have been piling up and,
as the project has grown in popularity and community activity,
we sometimes struggle with the sheer volume of them.
Those of us on the PowerShell Committee have been discussing some ways that we think
we might be able to improve the efficiency of our decision-making process,
and to reduce bottlenecks that may be causing the increase in our overall backlog.

We set out with a couple of goals:

First, we wanted to increase the velocity of innovation in PowerShell,
but without compromising the stability of the engine and language that so many depend upon
within their critical infrastructure and automation environments.
It’s critical that anything we do in changing the management of the PowerShell project not jeopardize this.

We also noticed that a lot of contributor time is being spent on contributions and discussions that
are ultimately rejected by Maintainers or the Committee.
Despite being rejected for legitimate reasons (e.g. risky breaking changes),
we recognize that the rejection could happen before the contributor spends considerable time and effort.

To that end, we want to:

  1. increase the number of people who can make approve or reject proposals,
    especially where those people have domain-specific knowledge about a topic
  2. make those approvals and rejections more explicit, giving contributors confidence in moving forward
  3. make approvals and rejections earlier in the process to avoid unnecessary work for contributors and maintainers

Working Groups

To meet these goals, we are introducing the concept of Working Groups (WGs) within the PowerShell project
(including those repositories that contribute their modules into the PowerShell package).
You can think of WGs as subcommittees for specific areas within the PowerShell project.
Some of their responsibilities include:

  1. Fostering discussions in issues and pull requests
  2. Deciding whether feature proposals need request-for-comment (RFC) docs to be approved by the Committee
  3. Approving or rejecting feature proposals in issues
  4. Offering guidance and expertise in RFC discussions
  5. Triaging bugs filed as issues
  6. Reviewing code in pull requests

Initially, working groups will only consist of PowerShell Team members,
but we will be reaching out to high-impact community contributors over the next few months
to gauge their interest in joining WGs.

Issue Flow

There are two primary categories of issues that get filed in the PowerShell repository:
bugs and feature proposals.
Bugs and features will each be handled differently going forward.

Bugs

Bugs are the easy case. At a high-level, when a bug gets filed:

  1. A Maintainer will label the issue with the appropriate Working Group(s)
  2. Working Group members for those labels will review the bug to determine if it is a legitimate bug,
    by-design, external to the project, and/or worth spending time to fix
    (based on the value, complexity, risk, etc.)
  3. When a bug has been established as legitimate, Working Group members will establish the severity of the bug
    (i.e. the importance of fixing it)
  4. If and when a PowerShell Team member or contributor files a PR to fix the bug,
    at least one Working Group member will be responsible for reviewing the PR.

In practice, this is similar to how bugs are already handled today.
However, we’re hopeful that the addition of Working Group members outside of the PowerShell Team
will enable a greater number of bugs to be triaged and resolved appropriately,
as well as to unblock a number of bug fixes in PR that are of a lower priority.

Feature Proposals

Feature proposals are a little more complicated.

First and foremost, any new feature proposals should initially be filed
as issues, specifically using the issue template for feature
requests

(subject to some ongoing changes). This issue must include:

  • a description of the feature being proposed
  • the scenario for using the feature (i.e. why is the feature useful
    in the real world)
  • examples of how the feature might work in practice (including mandatory example script blocks and output)

Again, Maintainers will label the issue for the appropriate WGs in order to bring them into the issue for discussion.
Working Group members will facilitate a discussion with the community around the utility and design of the proposal,
as well as contributing their expertise on the feasibility and design consistency of implementing the proposal.

One pattern that we are noticing within the PowerShell repo today is the large number of proposals that could
be implemented outside of PowerShell itself (usually via external modules).
In keeping with our goal of maintaining stability in PowerShell,
we’d prefer that this experimentation happens via the PowerShell Gallery,
where modules can be published as prerelease,
and where semantic versioning can be used to communicate breaking changes.
Therefore, WGs will aggressively reject any feature proposals that can be implemented
externally from the repo.

WGs will also decide whether they believe the feature proposal requires an RFC,
based on the complexity, size, and potential impact of the proposal.
Where RFCs are not required, WGs will approve the proposal and then will review the eventual PR to implement it.
Where RFCs are required, contributors will be asked to submit RFCs.
Working Group members will participate heavily in the RFC discussion,
contributing their expertise to help the Committee make decisions on whether to accept the proposal.

Experimental Features

Experimental features are features shipped in PowerShell that are not officially supported as they may be
unstable or subject to change in the future.
(They’re turned on by default in preview branches and off by default in officially supported versions,
including release candidates.)

We introduced experimental features as a way to accelerate development and gather feedback in situations where
we’re unsure whether a specific approach is best,
and where we may want to change the behavior before users start depending on it in production.

In the past, we’ve largely used experimental features for new behavior that we already have a strong intent to eventually merge.
While we’ve caught certain issues that have prevented experimental features from being accepted as stable,
we believe the current perception is that these features will eventually become stable.

In the future, we’d like to use experimental features for experimenting
and gathering user feedback on whether a feature should exist at all,
with a more explicit assertion that many of them will never find their way to a supported GA release.
This means that we may be accepting more PRs into PowerShell as experimental features,
but that this acceptance is not necessarily long-term acceptance into PowerShell.

Instead, the RFC process will be used to convey full acceptance,
something that may happen long after code has been accepted as experimental.
And in fact, the feedback received around the experimental will be used by the Committee to inform the RFC decision.

What’s next?

Similar to the way we roll out functionality in PowerShell,
we’ll be taking a staged approach to rolling out these governance changes, taking feedback along the way.

In the near term, members of the PowerShell Team have been added to preliminary WGs,
and you’ll see Area issue labels change to reflect these WGs as we’ve defined them.
Members of these WGs will be responsible for triaging new issues under those labels,
reviewing PRs under those labels, and (eventually) working through the backlog of existing issues.
WGs will also be experimenting with various ways of organizing themselves,
including how they divvy up issues/PRs and how much consensus amongst themselves to make a decision.

Over the next couple months, we’ll introduce more of this process as official governance proposals within the RFC repo,
and update our existing governance language to reflect the new changes.
These changes may continue to evolve as we learn more about what does and doesn’t work.

The Committee will address existing RFCs on a case-by-case basis.
Some have already been extensively discussed as issues and/or RFC discussions,
and we may choose to move forward with experimental implementations or reject them altogether.

If folks feel that issues, pull requests, or RFCs aren’t being adequately addressed by WGs,
they should still feel free to mention @PowerShell/powershell-committee
or to request that a Review-Committee label be added.
In the future, we’ll have more guidance on how escalations and Committee reviews will work.

Eventually, we’ll reach out to contributors who may be interested in joining these Working Groups,
completing our original goal of increasing the number of people who can make decisions about specific areas of
PowerShell.

Thank you!

Thanks to our contributors and users for continuing to submit issues, pull requests, and RFCs to the PowerShell repo.
We appreicate your patience as we work towards this new model, and we encourage you to provide feedback as issues
in the PowerShell-RFC repo as we continue on this journey.

The post appeared first on PowerShell.

SecretManagement and SecretStore Updates

This post was originally published on this site

Two updated preview releases are now available on the PowerShell Gallery:

Please note that these preview releases contain breaking changes. This version of SecretStore is incompatible with previous versions because the configuration format has changed. The previous file store cannot be read by the new version and you will need to reset the store Reset-SecretStore after installing the new version. Be sure to save your current stored secrets before upgrading so they can be re-added after you Reset your SecretStore.

To install these updates run the following commands:

Install-Module SecretManagement -Force -AllowPrerelease 
Install-Module SecretStore -Force -AllowPrerelease 
Reset-SecretStore

SecretManagement Preview 4 Updates

This update to SecretManagement addresses a bug blocking vault registration on Windows PowerShell, adds additional pipeline support, and makes several changes to improve the vault developer experience. Read the full list of changes below:

  • Fixes issue with registering extension vaults on Windows PowerShell (Error: Cannot bind argument to parameter ‘Path’ …)
  • Changes SecretVaultInfo VaultName property to Name, for consistency
  • Changes Test-SecretVault -Vault parameter changed to -Name for consistency
  • Adds -AllowClobber parameter switch to Register-SecretVault, to allow overwriting existing vault
  • Register-SecretVault uses module name as the friendly name if the -Name parameter is not used
  • Unregister-SecretVault now supports Name parameter argument from pipeline
  • Set-DefaultVault now supports Name and SecretVaultVaultInfo parameter arguments from pipeline
  • Set-Secret now supports SecretInfo objects from the pipeline
  • Adds -WhatIf support to Secret-Secret
  • Adds -WhatIf support to Remove-Secret

SecretStore Preview 2 Updates

This update to SecretStore includes updates to the cmdlet interface based on user feedback and desire to conform to PowerShell best practices. This update also updates error messaging to provide a clarified user experience. Read the full list of changes below:

  • Set-SecretStoreConfiguration now supports -Authentication and -Interaction parameters instead of -PasswordRequired and -DoNotPrompt switches
  • Update-SecretStorePassword has been renamed to Set-SecretStorePassword
  • Unlock-SecretStore no longer supports plain text passwords
  • Set-SecretStoreConfiguration now throws an error if called with no parameters
  • Added ProjectUri and “SecretManagement” tag to manifest file
  • Reset-SecretStore now defaults to ‘No’ when prompting to continue.

Tagging your extension vault on the PowerShell Gallery

If you are publishing an extension vault to the PowerShell Gallery we ask that you add the tag “SecretManagement” to the module manifest. This will the vault to be more discoverable for SecretManagement users.

Feedback and Support

As we approach General Availability for these modules now is the time to test the modules against your scenarios to request changes (especially breaking ones) and discover bugs. To file issues or get support for the SecretManagement interface or vault development experience please use the SecretManagement repository. For issues which pertain specifically to the SecretStore and its cmdlet interface please use the SecretStore repository.

Sydney Smith

PowerShell Team

 

The post SecretManagement and SecretStore Updates appeared first on PowerShell.

SecretManagement Module Preview Design Changes

This post was originally published on this site

SecretManagement Module Preview Design Changes

This article is intended primarily for SecretManagement extension vault developers.
It covers design changes that an extension vault implementer must be aware of.

It has been about 6 months since we published a pre-release alpha version of SecretManagement.
Since that time we have received a bunch of great feedback from the community.
There have been a number of incremental changes and improvements (including changing the name of the module).
But it also became clear that the original vision and design suffered some shortcomings.
Consequently, we re-thought the design and have been experimenting with various changes.
For this preview release, we now have what we feel is a better and simpler design providing a consistent cross-platform experience.

Changes

Design Issues

One problem with the previous alpha release was that it depended on the Windows Credential Manager (CredMan) for the built-in local vault.
The built-in local vault is a secure local store that is always available, regardless of whether any extension vaults are registered.
CredMan is Windows platform only, and so the pre-release version of SecretManagement worked only on Windows.
The plan was to eventually find similar third party solutions for non-Windows platforms.
However it turns out that CredMan is pretty unique, and there are no equivalent solutions on non-Windows platforms.
In addition community members pointed out that CredMan only works for interactive log-in accounts, and this means SecretManagement pre-release would not work with Windows built-in accounts or over PowerShell remoting.

Another problem was the decision to allow extension vaults to be written either as a binary C# implementing type or a PowerShell module.
These two forms of an extension vault are quite different, and the code became complex trying to accommodate them both.
The result was that extension vaults written in the two forms would have different behavior.

An original design goal was to abstract both management of secrets and management of secret vaults.
But we found that the way we abstracted secret vaults was too restrictive to accommodate the wide variety of existing local and cloud based secure store solutions we saw.
With this new design we are focusing on abstracting the management of secrets.
The purpose of SecretManagement is to provide scripts a common way to access secrets from widely different secret store solutions.
So the new design leaves it to the individual vault solutions how they are installed, configured, and authenticated.

Built-In Local Vault

The built-in local vault served two purposes.
It provided an out-of-the-box secure local store, and also provided a way to store sensitive registration data for extension vaults.
But using CredMan as the local store limited SecretManagement to Windows platform, without any good similar solutions on other platforms.
Nevertheless, a CredMan based extension vault is still useful for many Windows platform scenarios, and so we now have a CredMan based extension vault example available in the GitHub repo.

The original design allowed extension vault implementations to store additional vault registry information securely in the built-in local vault.
But we never saw a case where this was needed.
Secure store solutions have their own way to authenticate a user and don’t need to store sensitive data.

Consequently, the built-in local vault has been removed from SecretManagement.
All storage mechanisms are now extension vaults only.
But SecretManagement without an extension vault is not very useful, so we are also publishing a preview release of a new cross-platform secure store extension vault.
You can read more about the new SecretStore Extension Vault in the section below.

We have also added the ability to designate a registered extension vault as a Default vault.
The default vault works like the built-in vault did.
If no vault is specified when adding a secret, it is added to the default vault.
Also the default vault is searched before any other registered vault, when retrieving secrets.

Implementing Type

Support for an extension vault based on an implementing type has been removed.
This greatly simplifies SecretManagement and provides a more uniform development experience.

Now, extension vaults are just PowerShell modules that implement five required functions.
When an extension vault is registered as a module, it is verified to have the correct form and to implement the expected functions.
The extension vaults can be PowerShell script modules or binary modules, and the SecretManagement GitHub repo has examples of both forms.

Extension Vault User Interaction

Previously, an extension vault communicated to the user indirectly by passing results and error messages up to SecretManagement.
However, this greatly complicated writing extension vaults around existing secret store solutions on various platforms.
It was very difficult or impossible to support different forms of authentication.
For example, an extension vault couldn’t prompt the user directly for some action such as providing a password.

But now extension vaults are just PowerShell modules and their exposed functions (cmdlets) are called on the UI thread.
So each extension vault can now write to the pipeline, error or data streams, and can directly prompt users for actions.

This means an extension vault now has much more leeway in how it communicates to the user.
But it is also responsible for ensuring a consistent user experience with other vaults.
An extension vault should take care to write only expected data to the pipeline, and to write error data only for abnormal conditions specific to the vault implementation.
Common error conditions, such as secret not found should be left to SecretManagement.

Extension Vault Module Format

Now that SecretManagement calls extension vault functions on the UI thread, there have been some changes in how an extension module resides on file.
Each extension vault module implements the same five functions.
SecretManagement needs to disambiguate the function calls, and also ensure that these functions do not appear in the user command space.

To do this, an extension vault module must conform a specific file structure.
The following is an example of the required file structure for an extension vault named TestVault:

./TestVault
./TestVault/TestVault.psd1
./TestVault/TestStoreImplementation.dll
./TestVault/TestVault.Extension
./TestVault/TestVault.Extension/TestVault.Extension.psd1
./TestVault/TestVault.Extension/TestVault.Extension.psm1

The TestVault module contains a normal TestVault.psd1 PowerShell module manifest file.
It also has an optional TestStoreImplementation.dll binary that implements the actual store.
The manifest file looks like this:

@{
    ModuleVersion = '1.0'
    RootModule = '.TestStoreImplementation.dll'
    NestedModules = @('.TestVault.Extension')
    CmdletsToExport = @('Set-TestStoreConfiguration','Get-TestStoreConfiguration')
}

The manifest file exports two optional cmdlets used to configure the store.
But the only required field is NestedModules that tells PowerShell to load the TestVault.Extension sub module as a nested module of TestVault.

It is the TestVault.Extension module that contains the required function implementations.
It must be named with the parent module name plus the .Extension part appended to it.
The TestVault.Extension hides the SecretManagement required functions from the user, and also uniquely qualifies the functions for this specific extension vault module.
The TestVault.Extension sub module contains the expected .psd1 and .psm1 files.
The manifest file looks like:

@{
    ModuleVersion = '1.0'
    RootModule = '.TestVault.Extension.psm1'
    RequiredAssemblies = '..TestStoreImplementation.dll'
    FunctionsToExport = @('Set-Secret','Get-Secret','Remove-Secret','Get-SecretInfo','Test-SecretVault')
}

The TestVault.Extension module is dependent on the TestStoreImplementation.dll binary file, which implements the actual store.
But this is optional, and a simpler .Extension module implementation could implement everything within PowerShell script.
One example of this might be a cloud based extension vault that is accessed through PowerShell cmdlets or REST APIs.

For more extension vault module examples, see the SecretManagement GitHub repo.

SecretStore Extension Vault

The Microsoft.PowerShell.SecretStore extension vault module is a secure local store for SecretManagement.
It is open source and currently available as a preview version on PowerShell Gallery.
SecretStore is based on .NET Core cryptographic APIs, and works on all PowerShell supported platforms.
Secret data is stored at rest in encrypted form on the file system and in memory, and only decrypted when returned to a user request.
SecretStore works within the scope of the current user, and is configurable.

By default SecretStore is configured to require a password, as this provides the strongest security.
When a password is provided, it remains valid in the current PowerShell session until the PasswordTimeout time elapses.
When the password becomes invalid, the store can be configured to prompt the user or otherwise throw an exception.
The user can provide the password through an interactive prompt or with the Unlock-SecretStore cmdlet.
The Unlock-SecretStore is intended for automation scenarios where user interaction is not possible.

PS C:> Get-SecretStoreConfiguration

      Scope PasswordRequired PasswordTimeout DoNotPrompt
      ----- ---------------- --------------- -----------
CurrentUser             True             900       False

SecretStore can be configured to not require a password, but will be less secure.
Secrets are still encrypted on file and in memory.
But the encryption key is stored on file and protected only by the platform file system.
It is strongly encouraged that SecretStore be configured to require a password.

The following cmdlets are provided to manage SecretStore:

  • Get-SecretStoreConfiguration
  • Set-SecretStoreConfiguration
  • Unlock-SecretStore
  • Update-SecretStorePassword
  • Reset-SecretStore

Paul Higinbotham
PowerShell Team

The post SecretManagement Module Preview Design Changes appeared first on PowerShell.

SecretManagement Preview 3

This post was originally published on this site

We are excited to announce two modules are now available on the PowerShell Gallery:

To install the modules, and register the SecretStore vault, open any PowerShell console and run:

Install-Module Microsoft.PowerShell.SecretManagement -AllowPrerelease
Install-Module Microsoft.PowerShell.SecretStore -AllowPrerelease
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault

NOTE: This version of the module has a major breaking changing, if you have used past preview versions of the SecretManagement module, secrets previously stored will not be accessible in this version. Please migrate your secrets before updating. Your old secrets will not be removed after updating so they can be accessed by explicitly importing an earlier version of the module.

This blog will explain what to expect from these modules, how to try them out, and what is coming next.

Re-Introducing SecretManagement

The SecretManagement module helps users manage secrets by providing a common set of cmdlets to interface with secrets across vaults. This module supports an extensible model where local and remote vaults can be registered and unregistered for use in accessing and retrieving secrets. The module provides the following cmdlets for accessing secrets and managing SecretVaults:

 

Get-Secret
Get-SecretInfo
Get-SecretVault
Register-SecretVault
Remove-Secret
Set-Secret
Test-SecretVault
Unregister-SecretVault

 

SecretManagement is valuable in heterogeneous environments where you may want to separate the specifics of the vault from a common script which needs secrets. SecretManagement is also as a convenience feature which allows users to simplify their interactions with various vaults by only needing to learn a single set of cmdlets.

Some key scenarios we have heard from PowerShell users are:

  • Sharing a script across my org (or Open Source) without knowing the platform/local vault of all the users
  • Running my deployment script in local, test and production with the change of only a single parameter (-Vault)
  • Changing the backend of the authentication method to meet specific security or organizational needs without needing to update all my scripts

Secret Management Preview 3

Since our first two preview releases we have done significant investigation to maximize the usability, supportability, and extensibility of the module. Through this process we have re-designed the module is a couple of impactful ways:

  • Separated the SecretManagement module from a built-in default vault
  • Simplified the experience for authoring vaults to give more flexibility to authors–for more information on that check out this vault-author focused blog post

Separating SecretManagement from a built in vault

In this release we have separated the interface for accessing secrets and registering vaults from any vault implementation. We made this decision based on feedback that there are trade-offs between security, usability, and specificity for any vault that would be built into the SecretManagement module. We opted for a configurable model that allows the user to install and set as default the vault that best matches their requirements.

Consequently, vault registration metadata is stored on the file system with the expectation that it is not sensitive data. As a part of this design we leave secure vault authentication up to the vault extensions. While some vault implementations may take advantage of user context others may require interactive authentication from the user (or use another method).

We recognize that the value of the SecretManagement interface comes from the available underlying vaults. In other words if there are no vault extensions to register the module is useless. With this in mind, we wrote (and published a preview of) a local, cross-platform vault called SecretStore. We hope this vault not only proves useful for SecretManagement users but also serves as an example for extension vault authors looking to build off of existing vaults. We have also provided an example implementation of a Windows Credential Manager vault in our GitHub repository.

SecretStore Preview 1

SecretStore is a cross-platform local extension vault which is available as a preview on the PowerShell Gallery. We designed this vault as a best attempt at creating a vault that is available where PowerShell is, usable in popular PowerShell scenarios (like automation and remoting) and utilizes common security practices. This vault does have security limitations and we recommend exploring alternative vaults if data is highly sensitive.

Features of SecretStore

The SecretStore vault stoes secrets locally on file for the current user, and uses .NET Core cryptographic APIs to encrypt file contents. This extension vault is configurable and works over all supported PowerShell platforms on Windows, Linux, and macOS. The following cmdlets are provided to manage SecretStore:

- Get-SecretStoreConfiguration
- Set-SecretStoreConfiguration
- Unlock-SecretStore
- Update-SecretStorePassword
- Reset-SecretStore

For more information on the design of the SecretStore please refer to this design document.

 

Getting started with SecretStore and SecretManagement

After you have installed the modules open any PowerShell console to register the vault and create your first secret.

# First Register the vault, the name parameter is a friendly name and can be anything you choose
PS C:> Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault
# Now you can create a secret, you will also need to provide a password for the SecretStore vault
PS C:> Set-Secret -Name TestSecret -Secret "TestSecret"
Vault SecretStore requires a password.
Enter password:
*******
# Run Get-Secret to retrieve the secret, using the -AsPlainText switch will return it as a readable string
PS C:> Get-Secret -Name TestSecret -AsPlainText
TestSecret
# To see metadata about all of your secrets you can run Get-SecretInfo
PS C:> Get-SecretInfo

Name                       Type VaultName
----                       ---- ---------
TestSecret               String SecretStore

 

What’s Next

Based on user feedback we plan to move towards a General Availability (GA) release for both modules. Through this time, we hope to work with vault extension authors to build out the vault ecosystem. The timing of these releases is highly dependent on feedback from this release.

Feedback and Support

To get support or give feedback on the SecretManagement module please open an issue in the SecretManagement repository. To get support or give feedback on the SecretStore module please open an issue in the SecretStore repository.

 

Sydney Smith
PowerShell Team

 

 

The post SecretManagement Preview 3 appeared first on PowerShell.

PowerShellGet 3.0 Preview 10 Release

This post was originally published on this site

In this blog post we are excited to share:

PowerShellGet 3.0 Preview Updates

PowerShellGet 3.0 preview 10 is now available on the PowerShell Gallery. This blog post will cover all of the feature updates since we last published a blog post ( preview 6). These versions include completed functionality for updating PSResources, input-object support for installing PSResources as well as several bug fixes. To install the latest version of the module, open any console any run:

Install-Module PowerShellGet -AllowPrerelease -Force -Repository PSGallery -SkipPublisherCheck

 

What’s new in the preview releases

New Features

  • Completed functionality for Update-PSResource
  • Input-Object parameter for Install-PSResource
  • Add ‘sudo’ check for admin privileges in Unix in Install-PSResource
  • Adds DSCResources

Bug Fixes

  • Improved experience when loading module for different frameworks
  • Bug fix for assembly loading error in Publish-PSResource
  • Allow for relative paths when registering a PSRepository
  • Improved error handling for Install-PSResource and Update-PSResource
  • Remove prerelease tag from module version directory
  • Fix error getting thrown from paths with incorrectly formatted module versions
  • Fix bug with retrieving installed scripts in Get-PSResource
  • Fix bug with AllUsers scope in Windows in Install-PSResource
  • Fix bug with Uninstall-PSResource sometimes not fully uninstalling
  • Change installed file paths to contain original version number instead of normalized version
  • Fix bug related to finding dependencies that do not have a specified version in Find-PSResource
  • Fix bug related to parsing ‘RequiredModules’ in .psd1 in Publish-PSResource
  • Improve error handling for when repository in Publish-PSResource does not exist
  • Fix for unix paths in Get-PSResource, Install-PSResource, and Uninstall-PSResource
  • Add debugging statements for Get-PSResource and Install-PSResource
  • Fix bug related to paths in Uninstall-PSResource
  • Bug fix for -ModuleName (used with -Version) in Find-PSResource returning incorrect resource type
  • Make repositories unique by name
  • Add tab completion for -Name parameter in Get-PSResource, Set-PSResource, and Unregister-PSResource
  • Remove credential argument from Register-PSResourceRepository
  • Change returned version type from ‘NuGet.Version’ to ‘System.Version’
  • Have Install output verbose message on successful installation (error for unsuccessful installation)
  • Ensure that not passing credentials does not throw an error if searching through multiple repositories
  • Remove attempt to remove loaded assemblies in psm1

What’s Next

We plan to have a minimum of three more releases as we approach general availability (GA) of the 3.0 module. Our next planned release, preview 11 will address these issues. Once we are feature complete we will have the release candidate (RC) version. If no high risk or high impact issues are reported after this, we will ship that version of the module (plus any small bug fixes) as the GA version of PowerShellGet 3.0.

Once we reach this important milestone, we will re-evaluate next steps for the module by assessing the flow of incoming issues and re-evaluating issues marked with the “vNext” milestone in the repository. After we reach GA of this module, we will continue to invest in making PowerShell’s package management experience great.

Availability in PowerShell

We plan to begin shipping PowerShellGet 3.0 in PowerShell 7.2 previews. In these releases of PowerShell 7.2 we will include 2 related modules:

  • PowerShellGet 3.0
  • CompatPowerShellGet

Introducing CompatPowerShellGet

CompatPowerShellGet is a compatibility module that allows use of PowerShellGet 2.x (and below) cmdlet syntax with PowerShellGet 3.0 (and newer) functionality by making a best effort mapping between the cmdlet interfaces of both versions of the module. For example, if a user has the CompatPowerShellGet module installed and runs the command: Install-Module PowerShellGet -MinimumVersion 1 -MaximumVersion 2 -AllowPrerelease The CompatPowerShellGet module will get auto loaded into the PowerShell Session and will map the command to PowerShellGet 3.0 syntax: Install-PSResource PowerShellGet -Version "[1,2]" -Prerelease" The command will then be executed by the PowerShellGet 3.0 implementation. The user will also get a warning to update their script to the new cmdlet interface: WARNING: The cmdlet 'Install-Module' is deprecated, please use 'Install-PSResource’.

This module is designed so that users will not need to immediately update their scripts in order to update to the latest version of PowerShell or to begin taking advantage of the performance improvements already available in PowerShellGet 3.0. We still do recommend that authors begin making the minimal changes required to update their scripts to the new cmdlet interface.

This compatibility module is designed so that it takes precedence over legacy versions of PowerShellGet. If you have this compatibility module installed and would not like it to be used, you can remove it from the PowerShell session using the Remove-Module command.

Please note that this flow is only possible if the user has both the CompatPowerShellGet module installed and the PowerShellGet 3.0 preview module installed. Once PowerShellGet 3.0 is generally available it will be a dependency of CompatPowerShellGet.

Please also note that this compatibility module will not be called if you use fully qualified cmdlets. For example, if you use PowerShellGetInstall-Module this will call a legacy version of PowerShellGet. If this is a common scenario for you, and will be a barrier to migrating to PowerShellGet 3.0 we would appreciate that feedback in our GitHub repository

Goals of Migration to PowerShellGet 3.0

While creating a migration plan for PowerShellGet users we had the following goals in mind.

  • Have the quality of PowerShellGet 3.0 be so high that users want to migrate their scripts
  • Reduce friction for users to take immediate advantage of improvements in PowerShellGet 3.0
  • Not break any scripts in the short term for user who adopt the latest available version of PowerShell
  • Create a low friction migration path for script and module owners
  • Have a single, widely used version of PowerShellGet (for supportability, and improvement reasons)

Look forward to the next blog post (coordinated with our RC release of PowerShellGet 3.0) detailing the feature and performance improvements in PowerShellGet 3.0. We hope this post will give insight into why we believe users will have the best possible experience by migrating to PowerShellGet 3.0.

Migration Timeline

Beginning with PowerShell 7.2 preview 1 release we will ship the latest versions of the PowerShellGet 3.0 and CompatPowerShellGet modules.

As we continue to track usage and feedback around the compatibility layer, as well as the PowerShellGet 3.0 module, we hope to move towards a long term goal of only shipping the latest version of PowerShellGet in new versions of PowerShell.

Feedback and Support

At this stage in our development of the module user feedback is critical. For support or feedback on PowerShellGet please open an issue in this GitHub repository. For support or feedback on the CompatPowerShellGet module, or the migration plan please open an issue in this GitHub Repository.

Sydney Smith
PowerShell Team

The post PowerShellGet 3.0 Preview 10 Release appeared first on PowerShell.