Skip to content
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

Removing or annotating Serializable attribute on winforms classes #1425

Merged
merged 5 commits into from
Aug 3, 2019

Conversation

Tanya-Solyanik
Copy link
Member

@Tanya-Solyanik Tanya-Solyanik commented Jul 19, 2019

Fixes #889
Fixes #890
Fixes #1251

Proposed changes

Removed SerializableAttribute from types that don't have known binary serialization scenarios and annotated types that are staying serializable.
Lists of types are in #889

Customer Impact

This change reduces security risk associated with binary serialization

Regression?

no

Risk

high - might have to add attributes again if legitimate serialization scenarios exist

Test methodology

Manual verification and additional testing of resx serialization

Microsoft Reviewers: Open in CodeFlow

@Tanya-Solyanik Tanya-Solyanik requested a review from a team as a code owner July 19, 2019 03:43
Copy link
Member

@RussKie RussKie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍
Few minor comments

@RussKie RussKie changed the title [WIP] Removeing or annotating Serializable attribute on winforms classse [WIP] Removing or annotating Serializable attribute on winforms classse Jul 19, 2019
@Tanya-Solyanik Tanya-Solyanik force-pushed the dev/tanyaso/serializable branch 2 times, most recently from b0b8739 to 1e4647f Compare July 20, 2019 00:18
@zsd4yr zsd4yr changed the title [WIP] Removing or annotating Serializable attribute on winforms classse [WIP] Removing or annotating Serializable attribute on winforms classes Jul 22, 2019
Copy link
Contributor

@zsd4yr zsd4yr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pending more tests, LGTM

@Tanya-Solyanik Tanya-Solyanik force-pushed the dev/tanyaso/serializable branch 3 times, most recently from 46f1f71 to c2ef8e4 Compare July 23, 2019 20:07
@codecov
Copy link

codecov bot commented Jul 23, 2019

Codecov Report

Merging #1425 into master will increase coverage by 0.11197%.
The diff coverage is 70.65217%.

@@                 Coverage Diff                 @@
##              master       #1425         +/-   ##
===================================================
+ Coverage   25.64901%   25.76099%   +0.11198%     
===================================================
  Files            786         786                 
  Lines         268256      268169         -87     
  Branches       37978       37968         -10     
===================================================
+ Hits           68805       69083        +278     
+ Misses        194557      194164        -393     
- Partials        4894        4922         +28
Flag Coverage Δ
#Debug 25.76099% <70.65217%> (+0.11197%) ⬆️
#production 25.76099% <70.65217%> (+0.11197%) ⬆️
#test 100% <ø> (ø) ⬆️

@Tanya-Solyanik Tanya-Solyanik changed the title [WIP] Removing or annotating Serializable attribute on winforms classes Removing or annotating Serializable attribute on winforms classes Jul 23, 2019
@zsd4yr
Copy link
Contributor

zsd4yr commented Jul 23, 2019

LGTM but you should investigate this test failure. Looks like something in the debug skew for System.ComponentModel.Design.DesignerHost.AddToContainerPostProcess

