`convertToRustHeaders` replaced `options.headers` of the object passed to
`check`, `download` and `downloadAndInstall` with an array of entries. The
headers are now converted into the invoke payload only (`toRustHeaders`).
E2E: `check` leaves the options object untouched.
plugins/updater/guest-js/index.ts
- `tempdir_in(..)?` and `metadata()?` returned early on the first location
that failed (e.g. a non-writable `/tmp`), so the cache dir and the
directory next to the AppImage were never tried. Failures now move on to
the next location, as the deb/rpm path already did.
- The candidate list was duplicated between the AppImage and deb/rpm paths;
both now use `tmp_dir_locations`, which also no longer unwraps the parent
of the app path (`extract_path.parent().unwrap()`).
Compile-checked with clippy in a Linux container (default features).
plugins/updater/src/updater.rs
* fix(updater): derive the Windows installer launch error from ShellExecuteW
A failed `ShellExecuteW` was reported with `std::io::Error::last_os_error()`,
but `ShellExecuteW` reports failures through its return value (`SE_ERR_*`),
not reliably through `GetLastError`, so the message could be meaningless. The
return value is now mapped to an error (the codes shared with Win32 errors,
like `SE_ERR_ACCESSDENIED` when the UAC prompt is declined, keep their OS
message).
Running `on_before_exit` only once the installer launched changes when a
public hook runs and is left for v3.
Compile-checked only (clippy for x86_64-pc-windows-msvc).
plugins/updater/src/updater.rs
* use constants
Each `Update.download()` overwrote `this.downloadedBytes` without closing the
previous resource, so the whole previous update payload stayed in the webview
resources table. The previous resource is now closed once the new download
succeeded (so a failed retry still leaves the earlier download installable).
Not covered by e2e: the fixture manifest has no valid signature, so a
download can never succeed there.
plugins/updater/guest-js/index.ts
* fix(updater): warn when the update download URL is not https
`validate_endpoints` enforces `https` for the endpoints, but not for the `url`
of the manifest, so the artifact can be downloaded in plaintext. Enforcing it
would break existing releases (left for v3); `Update::download` now logs a
warning instead, unless `dangerousInsecureTransportProtocol` is enabled.
plugins/updater/src/updater.rs
* Apply suggestion from @lucasfernog
`#[cfg(mobile)] fn install_inner` returned `Ok(())` without doing anything.
`check` already fails with `UnsupportedOs` there unless a Rust caller sets a
custom target, in which case a download was followed by a successful
"install" that did nothing. It now returns `Error::UnsupportedOs`, the error
`check` uses.
Verified with clippy for aarch64-linux-android (the iOS build needs the Swift
package, which does not build here).
plugins/updater/src/updater.rs
* fix(updater): check the AppImage update payload before installing it
Without the `zip` feature the gz check was compiled out and a signed
`.tar.gz` was written verbatim over the AppImage, and any other payload
without the gz magic (e.g. a `.deb` from the same release, or the fallthrough
when `bundle_type()` is `None`) was written the same way, corrupting the app.
The payload is now checked before the current AppImage is moved: a gzip
archive requires the `zip` feature, and anything else must be an ELF
executable (which every AppImage is); otherwise `InvalidUpdaterFormat` is
returned. The `Cursor`/`OsStr` imports are gated so that the crate builds
warning-free without `zip` on Linux too.
Compile-checked with clippy on macOS, Linux (container) and Windows, each
with and without the `zip` feature.
plugins/updater/src/updater.rs
* tests
* fix(updater): skip a backup location the AppImage cannot be renamed into
Two mounts of one file system share st_dev, so install_appimage could
pick a bind-mounted or private temp dir and then fail every install with
EXDEV. Move on to the next location instead; the last one is the
AppImage's own directory.
* Apply suggestion from @lucasfernog
---------
Co-authored-by: Lucas Fernandes Nogueira <lucas@tauri.app>
* fix(updater): restore the current app when a macOS install fails
On macOS `install_inner` moved the installed app into a `TempDir` backup and
then renamed the new bundle into place. Neither of the two steps after that
move restored the app on failure, and the `TempDir` deleted the backup on
every exit path, so a failed final rename left the user with no app at the
install path and no way back. The privileged fallback had the same shape:
`rm -rf` the app, then `mv` the new one in.
Both moves are now `replace_bundle`, which renames the current app to the
backup, renames the staged bundle into place, and renames the backup back if
that second step fails. The privileged script moves the current app aside,
moves the new one in, and restores on failure; it deletes the previous bundle
only after the new one is in place. The temp and install locations are
compared with `st_dev` before anything moves, returning the existing
`TempDirNotOnSameMountPoint` rather than failing after the app has already
been moved, and the staged bundle root is set to 0755 because `tempfile`
creates it 0700 and that mode followed it into `/Applications`.
Two unit tests cover `replace_bundle`: the staged bundle ends up in place with
the previous one in the backup, and a failed second rename leaves the current
bundle where it was and returns that error.
Closes#3505, closes#3506.
* fix(updater): exchange the current and new bundles atomically on APFS
Even with the restore in place there was a moment between the two renames
where the install path held nothing, and a process killed in that moment
left the previous app in the temp dir rather than where it belonged.
`swap_bundle` calls `renamex_np` with `RENAME_SWAP`, which exchanges the two
directories in one step so the install path always holds one of the two. The
previous app ends up in the extraction temp dir and is removed with it. Where
the file system does not support the swap (`ENOTSUP`, or `EINVAL` on older
systems) the two-rename path with the restore is used as before, and a
`PermissionDenied` from either still goes to the privileged fallback.
`libc` is added for the macOS target only; it was already in the lockfile
through tauri. One macOS test checks the exchange and skips on a file system
that reports `ENOTSUP`.
* fix(updater): keep the previous app when it cannot be restored
If the restore rename also failed, the previous app was left only in the backup TempDir and deleted with it. Keep the backup in that case and return Error::PreviousAppNotRestored with its path.
* fix(updater): quote the paths in the privileged macOS install script
The paths went into single-quoted sh words inside an AppleScript string unescaped, so a quote in the app path broke the command (run as root) or panicked on the compile expect. Quote them for sh and AppleScript, and report script failures instead of panicking.
* fix(updater): fall back to moving the bundles on any swap error
Only ENOTSUP and EINVAL got the two-rename fallback, so volumes reporting EOPNOTSUPP or ENOSYS for RENAME_SWAP failed every update. Fall back on anything but a permission error, and have the swap test skip only off APFS.
* fix(updater): stage the macOS update on the app's volume
When the system temp dir was on another volume than the app, every update was refused. Create the temp dirs next to the app in that case, and compare the install path itself rather than what a symlink there points to.
* test(updater): update a macOS app on another volume than the temp dir
Runs the app from APFS and HFS+ disk images, covering the atomic swap and the two-rename fallback with the update staged next to the app.
* fix(updater): swap the bundles atomically in the privileged macOS install
The admin path ran two mv calls, leaving the install path empty between them. Run renamex_np with RENAME_SWAP as root through osascript's JavaScript bridge, and only fall back to the moves where the swap fails.
* add test
* cleanup
---------
Co-authored-by: Lucas Nogueira <lucas@tauri.app>
check() set both variables to Debian paths when they were unset. On distros
with a different layout, such as ALT Linux, the paths do not exist, and
rustls-native-certs then loads roots only from them, so every TLS client
created afterwards in the app got an empty root store.
reqwest with rustls already finds the system store through
rustls-platform-verifier and openssl-probe, so the override is not needed.
Closes#3598
* feat(updater): verify the version an update was signed for
The endpoint response is fetched over TLS but is not signed, and the signature
only covers the artifact, so a crafted response could pair an inflated version
with an older release's url and signature to force a downgrade to a genuine
but outdated build.
Read the version back from the signature's trusted comment and reject an
update whose announced version differs. Signatures carrying no version are
only rejected under the new requireSignedVersion option, since older CLIs did
not record one.
* fix tests
* feat(updater): option to not restart after install
* More platform cfg
* Add the same function for `UpdaterBuilder`
* Fix missing `#[cfg(windows)]`
* Mark `current_exe_args` cfg(windows)
* Mark `on_before_exit` cfg(windows)
* Mark `installer_args` cfg(windows)
* Note about `installer_arg` apply to both
* Remove current args and restart together
* Only build needed bundle on windows as well
* Remove `/NS` since it breaks the msi updater
* Add launch updater debug log
* Add a folder to test updates
* Remove unused `#[allow(unused)]`
* Format
* messed up git stage
* Add change file
* Clean up
* Disable NSIS compression for API example
* Bump wry for v1 test to pull in https://github.com/tauri-apps/wry/pull/1703
* format
* Make typescript happy
* Close new update on destroy
