Closed Bug 1568994 Opened 1 year ago Closed 8 months ago

Move Update URL template from pref to application.ini

Categories

(Toolkit :: Application Update, task, P3)

task

Tracking

()

RESOLVED FIXED
mozilla76
Tracking Status
firefox76 --- fixed

People

(Reporter: bytesized, Assigned: bytesized)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

There are a number of values that we need to generate the update URL. Since the update agent will need to generate the update URL, it should have some way of getting access to this information. By adding this information to the application.ini, we would easily be able to access this from outside of Firefox.

These are the values needed:

Glandium & Mossop-
I wanted to run these additions to application.ini by both of you. Does this sound ok? Should I be doing this a different way?

Thanks!

Flags: needinfo?(mh+mozilla)
Flags: needinfo?(dtownsend)

Do you intend to read application.ini? I'm not sure we should be doing something like this. application.ini is only there "by chance", as in, it wasn't removed because automation needed it, which it probably doesn't really anymore... so we may actually want to remove the file.
It's also worth noting that the update url template is a pref. Meaning it can be changed. And surely, the update service should be aware of that.
My gut feeling is that Firefox should write out a file for the service's consumption, rather than the service relying on a file shipped with Firefox.

Flags: needinfo?(mh+mozilla)

It is only read from the default prefs so user prefs can't change it. Ideally it wouldn't be possible to modify it as a default pref as well. Writing it out from the application would allow any user process to write it out since it would have to be written to a user writable location which would allow user processes to break updating.

Yes, I intend on reading this data from application.ini.

As Robert already mentioned, we are ok with removing that pref, in part because changing the user value of the pref currently has no effect.

Also as Robert mentioned, we consider writing out a user-writable file specifying the update URL to be an unacceptable security issue. It is simply too easy to compromise.

It sounds like you do not think that this is an appropriate way of storing or accessing this data, is that accurate? I feel that I should note that we are also planning on reading data out of a similar file: distribution.ini. Do you know of any problem with that?

Flags: needinfo?(mh+mozilla)

distribution.ini is not something we ship, but something downstreams might. It's meant to be there when it is. application.ini is a vestige.
The update service is not going to be built and shipped separately is it? So why not compile those values in?

Flags: needinfo?(mh+mozilla)

The Background Update Agent will be built as a separate binary, but using our build system. However, it will be written in Rust, and I am still struggling to figure out an appropriate way to access these compile-time constants in Rust.

Robert had previously requested that the update.locale file's contents be moved to application.ini, and suggested that it could be a good place for the update URL template too. It seemed logical, therefore, to store the other values that we need in the same place.

But if you don't think that this is an appropriate place for some or all of that information, there are other options we can consider. I'm not sure how to access the URL template, but perhaps I could add it as a compile-time constant and access it in the same way that I would be accessing other the other constants.

Let me know what you think.

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(mh+mozilla)
Resolution: --- → FIXED

Whoops. Don't know how I managed to press that by accident...

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

OS_TARGET, ABI and MOZ_ASAN are already build time constants ; GRE_MILESTONE is technically in platform.ini, it's also equivalent to App.Version, so it's more or less in application.ini already. As for the URL template... considering how far we actually still are from getting rid of application.ini... ¯_(ツ)_/¯. I guess it kind of makes sense in application.ini for the same reason the crash reporter submit url is there, whatever the reason it's there is in the first place (which I think might be related to downstreams).

Flags: needinfo?(mh+mozilla)
Priority: -- → P2
Summary: Add Update URL components to application.ini → Add Update URL template to application.ini
Flags: needinfo?(dtownsend)

This is being added to facilitate moving generation of the update URL to Rust (Bug 1567286). Once that has been completed, we should be able to remove the update URL from its current location in firefox.js so that it is not being duplicated in application.ini.

Attachment #9087866 - Attachment description: Bug 1568994 - Add Update URL template to application.ini r=glandium → Bug 1568994 - Add Update URL template to application.ini, XREAppData, and Services.appinfo r=glandium
Summary: Add Update URL template to application.ini → Move Update URL template from pref to application.ini
Priority: P2 → P3
Attachment #9092702 - Attachment description: Bug 1568994 - Convert usage of app.update.url pref to Services.appinfo.updateURL r=rstrong → Bug 1568994 - Convert usage of app.update.url pref to Services.appinfo.updateURL r=mhowell
Attachment #9092703 - Attachment description: Bug 1568994 - Convert Enterprise policy AppUpdateURL to work with the new update url mechanism r=rstrong,mkaply → Bug 1568994 - Convert Enterprise policy AppUpdateURL to work with the new update url mechanism r=mhowell,mkaply
Pushed by ksteuber@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4f2d89525c63
Add Update URL template to application.ini, XREAppData, and Services.appinfo r=glandium
https://hg.mozilla.org/integration/autoland/rev/12efcfc5555a
Convert usage of app.update.url pref to Services.appinfo.updateURL r=mhowell
https://hg.mozilla.org/integration/autoland/rev/cd6bf21b54db
Convert Enterprise policy AppUpdateURL to work with the new update url mechanism r=mkaply,mhowell
Status: REOPENED → RESOLVED
Closed: 1 year ago8 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
Regressions: 1625461
Blocks: 1625466

After this change I get Missing values in application.ini: AppUpdate:url
This is on linux, doing an x86 build of geckoview. Not filing a new bug because I'm not sure what is special about my setup that makes this happen.

(In reply to Eitan Isaacson [:eeejay] from comment #14)

After this change I get Missing values in application.ini: AppUpdate:url
This is on linux, doing an x86 build of geckoview. Not filing a new bug because I'm not sure what is special about my setup that makes this happen.

I get the same thing here.

Flags: needinfo?(ksteuber)

Addressing in Bug 1625523

Flags: needinfo?(ksteuber)
No longer blocks: 1630041
Regressions: 1630041
You need to log in before you can comment on or make changes to this bug.