{
public static class BinarySerialization
{
public static void EnsureSerializableAttribute(Assembly assemblyUnderTest, Dictionary<string, bool> serializableTypes)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than test by checking for attribute, just ensure you have a test-case that actually serializes every type. Could be useful for a negative case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't too bad after further consideration, just make sure you have actual test cases.

Copy link
Member Author

@Tanya-Solyanik Tanya-Solyanik Jul 24, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I simplified these tests to focus on blocking addition of serializable types.

{
public static class BinarySerialization
{
public static void EnsureSerializableAttribute(Assembly assemblyUnderTest, Dictionary<string, bool> serializableTypes)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't too bad after further consideration, just make sure you have actual test cases.

public sealed class ExceptionCollection : Exception
{
private readonly ArrayList _exceptions;
private const string SerializationKey = "exceptions";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than introducing a constant here, consider reverting the field name to exceptions then using nameof(exceptions) in the constructor / GetObjectData. Also consider adding // Do not rename (binary serialization). It'll be helpful if you express the serialization constraint consistently across the repo so that its easier for code-reviewers to catch the cases where folks may introduce new fields, or rename, and break serialization.

Copy link
Member Author

@Tanya-Solyanik Tanya-Solyanik Jul 24, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change is not as uniform as I had hoped because usually we have custom serialization code and do not serialize private fields, but rather pre-process data that we want to serialize or serialize public properties, Or serialize public property under a different name - for example Tag property is serialized as UserData.
I applied your suggestion only in cases where we are serializing private properties.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Well one benefit of always having custom implementations of these methods is that its much harder to break compatibility accidentally.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, the compatibility goal is achieved, but the source is not "intuitive" - it's impossible to deduce type members from the serialized data. But this is not the goal of this work item.

Copy link
Member

@RussKie RussKie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few little nits.
One question whether it is worth adding tests to check there are serialisable types other than those that we expect.

@RussKie
Copy link
Member

RussKie commented Jul 24, 2019

Btw happy to have it merged as-is to take it into P8, we can do further tweaks as a follow up.

@Tanya-Solyanik Tanya-Solyanik changed the title Removing or annotating Serializable attribute on winforms classes [WIP] Removing or annotating Serializable attribute on winforms classes Jul 24, 2019
@Tanya-Solyanik
Copy link
Member Author

Tanya-Solyanik commented Jul 24, 2019

Btw happy to have it merged as-is to take it into P8, we can do further tweaks as a follow up.

@RussKie - thanks! I would like to remove this attribute from 3 more types, need to double check that I am not missing some scenarios . And then will send to Olina for testing. Thus I made this [WIP] again

@RussKie RussKie added the 📭 waiting-author-feedback The team requires more information from the author label Jul 29, 2019
@RussKie

This comment has been minimized.

@ghost ghost removed the 📭 waiting-author-feedback The team requires more information from the author label Jul 31, 2019
@ghost ghost added this to the 3.0.0-Preview9 milestone Jul 31, 2019
@Tanya-Solyanik
Copy link
Member Author

For all types that have moved from different assemblies than desktop you should add TypeForwardedFrom attribute to the type. I believe this applies to System.Windows.Forms.Design & System.Windows.Forms.Design.Editors. This impacts serialization from core, consumed in desktop.

@ericstj - we don't have any serializable types in S.W.F.Editors. In System.Windows.Forms.Design we have a single serializable type (CodeDomSerializationStore) This type is used in Copy/Paste scenarios in VisualStudio. We are likely to use BinarySerialization on this type in the CoreDesigner as well, but we don't anticipate scenarios where we exchange types between the Core and .Net. Primarily because even if we are able to deserialize property store and type information of a control from one FX on another FX, we will not be able to discover the "destination" framework assembly. This type will be used to copy/paste controls between 2 Core containers only.

@Tanya-Solyanik
Copy link
Member Author

The only issue that concerns me is that currently the tests deserialize .NET Framework blobs on Core but never the other way around, means the tests never run on .NET Framework. Tanya will create a follow-up issue for that.

@ViktorHofer - thank you for the review, here is the issue #1549

@Tanya-Solyanik Tanya-Solyanik changed the title [WIP] Removing or annotating Serializable attribute on winforms classes Removing or annotating Serializable attribute on winforms classes Aug 2, 2019
@Tanya-Solyanik Tanya-Solyanik force-pushed the dev/tanyaso/serializable branch 2 times, most recently from 67396e1 to 5b03e70 Compare August 2, 2019 18:30
@RussKie RussKie added the 📖 documentation: breaking A change in behavior that could be breaking for applications. Needs to be documented. label Aug 2, 2019
@Tanya-Solyanik Tanya-Solyanik merged commit 44b5076 into master Aug 3, 2019
@Tanya-Solyanik Tanya-Solyanik deleted the dev/tanyaso/serializable branch August 9, 2019 16:18
@kpreisser kpreisser mentioned this pull request Aug 25, 2019
3 tasks
@RussKie
Copy link
Member

RussKie commented Sep 3, 2019

docs - dotnet/docs#14175

@RussKie
Copy link
Member

RussKie commented Sep 16, 2019

@Tanya-Solyanik reviewing #1237 I spotted that we still have serialisation-related decorations and logic in ResXFileRef:

image

Should OptionalField attribute and OnDeserializing and OnDeserialized methods be gone?

@Tanya-Solyanik
Copy link
Member Author

Tanya-Solyanik commented Sep 16, 2019

yes, thank you, good point!

removed here: #1921

@ghost ghost locked as resolved and limited conversation to collaborators Feb 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
📖 documentation: breaking A change in behavior that could be breaking for applications. Needs to be documented.
Projects
None yet
7 participants