What is the GPG issue?

FreePBX Security
21

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:

RHEL 7:

$ sudo -u asterisk gpg --list-keys --with-colons --with-fingerprint
tru::1:1574784962:0:3:1:5
pub:u:4096:1:9F9169F4B33B4659:1398901041:::u:::scESC:
fpr:::::::::2016349F5BC6F49340FCCAF99F9169F4B33B4659:
uid:u::::1462388765::5EA8A2B8DAFF0B5B8270478B22680FBD5AC05C1A::FreePBX Module Signing (This is the master key to sign FreePBX Modules) <[email protected]>:
sub:u:4096:1:06C57CED5C2FE148:1398901041::::::e:
pub:f:4096:1:3DDB2122FE6D84F7:1462348340:::m:::scESC:
fpr:::::::::072410D159E9DA63A459AB203DDB2122FE6D84F7:
uid:f::::1462348340::CFC4B419F5A212E7C9EBD42E413C7CCADB048961::FreePBX Mirror 1 (Module Signing - 2016/2017) <[email protected]>:
sub:f:4096:1:36992456A6869B39:1462348340::::::e:
pub:f:4096:1:86CE877469D2EAD9:1399270402:::m:::scESC:
fpr:::::::::1013D73FECAC918A0A25823986CE877469D2EAD9:
uid:f::::1462348010::6BF5E1714D6EE0E3E64FB65784D8310AD32E2C55::FreePBX Mirror 1 (Module Signing - 2014/2015) <[email protected]>:
sub:f:4096:1:3C355822CCEBF9CB:1399270402::::::e:

RHEL 8:

$ sudo -u asterisk gpg --list-keys --with-colons --with-fingerprint
gpg: WARNING: unsafe permissions on homedir '/var/lib/asterisk/.gnupg'
tru::1:1576798932:1733000076:3:1:5
pub:u:4096:1:9F9169F4B33B4659:1398901041:::u:::scESC::::::23:1576798781:1 http\x3a//162.213.33.9\x3a80:
fpr:::::::::2016349F5BC6F49340FCCAF99F9169F4B33B4659:
uid:u::::1542492566::5EA8A2B8DAFF0B5B8270478B22680FBD5AC05C1A::FreePBX Module Signing (This is the master key to sign FreePBX Modules) <[email protected]>::::::::::0:
sub:u:4096:1:06C57CED5C2FE148:1398901041::::::e::::::23:
fpr:::::::::C5C26167A09555DB29DA4ECF06C57CED5C2FE148:
pub:f:4096:1:3DDB2122FE6D84F7:1462348340:::m:::scESC::::::23::0:
fpr:::::::::072410D159E9DA63A459AB203DDB2122FE6D84F7:
uid:f::::1462348340::CFC4B419F5A212E7C9EBD42E413C7CCADB048961::FreePBX Mirror 1 (Module Signing - 2016/2017) <[email protected]>::::::::::0:
sub:f:4096:1:36992456A6869B39:1462348340::::::e::::::23:
fpr:::::::::EB312FC936875A7BC236DE6A36992456A6869B39:
pub:f:4096:1:86CE877469D2EAD9:1399270402:::m:::scESC::::::23:1576798818:1 http\x3a//37.191.231.105\x3a11371:
fpr:::::::::1013D73FECAC918A0A25823986CE877469D2EAD9:
uid:f::::1462348010::6BF5E1714D6EE0E3E64FB65784D8310AD32E2C55::FreePBX Mirror 1 (Module Signing - 2014/2015) <[email protected]>::::::::::0:
sub:f:4096:1:3C355822CCEBF9CB:1399270402::::::e::::::23:
fpr:::::::::593E5D6A7107C285E698CB563C355822CCEBF9CB:

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.

1 Like
22

You probably are blocked from accessing that server. Additionally Hkps is a special port (11371)

23

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.

gnupg is v2.2.12.

24

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

25

