-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define a PowerShell BinaryFormatter Obsoletion Strategy #14054
Comments
BinaryFormatter is really only used by remoting for TimeZone. The only other case is the communication between |
cc @PaulHigin |
This seems to also hit remoting from .NET interactive, for which there doesn't appear to be a work around currently. |
@SteveL-MSFT @fMichaleczek we've recently managed to get our first .NET 6 builds of Devolutions Server, and we've encountered this issue which is fixed for now using EnableUnsafeBinaryFormatterSerialization. Can you confirm that whatever happens with the binary formatter deprecation, future versions of the PowerShell SDK will still be able to connect to older versions of PowerShell, especially for Windows PowerShell 5.1 over a WinRM transport? |
As said in the BinaryFormatter Obsoletion Strategy, the code will be removed in .Net 8. Until that you can use the code with EnableUnsafeBinaryFormatterSerialization. |
Yes, but that doesn't answer the question of backward compatibility with Windows PowerShell 5.1 servers when using a future .NET 8 PowerShell SDK client. I don't know how much it relies on BinaryFormatter, but is it possible to replace just the required bits in the PowerShell SDK such that it keeps working? BinaryFormatter may be deprecated, but Windows PowerShell 5.1 will still be officially supported for years to come as it ships built-in with Windows Server |
Obviously, the distance between .Net and the .Net Framework increases with each new version and the ecosystem is obviously splitting into two parts. As for PowerShell, this split has already happened and is doubly amplified by the split in .Net, so in my opinion it is not serious to talk about forward or backward compatibility. |
Correct me if I'm wrong, but from your answer it really looks like we're crossing fingers that by the time PowerShell uses .NET 8, Windows PowerShell 5.1 won't really be a thing anymore. I agree with deprecating BinaryFormatter, and it makes sense to drop support for it from the .NET runtime, but we need a plan to have a working PowerShell SDK that can still connect to the still-supported Windows PowerShell 5.1 when this happens. It is going to be there for a LONG time, it's built-in to Windows Server, and Windows Server has a long lifetime before reaching its EOL. I really don't know much about BinaryFormatter, and from Steve's previous answer, it looks like we're using it only in two places (time zones and Out-GridView). If someone could point to the source files affected maybe we could better assess ways to retain compatibility? Another possibility would be to move the required classes in a nuget package separate from the .NET runtime that could be used in PowerShell, like Microsoft.Windows.Compatibility: https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack
|
Current MSFT PowerShell team policy is to release next pwsh in the day next .Net version is released. |
IHMO, integrate System.Text.Json and JsonSerializer, is the first thing to do. Because it's the future and maybe the solution (clijson ?). |
I made a twitter thread about this yesterday, and @jborean93 came up with the simplest possible solution for the BinaryFormatter API obsoletion: https://twitter.com/BoreanJordan/status/1512978332887175170?t=VwkOfkZ-zt69Vj8J0TEJzA&s=19 All we really need is custom code to handle the time zone stuff during the connection sequence. It is benign in nature, and we could make a fix already such that connections work with .NET 6 without re-enabling BinaryFormatter. The real BinaryFormatter APIs are not required, Jordan was able to write custom code for the time zone stuff in his own Python implementation, there aren't that many possible combinations to handle. As for Out-GridView, it is only really used interactively, so I suggest we should update the PowerShell server not to use it unless it is already the case, and not bother about backward compatibility since interactive PowerShell clients can reasonably switch to PowerShell 7. non-interactive use through the PowerShell SDK is what truly matters. Should we create a separate issue to add a proper fallback for the time zone stuff in the current code base, link it to this issue? It would fix at least the current problem. As for other planned deprecated APIs, are there issues opened for all of them, and can someone link them here so we have a good idea of other issues coming up that would break backward compatibility with Windows PowerShell servers? |
A small point - I would not wish to see a "powershell server" edition as noted in the third para. |
Looking at the code a bit further, it seems like for the PowerShell/src/System.Management.Automation/engine/remoting/common/WireDataFormat/EncodeAndDecode.cs Lines 2376 to 2392 in 7cc9c87
The other mentioned usage is with > "a" | Out-GridView
Out-GridView : Out-GridView does not work in a remote session.
At line:1 char:7
+ "a" | Out-GridView
+ ~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Microsoft.Power...GridViewCommand:OutGridViewCommand) [Out-GridView],
NotSupportedException
+ FullyQualifiedErrorId : RemotingNotSupported,Microsoft.PowerShell.Commands.OutGridViewComman I have no idea if there are any other usages of
|
Any idea why it may not work in Azure Functions even if EnableUnsafeBinaryFormatterSerialization is set? |
As far as I know, binary formatter is supposed to be removed in .NET 8. Is this still on the radar? |
The updated plan is for the entirety of the |
Isn't this still a problem because of: dotnet/runtime#98245 |
See also: |
dotnet team has published his BinaryFormatter Obsoletion Strategy (07/23/2020)
There is already an impact for PowerShell 7.1 as ASP.NET projects disable BinaryFormatter by default (but can enable)
See #14032
The next impacts will be :
The documentation about BinaryFormatter security guide is published.
The text was updated successfully, but these errors were encountered: