[bug] Generated `upgrade_code` for default `product_name` (tauri-app) causes ambiguity with an unrelated `winget` application

[drebouta]

Describe the bug

When bundling an application using the default name (tauri-app) and installing it using the generated .msi, winget list or winget list --upgrade-available (if product_version < 1.0.3) will reference an unrelated application: maqibin.MDXNotes.

This could ultimately lead to unwanted installations using winget upgrade --all.

Related issue on winget-cli repo: microsoft/winget-cli#6040 by @tkappedev

Related code:

tauri/crates/tauri-bundler/src/bundle/windows/msi/mod.rs

Lines 582 to 592 in 88c0568

	let upgrade_code = settings
	.windows()
	.wix
	.as_ref()
	.and_then(|w| w.upgrade_code)
	.unwrap_or_else(|| {
	Uuid::new_v5(
	&Uuid::NAMESPACE_DNS,
	format!("{}.exe.app.x64", &settings.product_name()).as_bytes(),
	)
	});

If above code is modified, the cli would need adjustments too:

tauri/crates/tauri-cli/src/inspect.rs

Lines 38 to 43 in 88c0568

	let product_name = interface.app_settings().get_package_settings().product_name;
	let upgrade_code = uuid::Uuid::new_v5(
	&uuid::Uuid::NAMESPACE_DNS,
	format!("{product_name}.exe.app.x64").as_bytes(),
	);

Reproduction

microsoft/winget-cli#6040

1. Choose any preferred variant of create-tauri-app: https://v2.tauri.app/start/create-project/
2. When prompted on name, etc., select the default settings, keep name as 'tauri-app' and choose any stack
3. Build the application: https://v2.tauri.app/reference/cli/#build
4. Install the application with the created .msi package (tauri-app\src-tauri\target\release\bundle\msi\tauri-app_0.1.0_x64_en-US.msi) and use default install location (C:\Program Files\tauri-app)
5. Do a winget list or winget list --upgrade-available.
6. The installed app will be detected as maqibin.MDXNotes, and with winget as source

Expected behavior

Using an additional and suitable property of the package to generate a truly unique upgrade_code per application.

Full tauri info output

-

Stack trace

Additional context

No response

[FabianLars]

Wow what a finding! And wild that a uuid derived from the product name is a match 🙃

Changing the upgrade code is breaking (as it breaks app updates) so it'd require a new setting :/ considering that hopefully nobody uses tauri-app as their actual product name i think we can make this low prio (but still nice to have of course)

[drebouta]

Wow what a finding! And wild that a uuid derived from the product name is a match 🙃

Magic 🪄

hopefully nobody uses tauri-app as their actual product name

Already too late. We also used the default values when building, just to quickly test the application and I guess we are not the only ones doing that.

Changing the upgrade code is breaking

A non-breaking mitigation (not fix) could be: Adding a uuid (might be overkill) or YYYY-MM-DD to the default package name args:
https://github.com/tauri-apps/create-tauri-app/blob/16c3d9f9286a0c05c2b5c2d074fe0dada8b21ad8/src/args.rs#L58
https://github.com/tauri-apps/create-tauri-app/blob/16c3d9f9286a0c05c2b5c2d074fe0dada8b21ad8/src/utils/mod.rs#L25

[Legend-Master]

And wild that a uuid derived from the product name is a match 🙃

Looking at maqibin.MDXNotes, it is built with tauri so 😂

so it'd require a new setting

We have a setting https://tauri.app/reference/config/#upgradecode I believe

We should document about where will productName be used and also in identifier's docs so at least people understand that this needs to be changed before they publish their app

#14175 (comment)

And similar to how to check and reject com.tauri.dev as identifier, we should probably at least show a warning about product name being tauri-app

A non-breaking mitigation (not fix) could be: Adding a uuid (might be overkill) or YYYY-MM-DD to the default package name args:

This is also a good way to mitigate this