This change updates ModuleIntrinsics.GetModulePath to handle the case where the Windows PowerShell module path is already in the environment's PSModulePath or when launched from a different version of PowerShell.
Previously, GetModulePath would append $PSHOME\Modules to the PSModulePath after removing the path for the launching version without considering the Windows PowerShell module path. The result, was the Windows PowerShell modules were found first and loaded incompatible modules; such as the built-in modules.
The change detects the Windows PowerShell module path and inserts $PSHOME\Modules path before it. The new test simulates launching from a different version of pwsh that has already added the Windows PowerShell module path.
Fixes#7679
On Debian 9, libmi cannot resolve libssl and libcrypto. This change adds symbolic links to packaging and build to the $PSHOME directory to resolve the issue.
The fix was verified interactively connecting to office 365, importing the session, and ensuring Get-MailBox and Get-User succeed.
Fix#7598
* [FEATURE] Allow Basic Auth over HTTPS
* WSManTransportManager.cs: Simplify HTTPS check
Update comment in test to refer to the right exception type.
* Disable test until limi crash fo selected connection error paths is fixed
* Use Hex format for defining the expected HRESULT
This PR fixes the logging issue on Linux where logging is initialized before `-settingsFile` is parsed causing custom log settings to be ignored. (see ConsoleHost.cs and ManagedEntrance.cs)
The PR also includes basic logging tests for Linux and MacOS. PSSyslog.psm1 contains the functions to retrieve selected logged items (based on PowerShell's log id and a timestamp) and Logging.Tests.ps1 contains tests for Linux and MacOS.
Fix#6332
This change renames log and logerror functions to a single Write-Log [$message] [-error] function to avoid conflicting with the log command on MacOS.
- Remove previous `UseAlwaysAnalytic` workaround in `SysLogProvider.Log`
- Update Script Block logging to always log to the operational channel with `UseAlwaysOperational`
- Fix `PSChannel` on Linux to use a bitmask
- Handle `UseAlwaysOperational` and `UseAlwaysAnalytic` keywords but adding to `_keywordFilter` if the associated channels were selected in the configuration
Support loading a custom `powershell.config.json` file via the command-line for use in testing.
This change supports replacing the default `powershell.config.json` file that's usually loaded from the `PSHome` directory with a custom version file.
The primary use-cases for this command-line option are as follows:
1. Allow the CI system to disable settings that impact test run times; such as disabling syslog usage on Linux and MacOS
2. Support testing of syslog and os_log without interfering with normal PowerShell operations during test runs via launching an instance with custom log settings.
When calling powershell from powershell (called the minishell for historical reasons), the arguments are passed as a base64 encoded string.
The native command parameter binder was trying to match up the ast to the argument value, which in this case, doesn't make sense.
The fix is to ignore the ast during parameter binding for this case of calling powershell from powershell.
Fix#5733
Various SAL annotations were either incorrect or not backed up by code. This PR address these issues.
NOTE: By default, Start-BuildNativeWindowsBinaries does not enable code analysis and issues detected by SAL annotations are not reported. To identify these issues, run Start-BuildNativeWindowsBinaries to generate the solution and vcxproj files. Launch a Visual Studio developer prompt, cd to src\powershell-native and run msbuild manually.
> msbuild PowerShellNative.sln /p:RunCodeAnalysis=true /p:Configuration=RelWithDebInfo /p:Platform=x64
The following changes address all code analysis warnings:
- GetRegistryInfo in NativeMsh had incorrect out annotations, remove __opt
- Fix handling of various out parameters - check for non-null and initialize
- Update and Align SAL annotations for GetFormattedErrorMessage overloads
- Allow PluginException to accept NULL message.
Issue #4029 exposed two problems when failing to load libpsrpclient.
WSManAPIDataCommon.ctor was not identifying the binary that failed DLLImport; hindering diagnosability
PrioritySendDataCollection.Clear() would throw a NullReferenceException when called from the finalizer after an error path.
This change addresses both of the above:
Guard against null arrays in PrioritySendDataCollection.Clear() - called from finalizer in error paths.
Diagnosability: Log the DllNotFoundException in WSManAPIDataCommon ctor and also include it as the internal exception when throwing PSRemotingTransportException.
Update Restore-PSPester to include PR PowerShell/psl-pester#12 that fixesPowerShell/psl-pester#11 - unhandled exceptions in before/after bypasses Pester's enddescribe logic.
Update to the latest, while we are at it.
Issue #4029 exposed two problems when failing to load libpsrpclient.
WSManAPIDataCommon.ctor was not identifying the binary that failed DLLImport; hindering diagnosability
PrioritySendDataCollection.Clear() would throw a NullReferenceException when called from the finalizer after an error path.
This change addresses both of the above:
Guard against null arrays in PrioritySendDataCollection.Clear() - called from finalizer in error paths.
Diagnosability: Log the DllNotFoundException in WSManAPIDataCommon ctor and also include it as the internal exception when throwing PSRemotingTransportException.
Update Restore-PSPester to include PR PowerShell/psl-pester#12 that fixesPowerShell/psl-pester#11 - unhandled exceptions in before/after bypasses Pester's enddescribe logic.
Update to the latest, while we are at it.
* Add dependency nuget packaging instructions for PowerShell.Core.Instrumentation ETW resource binary.
* Fix markdown MD031 Fenced code blocks errors.
* Fix MD022 Headers should be surrounded by blank lines
* Add a note about Authenticode Dual-signing requirement.
* PR Feedback.
* Set version to Beta.10
- Build PowerShell.Core.Instrumentation.dll - Resource-only binary for the ETW resources.
- Create a registration script for registering/unregistering the ETW provider.
This PR is divided into the following areas:
1. Add/Rename the PowerShell/Windows ETW manifest to the repo and change both the provider id (guid) and name. See #4939.
The manifest is at tools/resxgen/PowerShell-Core-Instrumentation.man
2. Generate a resx file containing the string resources needed for logging ETW events to syslog.
This is accomplished by tools\resxgen\resxgen.psm1 and resxgen.ps1. The tool generates two files
A resx file containing string resources for each message string from the manifest. This is generated in the System.Management.Automation\gen directory.
A C# class (EventResource) that provides the mapping between the integer event id and the associated string resource name. The file is generated in the System.Management.Automation\CoreCLR directory with a compile-time condition of UNIX
NOTE: The EventResource.cs class generated by resgen is explicitly ignored in the csproj file; it is not used.
3. SMA\utils\tracing\PSSysLogProvider.cs
Implements the abstract LogProvider class and is the syslog equivalent of PSEtwLogProvider. The class contains a number of logical methods for logging lifecycle, health, and normal events.
4. SMA\utils\tracing\SysLogProvider.cs
This is the Syslog equivalent of ETW's log provider class and implements a Log method versus ETW's EventWrite. It is also responsible for resolving event ids to resource names and performing the Syslog call. There is a large comment block in the class XML doc that describes the types of log output it produces.
5. SMA\utils\tracing\PSEtwLog.cs
PowerShell's current implementation is tightly coupled to this class; with code calling it directly for all events. To simplify integration of syslog, I updated the class to create an instance of PSSysLogProvider on Linux and removed the Linux-specific stub file.
6. SMA\engine\PropertyAccessor.cs
This class provides a wrapper around PowerShellProperties.json and has been extended to have Unix-specific assessors for configuring logging. Note that the file is expected to be in the $PSHOME directory to ensure SxS.
Currently, there are four configuration properties:
- LogIdentity - the string identifier for the source application. This defaults to 'powershell' and can be configured to enable distinguishing between side-by-side installations.
- LogLevel - configures the tracing level (log level). Informational is the defauilt.
- LogChannels - used to enable operational and analytic logging. Operational is the default.
- LogKeywords - used to configure enabling tracing by keyword. All keywords other than `UseAlwaysAnalytic` are enabled by default.
NOTE: This will likely change. PowerShell sometimes confuses the analytic channel with this keyword and sends logging to the wrong channel. Once this is cleared up, `UseAlwaysAnalytic` and `UseAlwaysOperational` keywords will likely be removed.
Additional Notes:
1. The current implementation writes directly to syslog and writing to a separate log file is still pending.
2. The generated class and resx are not part of the build; instead, it is expected that Resxgen should be run when events are added to the manifest. To fully automate the process, resxgen will need to be updated to generate the other dependent enums such as 'PSChannel', 'PSEventId', 'PSTask', 'PSOpcode', etc. You will see parsing logic in resxgen.psm1 to prepare for that but it is not enabled at this point.
4. Documentation is pending that documents the format of the syslog output as well as associated configuration.
5. As mentioned at the start, tests are pending
This change mitigates intermittent timeout failures in the access denied tests as well as fixes unintended cross-test dependencies. If PowerShell takes longer that 10 seconds to complete a race can cause the subsequent test to pick up the output file of the previous test and fail (i.e., the expected output error file already exists from the previous test because it was created by the long running PowerShell process after the second test started.) Worse case, the failure cascades causing the race to propagate through the remaining tests in the set.
The fix is two fold:
1: Increase the timeout for waiting for the launched powershell process. (mitigation)
2: Ensure each uses a unique name for the error and done files to avoid polluting the next test.
This change removes the call to `ContentHelper.GetEncoding` since it's logic for returning a default encoding when a ContentType header is not found disables subsequent checks for meta charset definitions.
All variations of the Invoke-WebRequest tests have been mirrored for Invoke-RestMethod. Verbose output is used to verify the encoding since Invoke-RestMethod returns the JSON content directly instead of a response object. (See ExecuteRestMethod)
* Add -SkipHeaderValidation switch to Invoke-WebRequest and Invoke-RestMethod to support adding headers without validating the header value.
* Fix whitespace
Invoke-WebRequest and Invoke-RestMethod cmdlets will now strip authorization header on redirect unless the new parameter `-PreserveAuthorizationOnRedirect` is specified.
The FullCLR implementation uses WebRequest to perform the request which silently strips the Authorization header when a redirect occurs.
The CoreCLR implementation uses HttpClient to perform the request which does not strip the authorization header. The change explicitly handles the initial redirect, removes the authorization header and submits the request to location in the response.
Fixes#2227
Dan Travison