So here is the latest.
Pale Moon 26 and below would validate extension signatures according to str8 up CAs in the certificate store. However if the issuer was not known it would allow install of extensions in a valid or tampered with state regardless.
- Signed Known Issuer (Valid XPI) - Allow Install
- Signed Known Issuer (Tampered with XPI) - Block install (Add-on is corrupt)
- Signed Unknown Issuer (Valid and Tampered with XPI) - Allow install
Pale Moon 27 and UXP will ONLY validate extension signatures against a hard coded implementation of AMO's Certificate Authority and ONLY when Add-on Signing is enforced from compile time. Otherwise it is treated as Signed Unknown Issuer
It is noteworthy to add that when Mozilla first started signing Add-ons on AMO for extensions in Pale Moon 26 and older we had to remove the signatures for edits and forks or else get that "add-on is corrupted" error. I do know that Mozilla signed their entire datastore twice. I can only assume the second time was to resign them to match this hardcoded c++ implimented CA that Pale Moon 27 and UXP (and everything at Mozilla) uses now.
What we are likely going to have to for UXP (this kind of complex work likely won't be duplicated/backported to Pale Moon 27) will be the following:
- Rewrite how Add-on Signing is handed to simplify it and return checking to the certificate store
- Figure out exactly what to do about the hard coded AMO CA either get it to check it first then check against the certificate store or get it to spit out something and import it into the certificate store.
This work is going to take a while to accomplish so for now be mindful that Extension Signature Validation Signing is busted.
As for GMForker, your implementation in UXP PR #238 was completely the wrong approach and had implications all over the place. It should be backed out.