Hi @mlessmann, I'm not very familiar with this topic and I have a few follow-up questions. I've been googling this topic a bit but it seems that advice is different depending on whether we're signing for security (which we are not) or just for strong naming (which we are)...

• It looks like every ScottPlot 4 package uses a different key file, but your suggestion for ScottPlot 5 is for all packages to use the same file. Does this matter?
• Is there any reason not to (or to) sign all packages in ScottPlot 4 and 5 with the same key file?
• Should changing the key files for future releases of ScottPlot 4 be avoided?

I'll probably adapt #3241 so all packages use a single key file, but we can reverse that decision based on your feedback. Thanks so much for bringing my attention to this topic!

* It looks like every ScottPlot 4 package uses a different key file, but your suggestion for ScottPlot 5 is for all packages to use the same file. Does this matter?

No, this does not really matter from a technical standpoint. This is just how signing is usually done when the key is secret, because then the signature provides a proof-of-origin: the user can confirm that the assemblies come from the source they expect and were not tampered with. In the case of ScottPlot and most other open source libraries this does not matter.

* Is there any reason not to (or to) sign all packages in ScottPlot 4 and 5 with the same key file?

Same as above, only if the signature is used for proof-of-origin. The key does not identify the software, but the vendor. For example, all libraries shipped with any version of .NET are signed with the same key (whose private key is secret).

* Should changing the key files for future releases of ScottPlot 4 be avoided?

Yes, even though there is no technical drawback. The only technical issue would be if someone consumes ScottPlot assemblies directly via Assembly Reference instead of NuGet. The Assembly Reference contains the fully qualified name, which contains at the end the public key of the signing key-pair. Changing the key would break those Assembly References.

I'll probably adapt #3241 so all packages use a single key file, but we can reverse that decision based on your feedback. Thanks so much for bringing my attention to this topic!

It's probably fine. I expect most consumers will use NuGet. Also: the check that a signed assembly cannot load unsigned assemblies was remove with .NET Core, so only consumers running .NET Framework are affected. If ScottPlot did not provide .NET Framework assemblies, signing would not he necessary at all.