Updating to dotnet 10

[JoeRibeiro]

Support for dotnet v 8.0 ends this year.

But:
Older versions of dotnet permitted untyped object deserialisation
Dotnet v 10.0 no longer allows untyped object deserialisation

I think it is considered a security issue to blindly deserialise without knowing what to expect.
It would potentially be a lot of work if we need to type match each data element in the .cyz file

I first updated the workflow file to use dotnet 10, but somehow the library must have been doing this untyped deserialisation "under the hood" because initially the releases still worked. I suspect it was when I pushed locally built bin/dlls the tool no longer allowed untyped object deserialisation.

[JoeRibeiro]

If I'm interpreting this correctly, the indication is that even when it was dotnet 8, the dlls that were held in bin were likely from an old dotnet version 6 anyway. Or chatgpt is just agreeing with what I'm telling it:

Why your old builds worked (and the new ones don’t)

BinaryFormatter:

In .NET 7, BinaryFormatter.Deserialize is disabled by default but can be re-enabled via an AppContext switch for compatibility.
In .NET 8, BinaryFormatter deserialize is removed (hard failure, no switch).
In .NET 10 (your term for the next LTS after .NET 8/.NET 9), the removal continues—there’s no way to turn it back on.

Untyped deserialization:

What many call “untyped” (e.g., JsonConvert.DeserializeObject(string) returning object, or System.Text.Json.JsonSerializer.Deserialize(string)) still exists, but usage patterns that allow arbitrary type activation (e.g., polymorphic object graphs from attacker-controlled input) are now more constrained. The security position is: prefer typed models or safe dynamic nodes (e.g., JsonDocument, JsonNode) to avoid unsafe type activation chains.

So yes: Your older releases likely bundled DLLs (or were built against a framework/runtime) where BinaryFormatter was still permitted (e.g., .NET 6 or .NET 7 with the AppContext override). When you rebuilt and pushed local bin/dlls targeting .NET 8+, the runtime hard-blocked BinaryFormatter and your tool started to fail.

[LucindaLanoy]

The <EnableUnsafeBinaryFormatterSerialization>true</EnableUnsafeBinaryFormatterSerialization> line was added to Cyz2Json.csproj by Robert when he updated to dotnet 8 so I guess it is right that when the tool was first built in dotnet 7 it wasn't really a problem.

Just to be sure, this untyped deserialisation you are talking about is what you used to get all metadata from JSON ? Or is that unrelated ?

[JoeRibeiro]

Hi Lucinda, yes what you used to get all metadata (possibly all data) from cyz and into JSON. I think the contents of this folder are used by the tool and use dlls built in dotnet 7 CyzFile-v1.1.4.1-net7.0

This is very confusing

[LucindaLanoy]

Ok, I'm trying to figure this out little by little, all those concepts are completely new to me. From what I see BinaryFormatter isn't used anywhere else in the code here, but is in the CyzFile-API especially the Serializing file. I don't know what this file does, but maybe then as you said this is related to the CyzFile-v1.1.4.1-net7.0.

That may mean that even if we wanted to get rid of the binary formatter line, we couldn't because CytoBuoy uses it ? Also from their last commit messages they seem to be preparing a new release soon...

[JoeRibeiro]

You're not alone! This is not familiar ground.

I did try simply deleting the line but it broke the .exe so EnableUnsafeBinaryFormatterSerialization does need to be implicity true.

I think your interpretation is correct "even if we wanted to get rid of the binary formatter line, we couldn't because CytoBuoy uses it".

We can at least conclude that as long as the underlying CyzFile-API continues to depend on dotnet 7, any updates we are making to the cyz2json wrapper are superficial because the dependency hasn't genuinely been removed at a core level.

[LucindaLanoy]

Yes I agree, besides, if i'm not mistaken, we are using the CyzFile v1.1.4.1, which is the latest release, however looking at the tags, they are actually at version 1.6.0.0 (and 50 commits changing 42 files have been made since then...), i don't know how we're supposed to use this version, and if it would break everything...