Pale Moon forum

ianas wrote:this is relativly new as I don't remember these warnings a few days ago

See #238.

ianas wrote:disabling then re-enabling the affected addons does not help

You must uninstall and reinstall (not disabling and re-enabling). For Basilisk < 2017.12.28 (from the source code < 2017.12.19).

This patch needs to be improved upon - according to the logic already mentioned above.

What does this have to do with the discussion at hand because what you quoted and what you linked has no clear connection.

IMHO - STR:

Basilisk < 2017.12.28 (2017.12.18-):
- Create a new profile
- Install unsigned extension (Press the button "Restart now")
- This warning will not appear

Basilisk >= 2017.12.28 (e.g. 2018.01.05):
- Create a new profile
- Install unsigned extension (Press the button "Restart now")
- This warning appears

Ok.. I still don't know the relevance of this to the issue of Signed Add-ons with Invalidated Signatures being allowed to install.

Are you saying you compromised that validation when you "fixed" an issue relating to id-less webextensions being blocked from installation? Does this have to do with unsigned extensions having warnings? What. If you did do something that compromised invalid signatures being blocked then it must be reversed at once. When it comes down to it.. Proper application extensions trump webextensions every time and signature verification and trust must trump everything.

Please, for crying out loud, use words in sentences that explain things in detail. This is serious.

Unfortunatelly, I do not understand. What should be the goal of any change?

Again, all three variants (+ settings):

xpinstall.signatures.required = false (default)

Basilisk (before #238):

An addon - unsigned:
- It's going to install
- This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") will not appear

An addon - signed - but this signature is invalid:
- It's going to install
- This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") will not appear

An addon - signed - this signature is valid:
- It's going to install
- This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") will not appear

xpinstall.signatures.required = true

Basilisk (before #238):

An addon - unsigned:
- It's going to install
- This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") will not appear

An addon - signed - but this signature is invalid:
- It's going to install
- This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") will not appear

An addon - signed - this signature is valid:
- It's going to install
- This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") will not appear

xpinstall.signatures.required = false (default)

Basilisk (after #238 - i.e. 2018.01.05):

An addon - unsigned:
- It's going to install
- This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") appears

An addon - signed - but this signature is invalid:
- It's going to install
- This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") appears

An addon - signed - this signature is valid:
- It's going to install
- This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") will not appear

xpinstall.signatures.required = true

Basilisk (after #238 - i.e. 2018.01.05):

An addon - unsigned:
- It cannot be installed ("This add-on could not be installed because it has not been verified.") / - This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") appears ?

An addon - signed - but this signature is invalid:
- It cannot be installed ("This add-on could not be installed because it appears to be corrupt.") / - This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") appears ?

An addon - signed - this signature is valid:
- It's going to install
- This warning ("[addon name] could not be verified for use in [application]. Proceed with caution.") will not appear

---

If you see a bug somewhere... Please edit it according to your preferences. IMHO: The red text is important (at least I don't see a bug there - the green text is considered).
But that it was unintentional for #238...

"The warning above" Above what? What warning? The "X is not verified for use in Y" warning in the add-ons manager OR the Doorhanger error about it being corrupt (which in Tycho shows for edited signed extensions).

USE SENTENCES THAT EXPLAIN THINGS IN DETAIL. Language barriers aside.. Do you not know how to speak like a person?

I can't read this crap with green and red and highlights.. Also, what does that pref have to do with anything.. Whatever that preference is set to by default should be your testing criteria.. Anyway.. I am going to test this personally because I need to KNOW and you are not telling me.

The text (warning) added to the post.

New Tobin Paradigm wrote:Do you not know how to speak like a person?

No. I'm a robot (probably). Artificial Intelligence. I'm sorry, Artificial Non-Intelligence, of course.

New Tobin Paradigm wrote:I can't read this crap with green and red and highlights...

So now I really do not know what else to do...

New Tobin Paradigm wrote:Anyway.. I am going to test this personally

Yes, that's best.

New Tobin Paradigm wrote:Yeah, it WILL check for signatures and like Pale Moon it SHOULD verify signatures if existent. [..]

Obviously, the best solution is to reinstate and fix the behavior to match what we have now on Pale Moon. No signature should install (if not strictly enforcing -- which we don't enable) and Signature should be checked for validity and integrity if it exists. If it is not valid it should be rejected and installation blocked and if somehow slid in by some means should be disabled.

I'm not sure you are right about how Pale Moon handles signed extensions. Currently it treats all signatures from Mozilla as "invalid because the certificate used to sign this file has an unrecognized issuer", but allows to install regardless of this verification error. And although I have never seen any extensions signed not by Mozilla in the wild, I doubt that Pale Moon would refuse to install such add-ons even if the signature is broken.

Assuming you are correct.. This is totally the wrong behavior.

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 as above.

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.

Stay tuned...

New Tobin Paradigm wrote:ONLY when Add-on Signing is enforced from compile time

So the user can not choose enforce and do not enforce signatures...

At least please you delete the "xpinstall.signatures.required" option, if it makes no sense (and it did not work right from the start).

As a platform.. It would be important to keep the preference. Also, if you bothered reading anything I said before you blind-sighted me with your thing.. I said there is a difference between allowing unsigned add-ons and what should be done with those that ARE signed..

I feel it is necessary to iterate something just in case anyone is thinking bad things might happen and come out of this thread and the exploration into the issue..

Pale Moon and Basilisk have zero plans to enforce any kind of strict signing or restrict unsigned add-ons.. Nor will the Add-ons Site be involved in signing extensions on behalf of Add-on Developers. This whole thing is to find out what is going on with the source code and resolve issues for add-ons that ARE signed but whose integrity is not being properly checked. Not so much for AMO.. That ship is sailing on May 8th. Though, a lot of people are still going to have Mozilla Signed add-ons for a long time.

Please see my previous post where I discuss the difference between allowing unsigned add-ons and what should be done with those that are signed that makes the comparison with http/https.

If you have any further questions please pose them.. I will do my best to answer.

For the record, Mozilla broke add-on signing in the "normal" way when they changed from reliance on NSS to a built-in certDB with only Mozilla certificates. Ever since then, invalidly-signed extensions (including tampered ones) are tossed on the heap "unsigned" because from Mozilla's perspective, that is all that mattered (signed = signed by Mozilla). I opened a bug for this incorrect behavior but was unheard. This was back in the Firefox 34-38 era; so yes it's been broken for a long time.

Since "unsigned" is perfectly fine for us, I'll remove the warning thrown when an "unsigned" (meaning either unsigned or invalid or modified or non-mozilla signed) extension is found when not required (by pref). The pref will still work and block (for the time being, anyway) and should be read as "require Mozilla signing".

Will this mean no more Author not verified? Or, is that different from signing?

SpockMan02 wrote:Will this mean no more Author not verified? Or, is that different from signing?

It's all related.

Moonchild wrote:Mozilla broke add-on signing in the "normal" way

This is not entirely true, see the comment on Issue #277.

With release of Basilisk-2018-02-02, the issue of warnings for unsigned (or signed-but-edited) add-ons appears solved.

installing such add-ons no longer produces a warning in the add-ons manager.

For any add-ons that already had these warnings, reinstalling them made the warning disappear.

coffeebreak wrote:With release of Basilisk-2018-02-02, the issue of warnings for unsigned (or signed-but-edited) add-ons appears solved. For any add-ons that already had these warnings, reinstalling them made the warning disappear.

In my case, I didn't even have to re-install. I just switched the value extensions.blocklist.enabled back to true, and everything was hunky-dory! Thanks for fixing this!