Hello,
I just want to verify this is legitimate. Our systems are flagging that we have a security update needed. However the Ticket number is #00000 and the notification is SEC-2019-000.
Can someone from Sangoma confirm before we update all systems?
Description is: Add GPG keys to begin to address longstanding keyserver issues
If it helps, I updated 6 servers yesterday and so far so good. It is related to the GPG key poisoning that has been commented on the forum.
It would appear to be related to this commit.
@reraikes this standard/stable-track Framework update solves my “Apply Config” woes.
cc: @tm1000
Great! I still think they should use the only working non poisonable key server and remove sks however.
Edit: I’ve been told that the key server changes will be committed soon which is awesome as that’ll solve future key server poisoning.
Also nice job @qwell!
Are we talking about Framework v15.0.16.38? I’m not seeing any changes in it.
Yep, that’s right.
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.
maybe @mattf or @jsmith question but should I (and others with signed keys) submit our keys to be resigned by the new key?
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.
Hey James,
Yeah, everybody who has a key signed with the old key should go through the process of getting their keys signed with the new key.
Best wishes,
Matt
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.
Matt
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)
Yeah, I think we’re going to update that too - just trying to change one thing at a time since security stuff is tricky and didn’t want to throw a whole bunch of changes out at the same time.
Thanks for your help and good advice on that side of things too!
Matt
Framework 15.0.16.38 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 15.0.16.38 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
);
Once we’ve finished the other changes we have planned (early next week?), the timeouts should be much less of an issue.
Just to be clear…
With the current framework (15.0.16.38), 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.
Care to elaborate on how to include a key in the module tarball?
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.
