1290548 - Unbranded add-on developer builds are updating to branded Firefox builds

Status: VERIFIED FIXED

(Release Engineering :: General, defect)

Description

[Kev Needham [:kev]]

The unbranded builds being generated for the add-on developers from bug 1135781 are updating to branded builds on the beta channel, and are likely to do the same on release in the future.

Steps to reproduce:

1. Download the unbranded beta add-on developer build from https://wiki.mozilla.org/Add-ons/Extension_Signing#Latest_Builds and install
2. Go to "About Firefox", an update is flagged as being available and starts loading
3. At the completion of the download, restart Firefox
4. The unbranded developer preview with Nightly branding is replaced by the branded version of Firefox beta

Expected results:

The unbranded builds do not update.

Suspect we need to add a specific product name to avoid defaults being set.

Comment 1

[Justin Wood (:Callek)]

Easiest option I imagine:

Don't provide updates, set https://dxr.mozilla.org/mozilla-beta/source/browser/config/mozconfigs/win32/common-opt#5 [in the addon builds] to `default` rather than using the real channel.

If we actually *want* updates we can revisit some base assumptions as well and investigate.

Comment 2

[Kim Moir [:kmoir] ET]

or you can just not provide updates like asan builds and specify that in the bb configs. I have a patch

Comment 3

[Kim Moir [:kmoir] ET]

Attachment: bug1290548.patch

patch to disable updates on add-on-devel builds

Comment 4

[JustOff]

Please, consider an option to provide update within unbranded tree, instead of completely disable update.

Comment 5

[Kim Moir [:kmoir] ET]

Comment on attachment 8776118 [details] [diff] [review]
bug1290548.patch

tests failed, not sure why since they passed on my master, investigating

Comment 6

[Kim Moir [:kmoir] ET]

Issue was bug 1291464

Comment 7

[Kim Moir [:kmoir] ET]

Comment on attachment 8776118 [details] [diff] [review]
bug1290548.patch

now that the blocking issue has been fixed, I landed this patch again and the tests passed

Comment 8

[Masatoshi Kimura [:emk]]

How to test add-on behaviors across updates, then?

Comment 9

[Kim Moir [:kmoir] ET]

verified that the downloaded addon build from 
https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&revision=c40e04bf929755ddbe1dfb5ea6e7302055805a10

Has the update channel set to default which means it will not be served updates.

To the people that requested that we provide updates for this build, we don't intent to provide updates at this time.  Please install a new addon devel build if you want test your addons with a different build.

Comment 10

[Avi Halachmi (:avih)]

