You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As use of the binary formatter is no longer recommended for exception deserialization because of security risks, the data contract serializer has been updated to include its own serializer for handling exceptions. Service Fabric handled a migration to the new serializer itself and documented the change here.
While Dapr Actor support serialization using both data contract and JSON, the latter bits are relatively new. As the data contract approach has been in broad use since actors were added to Dapr and there may very well be developers that simply cannot migrate to the JSON serialization approach, nor do we collect any data providing insight into usage either way, it seems prudent that we look into supporting the new data contract serialization approach for exceptions so as to mitigate the security risks inherent to this older (and likely more commonly used serialization approach).
Edit: As of writing this, it was unclear whether the Dapr Actors had accommodated the migration from the BinaryFormatter or not for its exception deserialization handling, but I wanted to put a note up to so I would remember to dig into it. I've investigated the matter and this mitigation has already been handled in the past, so there's nothing more necessary to do here.
The text was updated successfully, but these errors were encountered:
I've confirmed that Dapr is not using the BinaryFormatter for any exception serialization purposes today and that our implementation uses the DataContractSerializer for XML object graphics per the advice shared in the latest version of the security guidance as seen in the code here.
Describe the proposal
As use of the binary formatter is no longer recommended for exception deserialization because of security risks, the data contract serializer has been updated to include its own serializer for handling exceptions. Service Fabric handled a migration to the new serializer itself and documented the change here.
While Dapr Actor support serialization using both data contract and JSON, the latter bits are relatively new. As the data contract approach has been in broad use since actors were added to Dapr and there may very well be developers that simply cannot migrate to the JSON serialization approach, nor do we collect any data providing insight into usage either way, it seems prudent that we look into supporting the new data contract serialization approach for exceptions so as to mitigate the security risks inherent to this older (and likely more commonly used serialization approach).
Edit: As of writing this, it was unclear whether the Dapr Actors had accommodated the migration from the
BinaryFormatter
or not for its exception deserialization handling, but I wanted to put a note up to so I would remember to dig into it. I've investigated the matter and this mitigation has already been handled in the past, so there's nothing more necessary to do here.The text was updated successfully, but these errors were encountered: