Missing legacy provider keys in OpenTofu Registry

[cam72cam]

Hello, I've been going through the organizations who have submitted provider keys in OpenTofu and saw the CiscoDevNet only uploaded their latest key and not any keys for older versions. As people migrate their infrastructure over to OpenTofu they run into issues only having knowledge of the latest provider key for older releases.

Could you submit your legacy public keys at: https://github.com/opentofu/registry/issues/new/choose

Error while installing ciscodevnet/nxos v0.1.0: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.1.1: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.2.0: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.2.1: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.2.2: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.2.3: authentication signature from unknown issuer
...
Error while installing ciscodevnet/nxos v0.4.0: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.4.1: authentication signature from unknown issuer
Error while installing ciscodevnet/nxos v0.4.2: authentication signature from unknown issuer

Thanks!

[danischm]

Hi @cam72cam ,

Thanks for reaching out and bringing this to our attention! There are two issues worth mentioning here:

1. This specific provider was previously published under a different GitHub organization (netascode) and then starting with the 0.5.0 release the repository was moved to the CiscoDevNet organization and signed with a new key. This is correctly reflected in the TF registry, where the previous releases under the old organization are still visible (though hidden) under the old namespace, whereas only the releases after the repo transfer to the new organization are shown in the new namespace. In fact, the key being used to sign releases under the old namespace should already be published in the OpenTofu registry, it is just associated with the old namespace (netascode) and not the current one. I guess the current implementation of the OpenTofu registry does not allow for such mixed namespace/key scenarios. Would it be allowed to associate the same key with two different namespaces as a workaround and is this the suggested way forward?

2. In our case the CiscoDevNet organization/namespace is being used by multiple independent business units to publish content, whereas each business unit is using their own keys. When the OpenTofu registry was born, this was working fine as there was no key yet associated with this namespace and therefore all providers could be used, though none of the signatures could be verified either. Once I started adding the key for the providers I am maintaining to the OpenTofu registry, my providers could be verified successfully but I effectively broke all other providers that did not yet publish their keys in the OpenTofu registry. From what I have seen, OpenTofu now expected to have a respective key for any provider in the CiscoDevNet namespace and if that was not the case it errored out. I guess the assumption here is, that either all keys used in a single organization/namespace are published in the OpenTofu registry or none of them are, but you don't expect to only have a subset of keys available. If that is the case, it would be great if we could support this on the OpenTofu side (maybe displaying a warning that the key is unknown) as we cannot force people on our side to publish their keys in the registry and it would then prevent users from using any of those providers. Let me know if you want me to open an issue in the OpenTofu repo.

[cam72cam]

Let me talk with the OpenTofu core-team about this, we might need to add additional complexity to our registry process for this use case (org level vs repo level keys). In the mean time, should we remove all ciscodevnet keys from the OpenTofu registry?

[danischm]

Ok, thanks for looking into this. And no, let's keep the keys for now and I will also try to encourage other maintainers to publish their keys.