.net 5.0 BinaryFormatter not supported

You may already know this but in .net 5.0 the BinaryFormatter not supported any more.

I tried to upgrade my web api to .net 5.0 and get the exception ‘BinaryFormatter serialization and deserialization are disabled within this application. See BinaryFormatter security guide | Microsoft Docs for more information.’ when trying to do an Operations.Send(…). It’s not a problem for now I’ll revert back to .net core 3.1 where it works, just thought I’d give you a heads up :slight_smile: .

I found adding the following configuration to my web api project the following will allow the binaryformatter to work:


also you may need to investigate if there are security risks using the BinaryFormatter in some of the places it is used on, doc.Title, userInfo.email and hasing a JObject for instance.


1 Like

Thanks for the headsup! If I remember correctly the BinaryFormatter is only used to save data in the GH files, right?

No it’s used in Utilities.hasString() which is used in the BaseSerializer. I ran into it calling Operation.Send inside my web api

1 Like

Gotcha thanks! We’ll keep it in mind when we upgrade!
Any specific reasons to switch to .net 5? I’m curious :smiley:

1 Like

If i can i try to upgrade the applications I maintain including packages to the latest versions regularly, that way it won’t be a lot of work since the changes are still relatively minor and it will keep the application future proof. I’ve seen applications in the past that waited to long and just got to big to migrate, making it hard to find developers who still can and want to maintain it. Also keeping package up to date with security fixes has been more important since we stopped using the old .net framework where updates where automatic.

I’m also starting a new web project that may need to interact with Speckle. With new projects I usually start on the latest stable version of a framework so I was wondering if it could use .net 5 and it turns out I can with the extra configuration.

Still, the Microsoft warning did get me worried about using the BinaryFormatter. I’m for sure not knowledgeable enough, but I was thinking, since it is used to hash Objects is there now not a way for hackers to insert malicious code into an Object?

1 Like

Nice I agree, and .net 5 has some pretty cool features!

I’ll let @dimitrie reply to you last question as I’m not too familiar with that part. Also, we’re changing some serialization/deserialization routines, not sure if it will affect hashing or not…

Mind if I make this thread public? Might be useful to others too!

Sure no problem

Hi Ferdi! Hope all is well! I’ve had a look originally when doing the first 2.0 core, and it’s safe: the binary formatter is used in a controlled one way only (to get the bytes out of a string to pump inside a hash function).

Deserialisation is again safe, as we control the type discriminator and allow only known, Speckle Base derived types to be instantiated; there’s no danger unless someone writes a malicious kit and you end up using it (at that point… you’ve got bigger problems as you’ve just ran a malicious installer beforehand, or allowed someone to place evil dlls on your computer… I doubt the Speckle Kits folder would be their primary target :smiley: ).

1 Like

Hi Dimitrie,

thanks for you reply. I did a bit of research on this subject, and I now I think I understand better and totally agree with you. The potential security issue with the BinaryFormatter is with de-serialization and the BinaryFormatter.Deserialize() function is never used by Speckle.

I thought there was some “magic” byte/string combination that could start malicious code. Examples of the potential risk on the internet show the result of de-serializing a System.Diagnostics.Process object which, coming as a surprise to me, will actually start the process.

The deserialization done by Newtonsoft that is used by Speckle, as you told me, is not using the $type discriminator (TypeNameHandling = TypeNameHandling.None) but only allows for known kit types to be de serialized, so no problem there as well.

Glad to have learned some more on the subject, which as a developer I probably should have known to begin with :slight_smile: . Once again thanks for clearing that up.