wpf
wpf copied to clipboard
dotnet
Replace binary formatter
Description
The Binary Formatter was initially developed prior to the comprehensive understanding of deserialization vulnerabilities as a significant threat. As a result, the code doesn’t follow the modern practices. Due to the security vulnerability Binary formatter is considered obsolete. In .NET 9.0, the entire Binary formatter infrastructure will be removed from the product.
Binary Reader and Writer can be used to read and write the primitive data types into binary data and does not have any security vulnerability. We are creating a safe handle ‘BinaryFormatWriter’ which handles all primitives, Enums, strings, arrays and lists of primitives, and other items before falling into the process of serialization/deserialization. For serialization/deserialization we will use Binary writer. This approach will allow us to disable Binary formatter for the primitive and some other cases.
To convert the object to binary data we call TryWriteFrameworkObject with a memory stream and the object.
BinaryFormattedObject class is added to parse a binary formatted object from a stream. It used Binary reader to read from a stream.
This solution is similar as in WinForms
PR: https://github.com/dotnet/winforms/pull/9088
CC
@JeremyKuhne @lonitra
Customer Impact
In .NET 9.0, the entire Binary formatter infrastructure will be removed from the product, and it will become obsolete. It has additional benefits of making applications more friendly to linker trimming.
Regression
N/A
Testing
Internal testing done.
Risk
Low There might be a few instances where this solution won't be effective. Currently, this PR includes all the primitive types and few more data types. The plan is to handle additional cases as feedback comes in.
Microsoft Reviewers: Open in CodeFlow
To be clear, BinaryFormatter APIs will never be removed. Setting a switch in .NET 9 to enable the BinaryFormatter will likely become required for WPF and WinForms (as it is already for all other .NET projects in .NET 8). Enabling the functionality will possibly require additional steps in the future, but the surface area should always be there.
To be clear,
BinaryFormatterAPIs will never be removed.
Then it is my mistake for misunderstanding the “Customer Impact” section of the OP. Sorry to bother you.
To be clear, BinaryFormatter APIs will never be removed.
While the APIs may never be removed, according to BinaryFormatter infrastructure removed from .NET (.NET 9), "The internal BinaryFormatter implementation will no longer exist in .NET in any form and cannot be reenabled through any compat switch."
To be clear, BinaryFormatter APIs will never be removed.
While the APIs may never be removed, according to BinaryFormatter infrastructure removed from .NET (.NET 9), "The internal BinaryFormatter implementation will no longer exist in .NET in any form and cannot be reenabled through any compat switch."
The hope is to make you jump through more hoops by putting the actual implementation in another package, but there is no way the API will be removed or there will be no way to re-enable for quite some time. It is fundamental to many existing applications, particularly WinForms.
To be clear, one should avoid the BinaryFormatter if at all possible, but as a platform we will not completely abandon existing users of this functionality.
![azure-pipelines[bot] avatar](https://avatars.githubusercontent.com/in/9426?v=4 "Published by a pub.dev verified publisher"){kind=small}
I wonder if this change has changed the binary format. In other word, does this change maintain compatibility with the old content?
To be clear,
BinaryFormatterAPIs will never be removed. Setting a switch in .NET 9 to enable theBinaryFormatterwill likely become required for WPF and WinForms
Looks like this is not the case. The switch won't work and any usage will throw an exception, see https://github.com/dotnet/runtime/issues/98245 so either:
a) WPF stays on .NET 8 forever b) WPF subscribes to the nuget package c) WPF replaces BinaryFormatter. Any breaking change has to be accepted then (since its a new major version of .NET this isn't as bad as it sounds)
@Symbai the API surface will still be there, you'll just need the package for the APIs to work.
@Symbai the API surface will still be there, you'll just need the package for the APIs to work.
Which is exactly what I said for option B.
What is the current state of it? I'm testing .Net 9 Preview 4 with my .Net 6 control which has serializable objects and uses them for drag&drop. Apparently, DataObject class still uses binary serialization and it only fails on attempt to deserialize with exception about not supported binary formatter. What are your plans about this, should I try to fix it from my side and serialize object manually before creating DataObject or you will try to use other formatter from your side? Is it time to post you bugs about this? I haven't checked yet, but suppose I'll have the same question about clipboard. We want our controls to be compatible with .Net 9 by November, so I need to know more details in advance.
Note that the runtime is adding a public type that is based, in part, on the code you've copied from WinForms. NrbfDecoder will read binary format records.
https://github.com/dotnet/runtime/pull/103232
Our plan is to move the WinForms code to use this in the next preview.
Fyi: @lonitra and @Tanya-Solyanik are working on adding additional APIs to DataObject in WinForms to allow for safer binary format usage.