[asterisk@freepbx root]$ gpg --keyserver hkps://keys.openpgp.org --refresh-keys
gpg: refreshing 3 keys from hkps://keys.openpgp.org
gpg: requesting key 69D2EAD9 from hkps server keys.openpgp.org
gpg: requesting key B33B4659 from hkps server keys.openpgp.org
gpg: requesting key FE6D84F7 from hkps server keys.openpgp.org
gpg: key 69D2EAD9: no user ID
gpg: key B33B4659: no user ID
gpg: key FE6D84F7: no user ID
gpg: Total number processed: 3
Someone needs to go and validate they own they keys (Two go to [email protected] and one goes to [email protected]) then they can allow the user IDs of the keys to be published so you don’t get the no user id warning:
You are probably using the keys.openpgp.org keyserver, which has an owner approval system – it will strip all user IDs unless the owner of the corresponding email address has allowed them to be published.
However I believe just changing the servers to keys.openpgp.org would immediately improve performance.
@billsimon it’s only refreshing “C5C26167A09” (that key is not known to FreePBX), However. Go into the GPG class and change the servers out to what I proposed. GPG is different on all systems so yours might actually ignore the fact that FreePBX only wants to update an individual key
Individual keys are requested like so (Notice it’s only processed 2 of the three keys)
[asterisk@freepbx root]$ gpg --keyserver hkps://keys.openpgp.org --refresh-keys 1013D73FECAC918A0A25823986CE877469D2EAD9 2016349F5BC6F49340FCCAF99F9169F4B33B4659
gpg: refreshing 2 keys from hkps://keys.openpgp.org
gpg: requesting key 69D2EAD9 from hkps server keys.openpgp.org
gpg: requesting key B33B4659 from hkps server keys.openpgp.org
gpg: key 69D2EAD9: no user ID
gpg: key B33B4659: no user ID
gpg: Total number processed: 2
You want the fpr:::::::::1013D73FECAC918A0A25823986CE877469D2EAD9: line. That’s the key format that is passed back into refresh-keys. From this list you could also figure out who owns “C5C26167A09”.
The three included FreepBX keys are as follows:
1013D73FECAC918A0A25823986CE877469D2EAD9
2016349F5BC6F49340FCCAF99F9169F4B33B4659
072410D159E9DA63A459AB203DDB2122FE6D84F7
Additionally (since you do ‘light’ programing) I would go into the GPG class and make sure this line is only sending non-local keys
before line 605 you can do dbug($refreshKeys) and then run fwconsole dbug and in another window do your reloading. Make sure the keys listed there don’t include the ones in the list below:
Updating the keyservers list in GPG.class.php allows the reload to proceed. It reaches out to the keyserver every time, as you figured, because of the extra key in the list. I don’t know how to determine where that is from.
You should check the command itself and the code because it’s returning FreePBX fingerprints in a different format (that GPG still recognizes but FreePBX doesn’t)
I looked at that ticket and as suspected it’s something with ubuntu/debian.
[asterisk@freepbx BMO]$ gpg --keyserver hkps://keys.openpgp.org --refresh-keys --refresh-keys 593E5D6A7107C285E698CB563C355822CCEBF9CB C5C26167A09555DB29DA4ECF06C57CED5C2FE148 EB312FC936875A7BC236DE6A36992456A6869B39
gpg: refreshing 3 keys from hkps://keys.openpgp.org
gpg: requesting key 69D2EAD9 from hkps server keys.openpgp.org
gpg: requesting key B33B4659 from hkps server keys.openpgp.org
gpg: requesting key FE6D84F7 from hkps server keys.openpgp.org
gpg: key 69D2EAD9: no user ID
gpg: key B33B4659: no user ID
gpg: key FE6D84F7: no user ID
gpg: Total number processed: 3
The keys in the returned response are the freepbx keys. However they are in a different format than how they show up on CentOS. In fact it looks like Debian/Ubuntu return additional fingerprints for each single key (so each key has two fingerprints) This means on ubuntu systems the keys are being returned in a different format and thus aren’t able to be removed from the array. Thus they are passed back to the key server to be checked when they shouldn’t be.
It’d be an exercise for someone to figure out why fpr::::::::: gives the right fingerprint back on CentOS systems but not on other systems. Additionally someone should add a protected property in GPG to not check these fingerprints
I have this exact same problem on Debian 9 and 10 with Fpbx 15. I tried the fix posted by tm1000 of updating GPG.class.php L52, which is exactly the same as Fpbx 14, but the GUI still hangs.
Running sudo -u asterisk gpg --keyserver hkps://keys.openpgp.org --refresh-keys also hangs
I doubt it. I get exactly the same symptoms. Hangs on GUI but not fwconsole reload. However, I am using Fbpx v15 and PHP v7.3 which might be causing additional things.
These are completely fresh installs on D9 and D10. Same procedures that have worked in the past up until recently. I think that refresh key command was working a few days ago. Not sure though. I could have messed something up while troubleshooting this as well. But I am most certainly seeing the same issue as you.
Having similar problems on a test system running on CentOS 8. It looks like the output of gnupg 2.2.9 (RHEL 8) is different from gnupg 2.0.22 (RHEL 7). The newer version, which I’d guess is what the problem Ubuntu/Debian users are using, outputs the info on the subkeys as well:
Note the additional fpr lines which cause lookups. These subkeys are not registered anywhere (should they be?) and cause the timeouts.
Edit: just noticed these are the same keys Andrew pointed out in his post above. If they aren’t going to be registered at the keyservers then I agree they should be whitelisted in the module.
I’m now patching GPG.class.php to replace all existing key servers with just hkp://keys.openpgp.org and GUI reload times are 10 seconds whereas fwconsole reload time is 3 seconds.
If you are patching that already why don’t you just patch it further with whitelisting like bill, Mike and I mentioned above. Then it wouldn’t even launch gpg
I have absolutely no knowledge of the gpg in FreePBX, so the whitelisting you, Bill, and Mike mentioned is meaningless to me. I’m simply doing whatever I can to alleviate a problem that I raised with you earlier this year (‘works for me’ was your immediate response) and that has been sitting on an open ticket for 3 months now ([FREEPBX-20559] 'Apply Config' Excruciatingly Slow (or Fails) - Sangoma Issue Tracker). If it’s so easy to fix , why the hell doesn’t someone at Sangoma attend to it? I’d rather not be patching anything.
10 seconds is a whole lot better than it hanging forever (see the above ticket).
I’ve never understood why GUI reloads go through all this gpg business but ‘fwconsole reload’ doesn’t.
The ticket you opened earlier this year was probably closed as “works for me” because as stated several times work is based off of how bugs work in the officially supported distro. Which this isn’t an issue there as stated why previously in this ticket.
Also the ticket you opened up three months ago. No idea why it hasnt been worked on. I haven’t worked for Sangoma since May.
@billsimon started this thread. I’m merely here to help. However your responses really make me feel unwelcome. I dunno. Maybe it’s just me.
No idea. Again I don’t work for Sangoma. However @miken32 took the ideas here and submitted a PR doing exactly what we stated.
The GUI reload actually just spawns fwconsole reload in 15. So I’m not sure why you’d be experiencing that either
To answer why hasn’t it been fixed yet? While FreePBX is ostensibly open source, you’re unlikely to get much traction on fixes for problems that occur off Sangoma’s distro. I run 80 hosted PBXs on various RHEL forks, and figured out a long time ago that if I don’t submit my own patches I’ll just get “WFM” as a response to problems or feature requests that don’t fit in with how Sangoma wants their product to be used. Not a complaint – I realize they’re a company trying to make money off this thing – just an observation.