So yeah, the key transition here will be tricky. I've just experimented with signing the "Release" file in an apt repository with two different keys, but that isn't a solution since both keys are required to be present in the apt keyring in order to verify, and even then it's read as invalid/bad.
It appears that on http://download.jitsi.org/nightly, every package is individually signed, rather than the contents of the whole repo (i.e. the Release file I just referred to). I'm not as familiar with this type of setup personally—also not sure how the repo is being generated or how the signing is performed.
Switching the [repository signing key](https://download.jitsi.org/nightly/deb/unstable/archive.key), without users updating their keyring, will obviously result in errors. The user will see the message "The following signatures couldn't be verified because the public key is not available" when they run `apt-get update`. If they attempt to proceed with installation, they'll see `WARNING: The following packages cannot be authenticated!` and a prompt asking them if they want to proceed without verification.
I am not sure if it makes sense to maintain two repositories during the transition period.
If the Jitsi maintainers want to move forward with transitioning to a stronger key, then it's going to hurt a little. Things will be broken for many people for a while. Admins will begin to see these errors and will hopefully realize that action is required. Other projects have done this before, however, so don't be dismayed.
The best thing that can be done is to prepare for this as fully as possible.
1) Publish a key transition statement, announcing the new key, and providing a couple commands that people can be copy&paste into their shell to update it. (i.e. sudo `apt-key adv --recv-keys KEYID`)
2) Give advance notice (at least a month) to the community, users and developers through as many avenues as possible. Make the notice prominent on the website, GitHub etc.
2) Switch the signing key and re-sign all of the packages in the repository.
3) After a little more time has passed, you can revoke the old key or set it to expire, then propagate the expiry or revocation to keyservers.
If you anticipate that a future key transitions may be necessary again, then encouraging people to install a keyring package ([one such example here](https://github.com/freedomofpress/securedrop-keyring)) alongside their software, which updates the signing key in the apt keyring when that package itself gets updated, could make all this less of a headache.
Reply to this email directly or view it on GitHub: