1273298 - Add-ons are disabled on trunk builds, claiming they could not be verified to work with SeaMonkey

Status: VERIFIED FIXED

(SeaMonkey :: General, defect)

Description

[rsx11m]

Installing SeaMonkey trunk and running it with a new profile, all extensions which it ships with (including Lightning) are disabled, listed in the Add-ons Manager as "... could not be verified for use in SeaMonkey and has been disabled." Lightning works fine after manually enabling it.

This is a recent regression, aurora and beta builds are fine, seen independently on Linux and Mac OSX nightlies. I'm filing this for SeaMonkey first in case something screwed up with disabling the signing requirement for those builds.

Comment 1

[Adrian Kalla [:adriank]]

Imho, this is an INVALID bug (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1159499#c1 ).

Comment 2

[rsx11m]

Thanks, guess I didn't look into the Add-ons Manager on trunk for a long time (just now after Lightning was included in the default build and installation).

Note that this applies to *all* shipped extensions, not just Lightning. Does the difference between trunk and others for /extensions/ vs. /distribution/extensions/ apply for those too?

Comment 3

[Adrian Kalla [:adriank]]

(In reply to rsx11m from comment #2)
> Note that this applies to *all* shipped extensions, not just Lightning. Does
> the difference between trunk and others for /extensions/ vs.
> /distribution/extensions/ apply for those too?

It's logical to assume that it does.

Comment 4

[rsx11m]

True but not necessarily. Looking at http://hg.mozilla.org/comm-central/file/f32ca0e1adf2/suite/installer/package-manifest.in Lightning is the only extension explicitly testing NIGHTLY_BUILD to decide installation in /extensions/, whereas ChatZilla and DOM Inspector decide on !MOZ_OMNIJAR instead. Thus, if NIGHTLY_BUILD implies !MOZ_OMNIJAR, that would make them equivalent.

Comment 5

[Frank-Rainer Grahl (:frg)]

Attachment: Capture.PNG

I am not seeing this on a brand new Windows build and brand new profile. Maybe a bug in core code which has been fixed?

Comment 6

[rsx11m]

I'm still seeing this with a current trunk tinderbox build and a new profile, thus not fixed.

Comment 7

[rsx11m]

(at least on Windows)

Comment 8

[rsx11m]

(while no Windows tinderbox builds exist atm - I meant Linux of course, grrrr)

Comment 9

[rsx11m]

In my own SeaMonkey 2.47a1 build, I do no longer get the warning but Lightning remains disabled with a new profile until I explicitly enable it in the Add-ons Manager.

Comment 10

[Frank-Rainer Grahl (:frg)]

Attachment: 1273298-signing.patch

I think addon signing might not be properly disabled in the build configs. 

Couldn't this be added to confvars.sh?

Comment 11

[Edmund Wong (:ewong)]

Comment on attachment 8767499 [details] [diff] [review]
1273298-signing.patch

Review of attachment 8767499 [details] [diff] [review]:
-----------------------------------------------------------------

Aside for that minor nit, everything looks good.  r+ from me when you've skipped the macosx32 directory(I seemed to have forgotten to push that patch from bug 1061357.. I guess I need to update that patch once you've pushed this).

::: suite/config/mozconfigs/macosx32/debug
@@ +2,5 @@
>  
> +# Disable checking that add-ons are signed by the trusted root
> +MOZ_ADDON_SIGNING=0
> +# Disable enforcing that add-ons are signed by the trusted root
> +MOZ_REQUIRE_SIGNING=0

Frank, you don't need to change this file or anything within macosx32/*.  (In fact, this directory was supposed to be removed
earlier. (I think I had a patch waiting for review awhile back.)

Comment 12

[Edmund Wong (:ewong)]

(In reply to Edmund Wong (:ewong) from comment #11)
> Comment on attachment 8767499 [details] [diff] [review]
> 1273298-signing.patch
> 
> Review of attachment 8767499 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Aside for that minor nit, everything looks good.  r+ from me when you've
> skipped the macosx32 directory(I seemed to have forgotten to push that patch
> from bug 1061357.. I guess I need to update that patch once you've pushed
> this).
> 
> ::: suite/config/mozconfigs/macosx32/debug
> @@ +2,5 @@
> >  
> > +# Disable checking that add-ons are signed by the trusted root
> > +MOZ_ADDON_SIGNING=0
> > +# Disable enforcing that add-ons are signed by the trusted root
> > +MOZ_REQUIRE_SIGNING=0
> 
> Frank, you don't need to change this file or anything within macosx32/*. 
> (In fact, this directory was supposed to be removed
> earlier. (I think I had a patch waiting for review awhile back.)

Patch has been pushed, so just update your tree and push the updated
patch (without the mention of macosx32).

Comment 13

[Frank-Rainer Grahl (:frg)]

Patch pushed without the osx32. Thought so that it was obsolete but youe never know...

https://hg.mozilla.org/comm-central/rev/09dbbf8ea508

What about the branches? Should we wait till c-c builds again an and verifiy first that it solves the problem?

Comment 14

[Frank-Rainer Grahl (:frg)]

Attachment: 1273298-xpisigning.patch

Firefox sets this to true per default. I am sure we do not want this for the forseeable future. Currently the setting is picked up from /modules/libpref/init/all.js where it is still false but this might change in the future.

Comment 15

[Frank-Rainer Grahl (:frg)]

Attachment: 1273298-signing-ca.patch

patch for comm-aurora

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: Incorrect / incomplete build options.
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): none
String changes made by this patch: none

Comment 16

[Frank-Rainer Grahl (:frg)]

Attachment: 1273298-signing-cb.patch

patch for comm-beta

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: Incorrect / incomplete build options.
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): none
String changes made by this patch: none

Comment 17

[Frank-Rainer Grahl (:frg)]

Attachment: 1273298-signing-cr.patch

Patch for comm-release. Is it possible that the Win32 build config is utter rubbish with VS2010 still included?

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: Incorrect / incomplete build options.
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): none
String changes made by this patch: none

Comment 18

[rsx11m]

Comment on attachment 8769478 [details] [diff] [review]
1273298-xpisigning.patch

>+++ b/suite/browser/browser-prefs.js
>+pref("xpinstall.signatures.required", false);

as far as I can tell, this is set to false in all.js and overridden in firefox.js to true.

https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#4638
https://dxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#72

So, it this really necessary to set in browser-prefs.js as well since it defaults to false already?

Comment 19

[Frank-Rainer Grahl (:frg)]

>> So, it this really necessary to set in browser-prefs.js as well since it defaults to false already?

No. Just did go thru all the signing options and this one is the only one we currently do not set ourself. It might get changed in the future out of the blue but then we could change it then and not now. Thought ratty should decide. Completely indifferent here :)

FRG

Comment 20

[Adrian Kalla [:adriank]]

Frank: to be honest, I don't know what you are trying to fix with this patches - as they will definitely not fix *this* bug, as it has absolutely nothing to do with signing... Also: this bug always happens only on c-c and never on c-a, c-b and c-r (merge-independent).

Comment 21

[Frank-Rainer Grahl (:frg)]

>> Frank: to be honest, I don't know what you are trying to fix with this patches

Not much. As I told ewong I doubt that these will help. Just want to be sure that the environment is ok and knowing that all variables which control signing are set correctly might be a first step.

You sure this has nothing got do with signing?

Comment 22

[Adrian Kalla [:adriank]]

(In reply to Frank-Rainer Grahl from comment #21)
> You sure this has nothing got do with signing?

The message on the command line says "Disabling foreign installed add-on" (see bug 1159499), so it must result from the (Firefox) strategy to block add-ons installed by 3rd party software - and this has nothing to do with signing.

Comment 23

[Edmund Wong (:ewong)]

Comment on attachment 8769479 [details] [diff] [review]
1273298-signing-ca.patch

Review of attachment 8769479 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm

Comment 24

[Edmund Wong (:ewong)]

Comment on attachment 8769480 [details] [diff] [review]
1273298-signing-cb.patch

Review of attachment 8769480 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm

Comment 25

[Edmund Wong (:ewong)]

(In reply to Adrian Kalla [:adriank] from comment #20)
> Frank: to be honest, I don't know what you are trying to fix with this
> patches - as they will definitely not fix *this* bug, as it has absolutely
> nothing to do with signing... Also: this bug always happens only on c-c and
> never on c-a, c-b and c-r (merge-independent).

I'm wondering if this is related to bug 1191941?

Comment 26

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/releases/comm-aurora/rev/5418a4e791e3
https://hg.mozilla.org/releases/comm-beta/rev/270a08a12b13

Comment 27

[Frank-Rainer Grahl (:frg)]

Mc reported over irc that contrary to popular, my and Adrians belief changing the configs did indeed fix at least some of the problems. I still wonder why because locally the prefs default to 0 if not set. 

http://logs.glob.uno/?c=mozilla%23seamonkey&s=12+Jul+2016&e=13+Jul+2016

Comment 28

[Edmund Wong (:ewong)]

Comment on attachment 8769481 [details] [diff] [review]
1273298-signing-cr.patch

Review of attachment 8769481 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm.

Comment 29

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/releases/comm-release/rev/cf7409eacd77

Comment 30

[Philip Chee]

Comment on attachment 8769478 [details] [diff] [review]
1273298-xpisigning.patch

I see no harm in adding this.

Comment 31

[Frank-Rainer Grahl (:frg)]

https://hg.mozilla.org/comm-central/rev/f7e1f4d6f62f

Should the bug be closed for now?

Comment 32

[rsx11m]

Looks like we are done here, though issues persist. I've tried both a trunk tinderbox build and my own 2.48a1 Linux build and didn't see the "could not be verified" warning with either build in the Add-Ons Manager. However, Lightning was disabled and the "Disabling foreign installed add-on {e2fda1a4-762b-4020-b5ad-a41df1933103} in app-global" warning appeared in the console. This appears to be bug 1159499 though rather than the issue here (both builds used with a new profile).

For the upgrade scenario, I upgraded to 2.48a1 from an older 2.44 build (not trunk, though). Lightning wasn't updated, instead the message appeared in the Add-Ons Manager that it's incompatible. Judging from the console messages, that seems to be a conflict between the older Lightning version in the 2.44 profile and the different version coming with my current build, thus may be a non-trunk to trunk update issue which may not appear in trunk to trunk or non-trunk to non-trunk updates.

Comment 33

[Frank-Rainer Grahl (:frg)]

Jupp. Its likely becauase of the switch in Lightning locations between release and nightly. I never experience this on beta/release or nightly to nightly upgrades.

I think lets close this one here and reopen it or a new one if something else pops up.

Comment 34

[rsx11m]

I'm confused, which patches landed for 2.47, to get the tracking flags right?

Comment 35

[rsx11m]

Meaning, did everything land everywhere where it needed to land?  ;-)

Comment 36

[Frank-Rainer Grahl (:frg)]

>> Meaning, did everything land everywhere where it needed to land?  ;-)

Yes. The mozconfig variables landed on all branches. The optional play-it-safe pref change only on c-c for 2.48+. I think 2.45 should also be marked as fixed. FF 48 enforces the signing  requirements and so its the same as 2.46 even if it was somehow marked as unaffected.

Comment 37

[rsx11m]

Ok, thanks.

Comment 38

[Tony Mechelynck [:tonymec]]

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48a1
Build identifier: 20160913003001
http://hg.mozilla.org/comm-central/rev/b9cd88a0878f441423c99b7335ee393f4c7d1df1

FWIW, the warnings for add-ons not signed by Mozilla (including the ChatZilla nightly build) have disappeared. The only warnings still present are "<add-on> is incompatible with SeaMonkey 2.48a1" which is normal for the themes and langpacks which have it. (I have extensions.checkCompatibility.nightly == false so these latter add-ons are not app-disabled.)