Linux x86-64 does not pick the correct arguments

[biemster]

When choosing Linux as operating system, the URL generated is wrong on a couple places. Currently it generates:

• os=linux
• arch=x86-64
• os_arch=x86-64

which should be (mind the capital L):

• os=Linux
• arch=x64
• os_arch=x86_64

As a testcase, app id icnkogojpkfjeajonkmlplionaamopkf gives and old placeholder crx with the current settings, and the current correct crx with the suggested parameters.

[Rob--W]

What makes you think that Linux should be uppercase? Chromium's source code that is responsible for generating the URL uses lowercase linux, https://source.chromium.org/chromium/chromium/src/+/master:components/update_client/update_query_params.cc;l=38-81;drc=62dbeaf1bdd7daf0970858363509b1420f2f2f19

I'm getting the expected result (a valid extension package for Linux) when I use your example.

[biemster]

Very interesting. The link your app creates: https://clients2.google.com/service/update2/crx?response=redirect&os=linux&arch=x86-64&os_arch=x86-64&nacl_arch=x86-64&prod=chromiumcrx&prodchannel=unknown&prodversion=85.0.4183.83&acceptformat=crx2,crx3&x=id%3Dicnkogojpkfjeajonkmlplionaamopkf%26uc and the link with only arch and os_arch changed to my suggestions: https://clients2.google.com/service/update2/crx?response=redirect&os=linux&arch=x64&os_arch=x86_64&nacl_arch=x86-64&prod=chromiumcrx&prodchannel=unknown&prodversion=85.0.4183.83&acceptformat=crx2,crx3&x=id%3Dicnkogojpkfjeajonkmlplionaamopkf%26uc return v0.0.3 of the extension, but when linux is capitalized in addition to the changed arc and os_arch: https://clients2.google.com/service/update2/crx?response=redirect&os=Linux&arch=x64&os_arch=x86_64&nacl_arch=x86-64&prod=chromiumcrx&prodchannel=unknown&prodversion=85.0.4183.83&acceptformat=crx2,crx3&x=id%3Dicnkogojpkfjeajonkmlplionaamopkf%26uc it returns the latest, v0.0.8 of the extension. Not sure what is happening here, this is contradictory to the chromium source you showed indeed.

[Rob--W]

Interesting indeed. I tried different values, such as cros and something invalid such as foo, but they too return the 0.0.3 version instead of the 0.0.8 from Linux.

[biemster]

Maybe it's just because this specific app id is not for a regular extension, but for a support library for the upcoming Live Caption feature?

[Rob--W]

Where did you get the uppercase Linux?

[biemster]

trial and error, and a LOT of it :)

[Rob--W]

Why did you believed that there was something newer than 0.0.3? I also occasionally look for undocumented stuff, but I wouldn't randomly search for new versions unless I had some indication that there was some.

If you actually have a device that has downloaded the expected package, you could have found the correct format sooner by sniffing the network. The update is almost certainly over https, so you'll need to capture the secrets involved in the protocol handshake. You can do so by using Wireshark or tcpdump on the host where the application is running by starting that application with the SSLKEYLOGFILE environment variable set.

[biemster]

On this specific occasion somebody told me there was a newer version. Sniffing the traffic was also an option indeed, I used a command line switch to specify the update URL, --component-updater=url-source=someurl: https://chromium.googlesource.com/chromium/src/+/lkgr/components/component_updater/component_updater_url_constants.cc#16 then I don't need to bother decrypting SSL.

[Rob--W]

I guess that we can close this issue, can't we? From crxviewer's point of view, the functionality appears to be working as intended.

[biemster]

yeah, this is probably some fringe case, doesn't seem to affect intended functionality.