It's better not to sign an assembly at all than to make the signing key public. Publishing the signing key accomplishes nothing and does have downsides.
A strong-named assembly has as advantage over a non-strong-named assembly that you can be sure that two assemblies with the same strong name are identical. To provide this guarantee, the private key has to be just that: private.
Once the private key leaks, all guarantees a strong-named assembly offers are lost. It effectively becomes as useful as a non-strong-named assembly, but gives a false sense of security.
From an open source perspective, there is nothing wrong with keeping the signing key private. People are still able to fork, and sign the assembly themselves, if they want to do so. End users lose the flexibility to dynamically link against a different version of the assembly if the person who linked against the work used a strong named assembly.
This is intentional. If the software that incorporates the singed assembly is open source as well, the user can change the combination themselves. If it's propriety, this may be a problem for end users, but a problem with the propriety software, not with the open-source parts.
Also, publishing the private key will not help you in this scenario. The publisher of the propriety software could just as well build and sign the dependency with their own private key, which you don't have and can't publish, leaving end users in the same predicament.