Closed Bug 1568994 Opened 5 years ago Closed 5 years ago

Move Update URL template from pref to application.ini

Tracking

()

Status:

RESOLVED FIXED

Milestone:

mozilla76

Tracking Flags:

Tracking

Status

firefox76

---

fixed

People

(Reporter: bytesized, Assigned: bytesized)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

Bug 1568994 - Add Update URL template to application.ini, XREAppData, and Services.appinfo r=glandium 5 years ago Robin Steuber (she/her) [:bytesized] 47 bytes, text/x-phabricator-request		Details \| Review
Bug 1568994 - Convert usage of app.update.url pref to Services.appinfo.updateURL r=mhowell 5 years ago Robin Steuber (she/her) [:bytesized] 47 bytes, text/x-phabricator-request		Details \| Review
Bug 1568994 - Convert Enterprise policy AppUpdateURL to work with the new update url mechanism r=mhowell,mkaply 5 years ago Robin Steuber (she/her) [:bytesized] 47 bytes, text/x-phabricator-request		Details \| Review

Robin Steuber (she/her) [:bytesized]

Assignee

Description

•

5 years ago

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:

Robin Steuber (she/her) [:bytesized]

Assignee

Comment 1

•

5 years ago

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)

Mike Hommey [:glandium]

Comment 2

•

5 years ago

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)

Robert Strong (they/them - no direct email)

Comment 3

•

5 years ago

•

Edited

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.

Robin Steuber (she/her) [:bytesized]

Assignee

Comment 4

•

5 years ago

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)

Mike Hommey [:glandium]

Comment 5

•

5 years ago

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)

Robin Steuber (she/her) [:bytesized]

Assignee

Comment 6

•

5 years ago

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: 5 years ago

Flags: needinfo?(mh+mozilla)

Resolution: --- → FIXED

Robin Steuber (she/her) [:bytesized]

Assignee

Comment 7

•

5 years ago

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

Status: RESOLVED → REOPENED

Resolution: FIXED → ---

Mike Hommey [:glandium]

Comment 8

•

5 years ago

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)