Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feat] File path in Tauri Updater Signature Format #4467

Closed
LoonyRules opened this issue Jun 25, 2022 · 7 comments
Closed

[feat] File path in Tauri Updater Signature Format #4467

LoonyRules opened this issue Jun 25, 2022 · 7 comments

Comments

@LoonyRules
Copy link

Describe the problem

The Tauri Updater .msi.zip.sig file format contains the file path of the release build's .msi.zip on disk when being built.

untrusted comment: signature from tauri secret key
<some base64 that isn't easily decoded>
trusted comment: timestamp:1656152579	file:{{PATH_TO_PROJECT_AND_TARGET_RELEASE_BUNDLE_MSI_FILE}}_x64_en-US.msi.zip
+<another base64 that isn't easily decoded>

My question is: why? I do not want the path to my tauri project to be part of the signature at all, even if we did compile releases via CI/CD, of which is the ultimate goal.

Another question that is related to the format, why the untrusted comment: signature from tauri secret key?

Describe the solution you'd like

Remove the file path data if it's not directly required. If it is, figure out why and a replacement.

Alternatives considered

No response

Additional context

Initial conversation was made over on the Tauri Discord. This was then moved from Discord to GitHub to get more important from a Core Member.

@lucasfernog
Copy link
Member

lucasfernog commented Jun 27, 2022

The .sig contents should be the base64 encoded signature (I just double checked it). Can you share the tauri info output?

@LoonyRules
Copy link
Author

The .sig contents should be the base64 encoded signature (I just double checked it). Can you share the tauri info output?

Yes the .sig is base64 the data in my initial post is the base64 decoded contents.

@FabianLars
Copy link
Member

Btw here's where it comes from:

bin_path.as_ref().display()

@lucasfernog
Copy link
Member

I'll check with the author but I think we can remove that.

@LoonyRules
Copy link
Author

It feels like it's more for randomness but if that's the case a unique app id could just be generated instead and used.

@FabianLars
Copy link
Member

FabianLars commented Jun 27, 2022

i mean, having the file name itself is probably a good idea (edit: This is really common btw) and could be used to "confirm" the file is correct or whatever, but the whole path of the build system is a bit much 😅

@lucasfernog
Copy link
Member

I'll submit a PR with the change. Thanks for finding this, I never realized it :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants