That argument only flies in you don't also distribute the source code. Since you do, signing the compiled binaries delivered via the install package (and keeping your private key private!) makes perfect sense. It would allow you, and any third party developers targeting the DotNetNuke platform, to easily distinguish 'official' DNN builds from random forks or builds that have had non-coordinated adjustments made to the core.
But the key point is that it *doesn't* prevent folks from rebranding DNN; all they need to do is to download the source package, rebrand to their hearts content, and recompile. It does mean that folks can't rebrand DNN while pretending to others to be the version released by DotNetNuke.
I consider this a security issue to boot; since DNN assemblies are bin deployed, and the bin folder does not typically require Administrator privileges on the host to modify or replace, a deployed copy of DotNetNuke.dll could be replaced with a malicious copy with only exposure of privileges to the bin folder. That sort of thing is preventable with a strong name, as the assembly manifest of referring assemblies will specify the full name and the assembly binder would refuse to load the assembly if the key token was mismatched.
In fact, if DotNetNuke signed the compiled assemblies shipped for the Community Edition, it would *prevent* fracturing in the core - folks like me building modules could strong name their own assemblies, and be sure that I won't be cornered into supporting my module deployed on some random version of DNN.
Admittedly, a "suddenly signed" version of DNN will might blow backwards compatibility for existing modules, since any module's assemblies deployed today *isn't* signed (can't be, if they reference DotNetNuke.dll), but that is no excuse to continue shipping non-signed assemblies. Perhaps an intermediate period where a signed version is offered by default, while a non-signed Install package is made available while folks update their modules?Certainly, a variety of options might exist to mitigate impacts to backward compatibility once the impact is studied and understood.
That the store must today accept and distribute non-signed assemblies because of this frightens me beyond words.
Looking forward to continuing this conversation...