@reraikes is 10 seconds an improvement anyways? Unclear.

26

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.

27

Ron,

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

28

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.

1 Like
29

And you are “merely” a tremendous help, so thank you for jumping in here and getting to the root of the problem and providing the solution.

30

@miken32’s white list pull request is here (you need to login to see the PR): https://git.freepbx.org/projects/FREEPBX/repos/framework/pull-requests/158/overview

It doesn’t have the server patches at this moment but I reached out to @miken32 to maybe add the server we know works to the top of the list.

It now has both the key whitelist and server patches. Thanks @miken32!

One could checkout the repo and generate a diff from release/15.0 there.

31

On FreePBX 15 (up-to-date with EDGE modules enabled) with @miken32’s latest changes incorporated, an ‘fwconsole reload’ takes 3.25 seconds and a GUI reload takes 6.5 seconds (consistent over multiple runs).

[This is not a complaint – it’s simply an observation. This is infinitely better than it’s been since the early betas.]

32

Most likely the additional 3 seconds is taken up by the network request and then the process spawn. Which would be a little slower on raspi. This might be the best you’ll get

33

I doubt it’s the Raspberry Pi’s speed. This is running on a Raspbery Pi 4:

1.7 GHz Quad Core CPU with 4 GB RAM executing from a super fast USB 3 flash drive (200 MB/s).

34

I am seeing a similar issue on CE8 as someone else also pointed out. Using stable and --edge versions.

35

It just struck me that your reply doesn’t make sense to me:

Command line fwconsole reload : 3.25 seconds

GUI reload with module signature checking disabled: 3.25 seconds
GUI reload with module signature checking enabled: 6.5 seconds

Isn’t ‘fwconsole reload’ spawned in both GUI reload cases?

36

I should have clarified.

In 15.0 it spawns fwconsole reload. (See framework/amp_conf/htdocs/admin/functions.inc.php at release/15.0 · FreePBX/framework · GitHub which calls framework/amp_conf/htdocs/admin/libraries/BMO/Framework.class.php at release/15.0 · FreePBX/framework · GitHub)

In 14.0 it doesn’t spawn fwconsole reload directly. It calls retrieve_conf (which fwconsole reload calls as well, in 15 this was all consolidated… see why later)

retrieve_conf was deprecated in 15.0 so that there was 100% consistency between the GUI reload and a CLI reload. (See framework/amp_conf/bin/retrieve_conf at release/15.0 · FreePBX/framework · GitHub)

As I’m no longer in the code daily I only remember the last things I did to fix transient issues on systems that aren’t the FreePBX Distro. Unfortuntately (or fortunately?) these changes only made it into 15.0

37

The fixes haven’t been merged: Log in - FreePBX GIT

38

That’s what I was thought you were saying in your earlier post. However, a GUI reload takes twice as long as a CLI reload if module signature checking is enabled, but they’re equal if module signature checking is disabled. So I’m still confused as to why, if GUI reloads simply spawn fwconsole reloads, that signature checks being enabled doubles the time fwconsole takes to run when it’s spawned by the GUI vs run from the CLI. I understand that module signature checking takes considerable time, but if it’s being done by fwconsole in both cases, something doesn’t compute here. The symptom makes it appear that signature checking is done by the GUI (only) and is not performed by (CLI) fwconsole.

39

Look at the code yourself. I linked to it. You’ll see that the code just spawns fwconsole reload. Again that’s only the case for freepbx 15. Are you only testing this slow down on 15? Is 3.25 seconds really a slow down at this point?

At some point I do want to get another pi and see what the issue is but I think most of these issues seem to be resolved in 15

1 Like
40

Everything I’ve discussed in this topic relates to FreePBX 15 only. That’s why I’m baffled that turning off signature checking reduces GUI reload time from 6.5 to 3.25 seconds, but CLI reload time is always 3.25 seconds. Obviously an extra 3.25 seconds is tolerable, but it’s certainly a mystery.