(In reply to Kim Moir [:kmoir] from comment #9)
> verified that the downloaded addon build from 
> https://treeherder.mozilla.org/#/jobs?repo=mozilla-
> beta&revision=c40e04bf929755ddbe1dfb5ea6e7302055805a10
> 
> Has the update channel set to default which means it will not be served
> updates.
> 
> To the people that requested that we provide updates for this build, we
> don't intent to provide updates at this time.  Please install a new addon
> devel build if you want test your addons with a different build.

The "unbranded build" is not meant only for testing.

It was rightfully marketed at the time as a build which allows users to choose their own addons without being forced to a curated list (signed is curated, even if not hosted on AMO).

This build is about choice. Not about testing.

Mozilla didn't want to brand it as "Firefox" which is somewhat understandable, but there's quite a distance from "not branded but otherwise the same as release firefox except without forcing signed addons" to what it's apparently becoming now, which seems like "a build for testing addons".

It's fine if it's not branded as Firefox, and it's even OK, IMHO, if it updates a day or two after the official Firefox, but please make it behave like the normal release build otherwise (or beta respectively for the unbranded beta), with the same kinds of updates. I.e. with security updates when Firefox gets those, not as frequently as nightly, but not "never" either.

Comment 11

[Dan Stillman]

(In reply to Kim Moir [:kmoir] from comment #9)
> To the people that requested that we provide updates for this build, we
> don't intent to provide updates at this time.  Please install a new addon
> devel build if you want test your addons with a different build.

Sorry, are you suggesting that this is meant to be a permanent solution?

Even setting aside Avi's points about end users, the whole point of these builds for developers is that they allow them to develop their add-ons against current versions of Firefox so that they don't put out broken software — otherwise they could just use Developer Edition or Nightly, which support the same pref. It makes no sense to provide these builds and then not have them stay up to date.

I understand that adding new release channels is annoying, but these builds have been promised as a solution to all the problems with signing for two years — removal of the pref was pushed back something like five versions because these builds wasn't ready — and to now tell people that they'll need to manually check for and install new builds every few days is pretty shocking.

Comment 12

[persona]

The unbranded builds were promised as a way to let users run unsigned addons, not for "testing" (we already have the developer builds for that).  Crippling them by disabling updates will increase vulnerability.  Marking this bug as "resolved" is adding insult to injury.

Comment 13

[Dan Stillman]

(In reply to persona from comment #12)
> The unbranded builds were promised as a way to let users run unsigned
> addons, not for "testing" (we already have the developer builds for that).

Just to be clear, they were promised for both — and the issue for developers isn't really "testing" but rather development. If I'm working on an add-on, unless I don't plan to put out a release for several months, I need to develop against the version of Firefox that people are using now or will be using soon, not the version they'll be using in 12-18 weeks. That's the reason these builds are important for developers.

Comment 14

[persona]

Fine.  My point was that the unbranded builds were supposed to be useful for non-developers as well, those that have legitimate reasons to run unsigned plugins.

Comment 15

[Kim Moir [:kmoir] ET]

Please follow bug 1291912 for information on providing updates for unbranded builds for addon developers. 

The purpose of unbranded addon builds is to allow unsigned addons to be tested before they are signed and released and made available to their user communities.  For people who want to run unsigned addons you can use esr builds or nightly builds. However, we would encourage our users to use signed addons where possible for greater security.

https://wiki.mozilla.org/Add-ons/Extension_Signing#Timeline

Comment 16

[persona]

In that case, I would encourage your users to switch to another browser where possible for greater freedom.

Comment 17

[Avi Halachmi (:avih)]

(In reply to Kim Moir [:kmoir] from comment #15)
> The purpose of unbranded addon builds is to allow unsigned addons to be
> tested before they are signed and released and made available ...

Let's assume this has been known all along, and let's get back 18 months to where I believe the forced signing was first announced - https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/  :

> For extensions that will never be publicly distributed and will never leave
> an internal network, there will be a third option. We’ll have more details
> available on this in the near future.

As far as I can tell (do correct me if I'm wrong), it was never announced publicly what this third option would be, and also never mentioned since then.

ESR was mentioned at some blog-posts at the comments sections only, as well as at comment 15 here, as a build which would allow disabling forced signing.

So maybe this bug is an incorrect place to discuss this subject.

Is there another bug or some other pointers to a discussion/announcements/decision which explicitly states or implies that ESR would be the only non-crippled build which allows disabling forced signing?

Maybe this discussion should take place there.

If, however, there was no such announcement, then it's obvious why people expect to have a non-crippled build which is equivalent to a release build - updates and all, which allows disabling forced signing.

Comment 18

[Masatoshi Kimura [:emk]]

(In reply to persona from comment #16)
> In that case, I would encourage your users to switch to another browser
> where possible for greater freedom.

Out of curiosity, to which browser? Chrome allows only signed Extensions from Chrome Web Store. Edge allows only signed Extensions from Microsoft Store.

Comment 19

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Avi Halachmi (:avih) from comment #17)
> Is there another bug or some other pointers to a
> discussion/announcements/decision which explicitly states or implies that
> ESR would be the only non-crippled build which allows disabling forced
> signing?

The main venue for discussing unbranded builds has been the addons-user-experience mailing list[1].  It's pretty hard to spot a message that mentioned updates one way or the other when the unbranded build plan was announced (there are some recent messages now that the builds are made available and bugs like this were filed).

The closest thing I could find is a message[2] from Jorge on 2015/01/27 that says:

---

> 4) Updating differences?  Does the debug build check for and
> download newer versions of itself (debug builds) or newer versions
> of the release build?

It should update to the correct version, yes. We'll need to verify this,
though.

---

"Debug build" here is referring to the unbranded build (this is explained in Jorge's reply in the same message).

[1]: https://groups.google.com/forum/#!forum/mozilla.addons.user-experience
[2]: https://groups.google.com/d/msg/mozilla.addons.user-experience/qIgLq28aTdI/VXv4dEigngkJ

Comment 20

[persona]

> Out of curiosity, to which browser?

Pale moon, possibly others (SeaMonkey?)

Comment 22

[Kim Moir [:kmoir] ET]

Reopening because of issues identify in bug 1296910

Looking at a release build I see app.update.channel is set to release for the addon-devel build

I tested this on beta builds and it didn't occur.  Looking at the whitelist for release builds, it appears that it sets all update channels to release. I have a patch to test this. 

https://hg.mozilla.org/integration/mozilla-inbound/file/tip/browser/config/mozconfigs/whitelist#l70

Comment 23

[Kim Moir [:kmoir] ET]

Looking at the whitelist, all platforms doesn't include addon builds 
all_platforms = ['win64', 'win32', 'linux32', 'linux64', 'macosx-universal']
so I'm trying another approach on try

Comment 24

[Kim Moir [:kmoir] ET]

Attachment: set default channel in mozconfigs

I ran a job on try with these patches.  Looking at the about.config, it appears that it has app.update.channel set to default.  

It also has app.update.auto set to true and app.update.enabled set to true.  However, other CI builds for instance, on inbound have the same last two preferences set.

Comment 25

[Masatoshi Kimura [:emk]]

I restate my comment in bug 1291912: updating to branded builds is better than no update for add-on development. Please do not "fix" this until we have a proper "addon-devel" update channel.

Comment 26

[Manuel Reimer]

Today, I tried a "48.0.1" "addon developer" build on Windows and it directly updated me to the branded Firefox 48.0.1. So with the current situation the only way to use the unbranded version seems to be to disable the update process.

Comment 27

[Jordan Lund (:jlund)]

Comment on attachment 8783766 [details] [diff] [review]
set default channel in mozconfigs

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

hm, I think it might be better to fix this in mh. since we use the env MOZ_UPDATE_CHANNEL for things like debug: https://dxr.mozilla.org/mozilla-central/search?q=enable-update-channel&=mozilla-central

iiuc - we could add custom add-on-devel platform overrides under here:
   example for beta: https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/builds/branch_specifics.py?q=path%3Abranch_specifics&redirect_type=single#140


do we want to have a custom channel for these builds instead of sharing the same as debug/asan etc. we would need to add a special rule in balrog.

Comment 28

[Kim Moir [:kmoir] ET]

Attachment: bug1290548-3.patch

patch updated.  I didn't think that anything updated to the default channel.

Comment 29

[Jordan Lund (:jlund)]

Comment on attachment 8784078 [details] [diff] [review]
bug1290548-3.patch

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

should just work ®

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8d3f26b93ad9
Unbranded add-on developer builds are updating to branded Firefox builds r=jlund DONTBUILD

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8d3f26b93ad9

Comment 32

[Kim Moir [:kmoir] ET]

Comment on attachment 8783766 [details] [diff] [review]
set default channel in mozconfigs

So this patch

https://bug1290548.bmoattachments.org/attachment.cgi?id=8784078

didn't work on release

https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=5638397535682c538b244827fc2a9c339c716653

The app.update.channel was still release.

I landed the previous patch on release and checked the adddon build and the  channel is now default
https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&revision=fd70cb7a74bc9bd7a17467ceb988297e3084aa95

Comment 33

[Jordan Lund (:jlund)]

Comment on attachment 8783766 [details] [diff] [review]
set default channel in mozconfigs

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

weird ... magic!

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d349c7c04845
Unbranded add-on developer builds are updating to branded Firefox builds r=jlund DONTBUILD

Comment 35

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/d349c7c04845

Comment 36

[Johan]

When will an updated version of Dev Preview be available with this fix? Cause it seems you don't distribute point release versions of Dev Preview either (still at 48.0.0) so it will keep updating automatically and break the add-on I'm working on.

Comment 37

[Johan]

Re the above: Just found the updated build here: https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-release-win32-add-on-devel/1472654901/

Seems your definition of "Latest build" is quite off, given that https://wiki.mozilla.org/Add-ons/Extension_Signing#Latest_Builds still points to the 48.0.0 version.

Yet another reason to give us proper auto-updating, I mean if you can't even keep the "latest builds" page for manual updating up-to-date...

Comment 38

[Jordan Lund (:jlund)]

(In reply to Johan from comment #37)

> Yet another reason to give us proper auto-updating, I mean if you can't even
> keep the "latest builds" page for manual updating up-to-date...

johan: I can empathize with your frustration. Hopefully you can understand we have many simultaneous efforts and priorities continuously at play here. I am not sure when we will be offering automatic updates. In the mean time, here is a dynamic url that will always point you to the latest mozilla-release based win32 addon-devel build: https://tools.taskcluster.net/index/artifacts/#gecko.v2.mozilla-release.latest.firefox/gecko.v2.mozilla-release.latest.firefox.win32-add-on-devel

context: for each build we upload to the official location: archive.mozilla.org, we also upload to taskcluster.net and in taskcluster we have indexes available for things like 'latest' so we don't have to worry about a wiki page going out of date.

Comment 39

[Vasilica Tamas, QA [:vtamas]]

Confirm that unbranded builds are no longer updated at all. Tested on Windows 10 64-bit, Windows 7 64-bit and Ubuntu 12.04 64-bit.