https://tauri.app/ko/blogTauri v1 Blog2023-06-15T00:00:00.000Zhttps://github.com/jpmonette/feedTauri v1 Bloghttps://tauri.app/ko/meta/favicon-32x32.png<![CDATA[Tauri Board Elections & Governance Update]]>https://tauri.app/ko/blog/2023/06/15/tauri-board-elections-and-governance-updates2023-06-15T00:00:00.000ZThe Tauri Programme is celebrating it's two year anniversary of Tauri becoming a programme within The Commons Conservancy as well as the one year milestone of the Tauri 1.0 release. This also means we're preparing for the next round of Tauri Board Director elections to welcome in the next chapter of Tauri.
We wanted to celebrate these milestones but also use this as a chance to reflect on how we've grown since the Tauri 1.0 launch and how to continue evolving Tauri. The Tauri Working Group has been building the next iteration of the governance model for the past several months to make it more accessible for new and existing contributors, and ultimately sustainable for the future of Tauri.
The Tauri Board of Directors is the central decision-making body for the Tauri Programme and is responsible for the overall health and stability of the Tauri Programme. Additional details can be found on the Tauri Governance page.
In order to provide continuity from one year to another, the elections of seats are staggered over the course of 2 years. This means that one year a portion of the seats are elected, and the following year the remaining seats are elected. A Tauri Director seat is an elected position with a term of 2 years. The Board has a minimum of 3 Directors and a maximum of 7. This year there are 5 seats open for election.
This year we'd like to focus on diversifying the Tauri Board. We're looking for candidates that may be a developer who's worked on Tauri, a stakeholder in Tauri's future, experienced individuals from industry, or a person with a passion for regulatory and legal aspects within open source. If any or all of these are of interest to you then we'd invite you to apply as a candidate.
There are 3 steps to express interest and apply for candidacy:
Learn about the role of a Tauri Board Director on the Governance page.
Prepare a written introduction about yourself that covers who you are, your history and relevance for Tauri, and what you would like to bring to the Board.
Apply prior to July 2nd, 2023 by emailing board@tauri.app, messaging the @board role on the Tauri Discord, or by directly messaging Daniel Thompson-Yvetot on Discord (@Denjell) or email (denjell@tauri.app).
Voting will take place starting on July 5th through July 12th, 2023 where Tauri Working Group Members will cast their votes. We're expecting to announce the results on or before July 16, 2023. If elected, we'll ask you to sign this pledge if you haven't done so previously.
If you have any questions or would like more information please reach out by emailing board@tauri.app, messaging the @board role on the Tauri Discord, or by directly messaging Daniel Thompson-Yvetot on Discord (@Denjell) or email (denjell@tauri.app).
Tauri has always had a Working Group that's responsible for the day-to-day direction and execution, but as we grew it became clear that we needed to evolve the Working Group. We also wanted to give new Working Group members a clear places to jump in and get started. We thought of how we could achieve this while building and iterating on the existing framework. With these goals in mind, we created two new concepts within the Working Group: Domains and Domain Leads.
A Domain in the Working Group represents a specific area of interest. We're starting with these 4 domains:
Development: Developing and maintaining the Tauri software
Community: Looks after the broader community resources and the public presence of Tauri
Governance & Guidance: Involved with all things organizational in nature
Operations: Responsible for all the tooling and infrastructure Tauri needs to get work done
This gives clear entry points for a new member of the Working Group to jump into right away. It also allows us to continue growing our core competency of core Tauri development while giving additional focus to all areas which support the Tauri organization as a whole. Each of these domains will be represented by Domain Members and Domain Leads, but membership is not mutually exclusive.
Within a domain, there is a position for 2-3 Domain Leads. These are core individuals in the Working Group that are critical to their respective Domain. They help by setting the direction and priorities for their domain while also serving as key leaders for the Working Group as a whole.
Leads are appointed twice a year, in the spring and in the fall. Since this governance update is being rolled out mid-term we're appointing interim leads that have been key members of the Working Group. This fall we'll reflect on the initial experience and host a new round to appoint the Domain Leads. We'll announce information for that process when we're closer to "appointment season".
We hope that these changes provide the foundation to continue the journey the Tauri Working Group has been on while also catalyzing the continued growth and sustainability of the organization. You can learn more about these updates in the Governance and Guidance repo on GitHub. Give us your feedback on the GitHub Discussion for this post.
]]>Robin van Bovenhttps://github.com/BeanowJacob Boldahttps://github.com/jboldaLorenzo Lewishttps://github.com/lorenzolewis<![CDATA[Announcing Tauri 1.4.0]]>https://tauri.app/ko/blog/2023/06/14/tauri-1-42023-06-14T00:00:00.000Z
The Tauri team is excited to announce the 1.4 release. This version includes several new features and important bug fixes such as CLI completions, unit testing capabilities and Windows installer improvements.
Tauri 1.4 still has a minimum supported Rust version of 1.60, but due to some dependency incompatibility issues we are no longer pinning the patch version of the time, ignore, and winnow crates. If you are still using Rust 1.60, you will need to pin these versions manually with cargo update.
The tauri crate now exposes the test module under the test Cargo feature. This module is still unstable but allows you to unit test your application by creating a tauri::App instance that can execute without spawning windows. See the documentation for more information and examples.
It was performed during paid time at CrabNebula Ltd. and we are grateful to be able
to spend parts of our work time contributing to the open source project and making it a more secure environment ❤️.
For this release we manually audited a selection of PRs
instead of all PRs coming into the release.
The new approach means the reviewers and developers need to decide on their own if a PR is introducing any security relevant change.
A review can be triggered by anyone involved in the change, by adding a label to the PR.
For the first time we also audited after the official release due to time constraints.
This resulted in a security patch release, fixing the only impactful issue (CVE-2023-34460) discovered during auditing.
In general this release was more focused on fixing and improving the NSIS features and introduced less new features and security relevant changes.
It is internal in the sense that we are also involved in the project itself but performed with the help of an external entity. Calling it external security audit would create false impressions.↩
The Tauri CLI can now create Windows application installers using NSIS. This new bundle target is also available on macOS and Linux as an experimental feature, so you can cross-compile your Windows installer. Documentation on the latter will be published soon.
The internal audit was performed by @tweidinger and @chippers, who are involved in most security topics at the Tauri project. It was performed during paid time at CrabNebula and we are grateful to be able to spend parts of our work time contributing to the open source project and making it a more secure environment ❤️.
We manually audited over 45 PRs. Some PRs (e.g. #5544) lead us to diving into very old RFCs (RFC6068 and RFC3966), NSIS documentation (e.g. #6039) and many other external resources. We documented questions, notes and findings in markdown files and shared these notes with the responsible developers to ensure appropriate fixes.
The changes from a security perspective and findings of the audit are summarized in the following sub-sections.
This was by far the most impactful and time consuming PR we investigated. This PR introduces a streamlined way for applications to allow external domains access to the Tauri IPC layer1 and usage majorly impacts the security model of a Tauri application. Security impact2 depends on exposure3 of the feature, enabled Tauri commands and the capabilities of an adversary4.
We consider this new feature similar to driving a very fast race car without any safety features enabled and urge developers to very very carefully consider if they really need this exposure.
Before this addition was merged, a semi-known vulnerability was (ab)used by application developers to achieve the same functionality. To make the whole community aware of this risk we published a security advisory to give a heads up. Applications are affected if they allow users to navigate to arbitrary domains or have an open redirect vulnerability5. If you implement such a feature you should update to the 1.3 release as fast as possible.
The initial PR changes allowed wildcards (https://*) and glob patterns, which we believe are helpful but shouldn't be exposed to all Tauri developers. We concluded that the risk of over-exposure, like the allow list toggle to enable all Tauri API endpoints, does not justify this permissive exposure. The final implementation allows to configure specified (sub)domains6 (eg: example.com) to gain remote access to the Tauri IPC.
The few edge use cases, which require wildcards or even further exposure can be implemented by custom Rust code which is able to dynamically modify the IPC access. We now expose this remote IPC scope in a similar fashion as the fs or http scope.
Assuming a fully trusted web service on https://trusted.example it is now possible to configure the security scope to allow certain windows or even plugins access to custom implemented commands and optionally the inbuilt Tauri API:
Shared domains MUST NOT be used for this in any circumstances. We do not limit access to paths or specific files. You can only scope with trusted(sub)domains6. Another very risky catch is that developers must be sure that the domain ownership does not change over the lifetime of the application. Domain takeover could lead to compromised user devices.
Due to certain webview features not enabled nor being accessible, a community contribution introduced the possibility to add additional arguments to the webview process, which is created in a new window.
This feature was exposed to the frontend in the window endpoint. We found that this exposure was highly risky, as most webviews have very impactful features and flags that can be allowed via the process arguments.
All of the following threat model assumptions are based on the Tauri window creation being allowed in the allowlist of the tauri.conf and therefore exposed to the frontend. This PR affects Windows only, therefore there is no impact on the other supported operating systems.
An adversary with the capabilities to create windows and pass command line arguments to the webview can elevate their privileges to escape the strict sandboxing of Tauri and the webview.
The flags allow to enable several dangerous webview features, from loading profiles outside of the current default profile folder (stealing browser sessions from the device) to disabling security measurements of the webview (eg: certificate validation, sandboxing, webdriver/headless mode, device management endpoints, ...).
The feature was then changed to be only exposed on the rust side. Tauri application developers can use this to implement custom commands to invoke webview windows with use case specific arguments.
We found that the components to extract remote bundler files like the Webview2 installer were manually extracting single files with the extract_zip function, which uses ZipFile::name() instead of ZipFile::enclosed_name() as recommended in the documentation. Files which had names like ../../../../foo.sh could be extracted outside of the intended directory on the filesystem. This kind of vulnerability is called ZipSlip.
As the function was only used on verified and trusted files the impact here was nearly zero. Regardless we changed the implementation to facilitate the proper extraction method.
The bundler was not escaping content passed to the handlebars::Handlebars::render(), which could cause unwanted code execution during the bundler phase. This was also a low impact issue but was promptly fixed.
On Windows, the msi installer's Launch App checkbox will be checked by default. #5871
Add --png option for the icon command to generate custom icon sizes. #5246
On Windows, change webview theme based on Window theme for more accurate prefers-color-scheme support. #5874
Remove default features from Cargo.toml template. #6074
Add a method to the WindowBuilder struct to recreate windows from tauri.conf.json configurations.#6073
Improve the error message when rustc couldn't be found. #6021
Added support for pre-release identifiers and build numbers for the .msi bundle target. Only one of each can be used and it must be numeric only. The version must still be semver compatible according to https://semver.org/. #6096
Add --ci flag and respect the CI environment variable on the signer generate command. In this case the default password will be an empty string and the CLI will not prompt for a value. #6097
Skip the password prompt on the build command when TAURI_KEY_PASSWORD environment variable is empty and the --ci argument is provided or the CI environment variable is set. d4f89af18d69fd95a4d8a1ede8442547c6a6d0ee
Fix serialization of js Map when used in invoke. #6099
Inter-Process Communication, in this instance the communication between the Tauri core and the frontend code run inside the webview.↩
Security Impact: What is the theoretical biggest impact of this threat combination? This highly depends on correct scoping of Tauri API endpoints and hardening of custom implemented Tauri commands.↩
Exposure: Describes the exposed scope items of this feature to either an user or adversary. It is possible to restrict exposure to only certain domains, windows or only to custom implemented commands.↩
Adversary Capabilities: Which kind of privileges has the adversary? Can range from tricking user into entering malicious input to code execution in the frontend via cross-site-scripting (which is the highest privilege for frontend code in our case). Common capabilities are described in the OWASP documentation.↩
An application can be exploited if it parses user input for making an URL redirection decision, which is then not properly validated.Wikipedia Source↩
A new alpha release for the 2.0 has been published. This release includes all changes from the upcoming Tauri 1.3 release, an important breaking change on the HTTP client and native mobile capabilities for Tauri plugins.
The default HTTP client using attohttpc has been removed due to issues with the development server proxy on Windows. All reqwest-* feature flags have been removed because reqwest is now the client we use.
A Tauri plugin now can access iOS via Swift and Android APIs via Kotlin or Java code, simplifying usage of platform interfaces such as camera or geolocation. To bootstrap the iOS and Android projects on an existing plugin, run tauri plugin ios add and tauri plugin android add. New plugins automatically include all the configuration needed to write native mobile code.
Here's an example of a plugin that takes a string value and resolves an object:
Android plugin:
ExamplePlugin.kt
package com.plugin.example import android.app.Activity import app.tauri.annotation.Command import app.tauri.annotation.TauriPlugin import app.tauri.plugin.JSObject import app.tauri.plugin.Plugin import app.tauri.plugin.Invoke @TauriPlugin class ExamplePlugin(private val activity: Activity): Plugin(activity) { @Command fun ping(invoke: Invoke) { val value = invoke.getString("value") ?: "" val ret = JSObject() ret.put("value", value) invoke.resolve(ret) } }
iOS plugin:
ExamplePlugin.swift
import UIKit import WebKit import Tauri class ExamplePlugin: Plugin { @objc public func ping(_ invoke: Invoke) throws { let value = invoke.getString("value") invoke.resolve(["value": value as Any]) } } @_cdecl("init_plugin_example") func initPlugin(name: SRString, webview: WKWebView?) { Tauri.registerPlugin(webview: webview, name: name.toString(), plugin: ExamplePlugin()) }
]]>Lucas Nogueirahttps://github.com/lucasfernog<![CDATA[create-tauri-app Version 3 Released]]>https://tauri.app/ko/blog/2023/03/01/create-tauri-app-version-3-released2023-03-01T00:00:00.000Z
A new major version of create-tauri-app has been released. This version adds support for the alpha version of Tauri 2.0, the ability to initialize iOS and Android projects and removes some less commonly used templates to make the project more maintainable.
The first alpha version of Tauri 2.0 was published almost 3 months ago which brought initial mobile support for Android and iOS. Previously there wasn't an easy way to create a new project to test either the changes in the alpha version nor the mobile support. Well, that ends now!
Starting with version 3 of create-tauri-app, you can now pass --alpha flag and it will bootstrap an app that uses tauri@2.0.0-alpha. When adding the --alpha flag it will automatically prompt you if you'd like to add mobile support. You can also use the --mobile flag to automatically make it mobile compatible.
With version 2 of create-tauri-app we also focused on improving the flow and experience of the prompted questions.
Previously the second prompt would ask "Choose your package manager". This was a bit vague and could leave some with unanswered questions:
What is cargo?
Is it a new Node.js package manager?
Why choose it over pnpm or yarn?
This would be even more vague if we decided to add a new frontend language (such as a webassembly Golang web application). We added a prompt asking to choose the package manager to ask which language would you prefer. It looks something like this:
? Choose which language to use for your frontend › Rust ❯ TypeScript / JavaScript (pnpm, yarn, npm)
After choosing the frontend language create-tauri-app will then prompt for package manager to use if the language has multiple (such as Node.js with npm, yarn, and pnpm).
Another prompt that we felt problematic was the template selection prompt. It contained a lot of templates to choose from and was only growing with time:
We decided to split this up into 2 prompts. The first will ask which UI template to use:
✔ Choose your package manager · pnpm ? Choose your UI template › Vanilla ❯ Vue Svelte React Solid Angular Next SvelteKit ClojureScript Preact
And then the second will then ask any additional choices that are specific to that template (such as choosing between TypeScript or JavaScript for Vue):
✔ Choose your package manager · pnpm ✔ Choose your UI template · Vue - (https://vuejs.org) ? Choose your UI flavor › ❯ TypeScript JavaScript
Even with these refinements the list of templates was still quite large and would only grow over time. The next thing to look at was the list of templates themselves.
When create-tauri-app version 2 was launched it quickly received PRs to add additional templates beyond what it originally launched with. While it was exciting to receive so much support from the community, it did bring up a couple of new challenges:
It made it almost impossible to fit them in a single prompt
Maintaining all the templates was becoming more difficult
It was a hard balance between showing how flexible Tauri is but also making sure that the project was maintainable and had the DX that we wanted.
We decided to focus on the most popular frontend frameworks and used guidance from community surveys like The State of JS and our own Tauri community feedback. With this we removed the next, next-ts, preact, preact-ts, clojurescript, svelte-kit and svelte-kit-ts templates and also closed PRs which aimed to add more templates.
We want to make sure that we offer a place for the Tauri community to provide their own templates for the frameworks they love. The templates section of awesome-tauri is just the place for that. We invite the community to submit a PR to the awesome-tauri repo with their templates so that they can be shared with the Tauri community. We'll also be creating a section on the Tauri website to highlight and showcase these community templates.
If you'd still like to use the previous templates from version 2 of create-tauri-app they are still published to npm and crates.io. Here's how you can use a previous version:
However, as time goes, these templates will become out of date as Tauri and the frontend frameworks move forward. We'd recommend you look at the community templates in the awesome-tauri repo and welcome submissions if something is missing.
We hope that these changes make it easier for the community to try out the alpha and beta versions of Tauri 2.0 and also make the process to create a new Tauri app easier for everyone! We'd love to hear your feedback and invite you to join the conversation on the GitHub Discussion for this post.
]]>Amr Bashirhttps://github.com/amrbashir<![CDATA[Tauri Community Growth & Feedback]]>https://tauri.app/ko/blog/2023/02/09/tauri-community-growth-and-feedback2023-02-09T00:00:00.000Z
This year, we had over 600 responses to the Tauri Community Survey (over 3x more than the previous survey's responses). We'd like to extend a very special thank you to Wu Yu Wei and DK Liao for translating the survey from English into Simplified and Traditional Chinese so that we could include more people from the community and their feedback in the survey. You can download the public data for the survey here.
We've heard your feedback and have started a couple of projects to directly address it. The first one we'd like to talk about is search.
Without searching, can you ever find something? And if your telescope is cracked, can you see the planets or stars? We know that our search lens was dusty and scratched; it felt sometimes like a roll of the dice, and some folks even resorted to using ChatGPT to find answers.
Search has been a project that we've taken a few runs at over the years, but we've also learned that it's not quite as easy as it first seems. Ken from the Tauri Working Group did inspirational work with the previous tauri-search project. He created a lot of the foundation and research in the previous project for us to understand what goes into search.
With the next iteration of search, we had three goals in mind:
First, we needed to choose a backend search engine to store and serve the search index. When evaluating search engines, we wanted to make sure we used something that shared our values of open source software and a small footprint. After comparing and researching players in the search market (and also learning from our previous approach with Meilisearch), we decided on Meilisearch because we knew it fit both of those goals.
We decided to partner up with Meilisearch to use their engine and their Meilisearch Cloud offering to host our search engine. They graciously sponsored a hosted plan that they manage for us. This lets us focus on building Tauri, knowing that the maintenance and upkeep of the search engine are in trusted hands.
The next piece of the puzzle is to actually get the content indexed and ingested into the search engine. Fabian from the Tauri Working Group set up the project using the docs-scraper project from Meilisearch.
Previously, we had a setup that would take our markdown documentation and JavaScript AST and use that to build the search index. Although it led to much faster indexing times, it meant we had a tightly coupled dependency between search indexing and the way we rendered content on our website. This would sometimes lead to the search results getting out of sync with the content on the live website. In order to update the website or optimize the indexer, someone would need to have knowledge of both, making it more difficult to maintain.
With the current version of the scraper, we can handle all of the configuration and tweaking of results with a single JSON file and let the scraper take care of the rest. We set up a GitHub action that would perform the scraping as part of our CI/CD pipeline and then send those results to our Meilisearch Cloud instance.
The final step was to create the frontend UI that people visiting tauri.app would interact with. Amr from the Tauri Working Group created the meilisearch-docsearch project to help with this. This repo is compatible with Meilisearch 1.0 (we're using it now on tauri.app).
It's inspired by the algolia/docsearch and meilisearch/docs-searchbar.js projects that provided a very solid foundation to begin with. The beauty of open source is that we can learn from each other and use that to give back to the ecosystem.
To talk through some of the details, I'll hand it over to Amr:
The meilisearch/docs-searchbar.js project was good, but I always felt it could use some improvements to get feature parity with algolia/docsearch. I also felt we could help with an update to help with UI/UX.
On mobile screens, it needed UI/UX improvements so that the search results wouldn't go off-screen.
On desktop, the search results would normally appear under the search input, which in the case of tauri.app was placed on the top-right. This caused a bad UX because you'd have to keep moving your eyes between the page content in the middle and the search results in the top-right.
It is missing a common keybinding. ctrl/command + K to start the search, ctrl/command + K is pretty common in the JS ecosystem documentation sites. It also doesn't have the ability to select text on the page and then trigger a search directly from that text.
I have been always a big fan of algolia/docsearch UI/UX. It checked all the features on my list, and I always wanted to have that for tauri.app. In fact, several months ago, I tried to change the meilisearch/docs-searchbar.js CSS on our end to improve point 1 and 2 above but I stopped mid-way because of the difficulty of building on top of existing css and fighting for highest specifity (plus CSS is hard 😉). Other projects also couldn't benefit from our modifications in an easy way.
Later, we were discussing how to improve the search UI and UX, and we decided that we could improve on the base Meilisearch UI. That project turned into meilisearch-docsearch.
The good news is that all of these changes are live! You can see the new search on tauri.app. We'd love to hear your feedback on what works and what could use improvement in the GitHub Discussion for this blog post. We invite you to not only report bugs, but also if your search result wasn't expected or should be higher up on the list of results.
We'd like to wrap up by extending a special thank you to Ken for the original Tauri Search project, Amr for the meilisearch-docsearch project, Fabian for writing the revised index scraper and continuous testing, Meilisearch for their partnership and the Meilisearch Cloud instance and finally the Tauri community for their continual feedback to help us drive Tauri and the community forward.
Over the next year, the Tauri Working Group is excited to continue working towards Tauri 2.0. We also have a website rewrite in the works that we'll be launching in beta this spring. If you'd like to get involved, you can reach out to us in the Tauri Discord and follow us on Mastodon and Twitter.
]]>Lorenzo Lewishttps://github.com/lorenzolewisAmr Bashirhttps://github.com/amrbashir<![CDATA[Migration to webkit2gtk-4.1 on Linux port]]>https://tauri.app/ko/blog/2023/02/03/tauri-2-0-0-alpha-32023-02-03T00:00:00.000ZHello everybody! We just released Tauri v2.0.0-alpha3 recently. While it doesn't bring any major feature, it does bring some huge impacts on Linux port.
We will use WebKit2GTK–4.1 in 2.0 from now on.
If you are using Tauri version 1.x, there's nothing to worry about. Everything you need is still the same.
But if you are using Tauri version 2.0 alpha version starting from alpha.3, you will need to install the new WebKit2GTK package with API version 4.1.
We will update the prerequisites in our site soon. But if you want to know how to install such version, here are some instructions from wry:
# On Arch Linux / Manjaro: sudo pacman -S webkit2gtk-4.1 # On Debian / Ubuntu: sudoaptinstall libwebkit2gtk-4.1-dev # On Fedora: sudo dnf install webkit2gtk4.1-devel
The main difference between version 4.0 and 4.1 are the soup library. WebKit2GTK-4.0 uses soup2 and WebKit2GTK-4.1 uses soup3.
So if you didn't use any soup2-specific APIs, your applications should continue to work fine.
The reason behind this change is because we aim to add flatpak support, but Gnome runtime uses webkit2gtk-4.1.
There are also some subtle bugs like this that only happen in soup2 and they can be fixed by upgrading to soup3.
What other breaking changes we are going to expect?
The major one will be the MSRV. With Tauri v2.0.0-alpha.3 released, MSRV is bumped to 1.64. We will also update windows-rs in the future.
This Rust version should satisfy the latest version of windows-rs.
We do plan to update our MSRV with minor releases after 2.0. This could ease the friction to stick to any fixed Rust version while updating dependencies.
]]>Wu Yu Weihttps://github.com/wusyong<![CDATA[Announcing the Tauri Mobile Alpha Release]]>https://tauri.app/ko/blog/2022/12/09/tauri-mobile-alpha2022-12-09T00:00:00.000Z
Tauri mobile is here! The first alpha release 2.0.0-alpha.0 has been published.
You can adapt your existing desktop application to run on mobile or start a fresh project.
Tauri runs on the connected device or starts an emulator if available.
The Tauri team is happy to announce the 1.2.0 release. It includes a security fix, so we encourage new and existing users to update to one of the fixed versions. Other changes were internally audited and no security issues were found.
Make sure to update both NPM and Cargo dependencies to the 1.2.0 release. You can update the NPM dependencies with:
This release includes a patch for a security vulnerability reported by MessyComposer.
Due to incorrect escaping of special characters in paths selected via the file dialog and drag and drop functionality, it was possible to partially bypass the fs scope definition.
It was not possible to traverse into arbitrary paths, as the issue was limited to neighboring files and sub folders of already allowed paths.
A successful bypass requires the user to select a pre-existing malicious file or directory during the file picker dialog and an adversary controlled logic to access these files. This means the issue by itself can not be abused and requires further intentional or unintentional privileges.
The patch is also available in 1.0.7 and 1.1.2. See the advisory for more details.
This release includes a minimum supported Rust version bump. Tauri now requires at least Rust 1.59 to compile. This was necessary due to several dependency updates that demanded this change.
The Linux webview binding has been updated and it now has support to custom protocol headers when running on webkit2gtk version 2.36 or above. This fixes CORS issues on production when manually fetching a build asset.
We finally merged one of the most awaited pull requests, introducing the titlebar style configuration. Your application can now define a transparent or overlay titlebar, hide the window title text and define the window to accept first mouse events so it can be focused immediately after receiving a click event to be dragged.
Window with overlay titlebar style
Window with transparent titlebar style (uses the window background color)
Other changes
There are a lot of smaller changes and bug fixes in this release. You can see a summary of the release notes in the following sections. The complete changelog can be found on the releases page.
Use correct code ja-JP for japanese instead of jp-JP (#5346)
Clear environment variables on the WiX light.exe and candle.exe commands to avoid "Windows Installer Service could not be accessed" error. Variables prefixed with TAURI are propagated. (#4819)
Fix regression in SystemTray::with_menu_on_left_click (#5235)
Fix regression introduce in tauri@1.1 which prevented removing tray icon when the app exits on Windows (#5245)
Fix access to the WebviewWindow.getByLabel function in a tauri://window-created event listener (#5458)
Fix a deadlock when modifying the menu in the on_menu_event closure. (#5257)
]]>Lucas Nogueirahttps://github.com/lucasfernog<![CDATA[Announcing tauri-egui 0.1.0]]>https://tauri.app/ko/blog/2022/09/19/tauri-egui-0-12022-09-19T00:00:00.000ZThe Tauri team is pleased to announce the first release of tauri-egui.
egui is a GUI library written in Rust. It leverages an OpenGL context via glutin.
tauri-egui is a Tauri plugin that connects with the Tauri runtime event loop to allow you to create glutin windows via our glutin fork
and use egui through our egui-tao integration.
To use egui, all you need to do is implement the tauri_egui::eframe::App trait to render elements using the egui API. In the following example, we will create a login layout.
Define the struct that will be used to render the layout:
Implement tauri_egui::eframe::App to use the egui APIs:
impleframe::AppforLoginLayout{ // Called each time the UI needs repainting // see https://docs.rs/eframe/latest/eframe/trait.App.html#tymethod.update for more details fnupdate(&mutself, ctx:&egui::Context, frame:&muteframe::Frame){ letSelf{ heading, users, user, password, password_checker, tx, .. }=self; let size =egui::Vec2{ x:320., y:240.}; // set the window size frame.set_window_size(size); // adds a panel that covers the remainder of the screen egui::CentralPanel::default().show(ctx,|ui|{ // our layout will be top-down and centered ui.with_layout(egui::Layout::top_down(egui::Align::Center),|ui|{ // we will start adding elements here in the next sections }); }); } }
Now that we have created the layout, let's put it on a window and show it in the Tauri application:
usetauri::Manager; fnmain(){ tauri::Builder::default() .setup(|app|{ app.wry_plugin(tauri_egui::EguiPluginBuilder::new(app.handle())); // the closure that is called when the submit button is clicked - validate the password let password_checker:Box<dynFn(&str)->bool+Send>=Box::new(|s| s =="tauri-egui-released"); let(egui_app, rx)=LoginLayout::new( password_checker, vec!["John".into(),"Jane".into(),"Joe".into()], ); let native_options =tauri_egui::eframe::NativeOptions{ resizable:false, ..Default::default() }; app .state::<tauri_egui::EguiPluginHandle>() .create_window( "login".to_string(), Box::new(|_cc|Box::new(egui_app)), "Sign in".into(), native_options, ) .unwrap(); // wait for the window to be closed with the user data on another thread // you don't need to spawn a thread when using e.g. an async command std::thread::spawn(move||{ ifletOk(signal)= rx.recv(){ dbg!(signal); } }); Ok(()) }) .run(tauri::generate_context!()) .expect("error while running tauri application") }
Here's how it will look on all platforms:
To customize the look and feel of your egui application, check out the Context#set_style API.
After 113 pull requests and nearly two months of work, the Tauri team is pleased to announce the 1.1.0 release. The changes were internally audited and no security issues were found.
This release includes a patch for a security vulnerability reported by @martin-ocasek. The readDir function was able to return entries outside the configured scope when a symlink is found. The patch is also available in Tauri 1.0.6. See the issue on GitHub for more details.
We have been recommending to use the tauricon project to generate icons for your Tauri application using a single source PNG. Several issues have been reported, and we decided to "Rewrite It In Rust" to enhance its stability. This allowed us to move this functionality to the main Tauri CLI, so now you can use the tauri icon command.
The Tauri CLI can now be installed using cargo-binstall, a mechanism to download and install pre-built Rust binaries. The binaries are available for the main targets and can be installed with:
$ cargo install cargo-binstall $ cargo binstall tauri-cli $ cargo tauri dev # run any Tauri command!
The system tray APIs (previously only available in tauri::Builder::system_tray) can now be used at runtime with tauri::SystemTray giving you control over its lifetime and even create multiple trays.
Here's a quick example on how to use it:
usetauri::{Builder,CustomMenuItem,SystemTray,SystemTrayEvent,SystemTrayMenu}; Builder::default() .setup(|app|{ let handle = app.handle(); SystemTray::new() .with_id("main") .with_menu( SystemTrayMenu::new().add_item(CustomMenuItem::new("quit","Quit")) ) .on_event(move|event|{ let tray_handle = handle.tray_handle_by_id("main").unwrap(); ifletSystemTrayEvent::MenuItemClick{ id,..}= event { if id =="quit"{ tray_handle.destroy().unwrap(); } } }) .build(&handle) .expect("unable to create tray"); });
In the 1.0 releases Tauri supports the JSON configuration format by default, and JSON5 when the config-json5 Cargo feature is enabled, meaning the following configurations are valid:
This release includes some dependency updates that must be handled in your app if you implement platform-specific functionalities using these crates. The most important updates are:
windows updated to 0.39.0
webview2-com updated to 0.19.1
raw-window-handle updated to 0.5.0
Make sure you also update plugins such as window-vibrancy and window-shadows to latest.
There are a lot of smaller changes and bug fixes in this release. You can see a summary of the release notes in the following sections. The complete changelog can be found on the releases page.
Validate updater signature against configured public key
Return an error if a sidecar is configured with the same file name as the application.
Keep the created windows in a RefCell instead of a Mutex, avoiding deadlocks
Prompt for beforeDevCommand and beforeBuildCommand in tauri init.
Use cargo metadata to detect the workspace root and target directory.
Allow configuring the before_dev_command to force the CLI to wait for the command to finish before proceeding.
Avoid re-downloading AppImage build tools on every build.
Retain command line arguments in api::process::restart
Enhance the dialog style on Windows via the manifest dependency Microsoft.Windows.Common-Controls v6.0.0.0.
Rerun codegen if assets or icons change
Only rewrite temporary icon files when the content change, avoid needless rebuilds.
]]>Lucas Nogueirahttps://github.com/lucasfernog<![CDATA[Tauri Programme Turns 1 and Board Elections]]>https://tauri.app/ko/blog/2022/07/12/tauri-programme-turns-1-and-board-elections2022-07-12T00:00:00.000ZThe one year anniversary for Tauri becoming a programme within The Commons Conservancy is upcoming on the 16th of July! On that anniversary, two of our Directors on the Tauri Board will be at the end of their first half-term. The Board will hold an election on the 15th of July to decide the Directors for the next two year term.
The Tauri Board has a minimum of three, and a maximum of seven people. Right at the start we've had seven people come on board. Meaning we can't add any more people during this election. So if you're applying it means you'll compete with the two project founders for a seat on the Tauri Board.
Honestly those are big shoes to fill! So to avoid unnecessary disappointment, in this election we decided to add a requirement: You must be currently part of a working group to apply as a candidate.
If you're still with me, then here are some additional details:
Please notify the board before July 15th 00:00 UTC if you would like to apply as a candidate.
You can mention @board on Discord, or DM Beanow#5887 if you want your application to be kept private within the Board.
Optionally, you can include a short motivation for your application.
If there are multiple candidates, the Tauri Board will vote for their preferred candidates.
The Directors running for office again will have half a vote deducted from votes in their favor (one for each consecutive term served).
After voting on July 15th we'll share the results.
The existing Directors applied for another term and there were no additional applicants. Meaning no vote was necessary to select between candidates. For the Chair position Daniel ran as the only candidate.
The Tauri Board then voted unanimously in favor of the following:
The Board appoints Daniel and Lucas for an additional full term (2 years) as Board Directors, starting the 16th of July.
The Board appoints Daniel as Chairperson for the next term (1 year), starting the 16th of July.
Another election will be held around the same time July next year, now with extra time to apply and for the Board to vote. We'll announce the specifics in due time.
]]>Robin van Bovenhttps://github.com/Beanow<![CDATA[Tauri 1.0 Release]]>https://tauri.app/ko/blog/2022/06/19/tauri-1-02022-06-19T00:00:00.000Z
Tauri is an app construction toolkit that lets you build software for all major desktop operating systems using web technologies. The core libraries have been written for you in Rust and the user interface can be written using virtually any frontend framework. It includes an optional and tree-shakeable JavaScript API for comfortable low-level system access, a desktop binary bundler with code signing and artifact verification, a secure updater to keep your users on the latest version, an extensive plugin system, and support for OS-level integrations such as notifications and app trays.
Tauri is as simple to use as it is easy to extend. For those new to the Rust programming language, Tauri provides a comfortable learning environment that will grow with you. Once you have installed Rust, creating your first app is a mere running of create-tauri-app. But you don't have to use Node.js at all, if you would prefer to remain in the safety and comfort of 100% Rust.
Tauri allows you to build "local first" applications without a webserver, so your users don't have to share their data with big tech. Using local databases and rust based cryptography have never been easier.
The apps you make are lean and performant, which reduces electricity, storage space, and general natural resource consumption. Every byte saved is a leaf on a tree that gets to grow.
To illustrate this, we compiled some numbers on the ecological impact of your app's size. As you can see, even small increases in size have a hefty impact on the environment!
Although the carbon absorption capacity can vary, it is generally considered that a tree can store about 167 kg of CO2 per year, or 1 ton of CO2 per year for 6 mature trees (https://climate.selectra.com/en/news/co2-tree)
We know that open source software is a means of fostering equality and collaboration, which is why we placed the ownership of the code at the Commons Conservancy. You can rest assured knowing that the code base will never be rug-pulled or locked behind open-core pay-to-play feature gates. We believe in open collaboration and safe spaces for all. We have an open working group, accessible to any competent contributors. And we love you all. ❤️
Here are some of the things people are saying about Tauri:
"Spacedrive had to feel native across all platforms, all while being lightweight, instant to launch and extremely fast to use. This just wasn't possible with a web-based UI — until now, thanks to Tauri." - Jamie Pine, Spacedrive Founder
"Tauri has the potential to unlock a new generation of desktop software that feels native to users but is as easy to build as web apps."
"Tauri stands to reduce the disastrously negative environmental costs of bloated and memory-hogging applications on the internet by orders of magnitude. Any rough approximation of monetary value that could result in, would easily reach hundreds of billions in cost savings for our modern era of grossly underutilized local compute and storage resources."
"With its security-focused design and low memory footprint, Tauri is the electron alternative we've been waiting for. Tauri has allowed us to build a more secure, more performant desktop app while using the same web technologies, which we love. Thanks to the team for their amazing work! P.S.: Can't wait for mobile support!"
You can visit our code base, file a bug-report, request a feature, or join the discussion on GitHub. There's lots of things that people make, and visiting the awesome-tauri repo on GitHub is a great place to discover and share. If you need support or just want to hang out, you can join our Discord server.
Tauri is one of the top 200 projects on GitHub in all programming languages.
People love to discuss what is great and terrible about Tauri on orange websites:
Fresh off the heels of the 1.0 release, the team is already setting our sights on the next steps for Tauri. While we continuously work on improving our documentation, we're also working on:
Mobile support for both iOS and Android
Alternative renderers
IPC enhancements to enable improved debugging
Runtime plugins
Support for additional bindings in other languages
We're also inspired by the community to see which features are being used and what new features will enable them to develop even more amazing applications. Your feedback is the most important thing to Tauri's future innovation!
A special thanks to all our contributors who volunteered their precious time to make Tauri awesome and all our sponsors whose generous donations made Tauri possible (and financed a large portion of our audit!)!
The support of industry giants has been really helpful keeping the lights on. Here's an alphabetical list:
Cloudflare for sponsoring unlimited workers for the OSS updater service (coming soon)
DigitalOcean for comping the droplets that run our bots and search
What feature are you most excited about?
The customizations we offer for the window but that's because it is what I mostly worked on. I am also excited about how Tauri will change the mindset of some people and help them build secure apps by default.
What is your proudest moment/contribution with Tauri?
Probably when I removed about 20 lines of code in favor of only 3 lines. I wrote both and that's why it felt special, because it was an indicator of how much I've grown as a developer.
What feature are you most excited about?
Is "All of them" a valid answer?
What is your proudest moment/contribution with Tauri?
Hmm, probably when I was asked to join the team. Fixing AppImages again and again and again is a close second...
What feature are you most excited about?
The auto-updater is pretty great but plugins are very dear to me and definitely the most promising feature of Tauri!
What is your proudest moment/contribution with Tauri?
Moderating the tauri-awesome repo. Seeing so many strangers build cool things with and for the work you've been doing. That's a really great feeling.
What feature are you most excited about?
It may sound silly but I love customizing stuff, so the possibility to make almost anything with our windows appearance is neat.
What is your proudest moment/contribution with Tauri?
Creating the foundations of Tauri docs as we know them today and trying to provide clean and easy to understand docs.
What feature are you most excited about?
Pretty much everything, getting Tauri out of a proof of concept to something stable is a huge milestone.
What is your proudest moment/contribution with Tauri?
TAO and all under laying features (menus, trays, etc..), benchmarks and the proof of concept for iOS.
What feature are you most excited about?
Overall resource efficiency. We've all been where we have a handful of "native" web apps running on our machine and it grinds to a halt. I'm ready for those small bundle sizes!
What is your proudest moment/contribution with Tauri?
The overall tauri.app website. It was in a really good place when I joined, but I knew I could help boost it up to the next level. Even things like picking a title for a sidebar can take a long time with all the discussions, but at the end of the day we all have the best output from putting our heads together.
Window with overlay titlebar style
Window with transparent titlebar style (uses the window background color)
