There are more changes coming soon that are going to adjust which keyservers are used for downloading unknown public keys and updating existing keys when needed. Those changes should resolve the biggest issues people have been seeing.
The simplest way is for developers to simply bundle their signed keys into their package. It doesn’t require any lookup, and is provably secure, including offline. This is poorly documented, unfortunately, which is my fault.
The other thing is that FreePBX shouldn’t be using the SKS keyservers at all - simply change to use the new keyserver (the name of which I have temporarily forgotten, blame all the booze), which requires email authentication before allowing updates. That immediately, and trivially, solves the problem.
The FreePBX primary key should be read only ANYWAY. There is nothing that can prove it is more original than is already - or the new one - as it’s hard-coded in numerous places.
As mentioned by others, it’s legitimate. There have been a lot of complaints caused the old freepbx module signing key being poisoned on public keyservers so at the end of the year we’re adding support for new signing keys that this framework update covers. We pushed it out as security released so that it would get to as many systems as possible.
FYI: This new key can be just as easily poisoned as the old key since the poisoning takes place on the GPG Ring of Trust. This is why the server should be set to only hkps://keys.openpgp.org. The longer FreePBX keeps referencing SKS (which is broken) the sooner you’ll have someone poisoning the new key again. In fact the old key is perfectly fine on hkps://keys.openpgp.org since it was scrubbed and cleaned of all poisoning. (and on that note I don’t think issuing a new key was even needed since it can be poisoned just as easily as the old key)
The new key. Or any key. Will always been vulnerable to poisoning on “bad” networks. Like SKS (and actually ALL networks freepbx currently uses)
Framework 184.108.40.206 does not correct GUI reloads from taking forever for me. @miken32’s original changes did (ignoring the 6.5 second vs 3.25 second mystery).
Unless the list of well-known keyservers is changed to the following, GUI reloads still take forever with Framework 220.127.116.11 unless module signature checking is disabled:
// List of well-known keyservers.
private $keyservers = array(
“hkps://keys.openpgp.org”, // Unpoisoned keyserver
“hkps://keyserver.ubuntu.com:443”, // This is in case port 11371 is blocked outbound
“pool.sks-keyservers.net” // Last resort
With the current framework (18.104.22.168), GUI reloads are 3.25 seconds with signature checking disabled. With signature checking enabled, GUI reloads NEVER complete. CLI reloads are 3.25 seconds under all circumstances.
You’re experiencing problems with a Debian/Ubuntu system which is not going to be fixed unless a) subkeys are added to the whitelist as in my pull request or b) the subkeys are updated on the keyservers. Those lookups are always going to timeout otherwise, regardless of which servers are configured. This is due to the changed output format of the newer version of gnupg, and the fact that the subkeys aren’t currently listed in the keyservers.