✅ Deploy Preview for tauri-v2 ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	701c2ba
🔍 Latest deploy log	https://app.netlify.com/sites/tauri-v2/deploys/664bcfaf2c86c200089e012b
😎 Deploy Preview	https://deploy-preview-1367--tauri-v2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 (🟢 up 1 from production) Accessibility: 100 (no change from production) Best Practices: 100 (no change from production) SEO: 92 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify site configuration.

Pulling this from the Discord conversation:

Btw @lorenzo speaking of Gitpod, how is contributing meant to work with that exactly? I mean when I wanna contribute I fork the repo, but now that Gitpod link in the README isn't valid anymore because it points to the main repo instead of my fork. One alternative could be to open gitpod based on the main repo, but now I need to be a smart Git user in order to change the upstream branch to my fork of the docs. Like, if everyone has write access to the main repo it's easy, then it's just open gitpod and start making new branches, but if we rely on forking then making PR's then it's kind of a pain

The flow I have in mind is that a person starts from our repo, they don't have a fork. GitPod, Codespaces, etc. are for those people who don't care about forking, cloning, setting up on their local machine, etc. It's for people who want to contribute a typo fix, a translation, etc. and not worry about all of that.

At least in VSCode locally, if I try to "push" to a repo that I don't have write access to it will suggest to me to fork it and open a PR which has been a flow that's worked for me (might need to confirm what that experience is through Gitpod/codespaces to confirm).

For that reason I'd suggest we set up protected branches and give the general public write access to branches starting with contrib/, then you can skip forking altogether, you just open Gitpod, run git checkout -b contrib/my-feature and bam, you're off to the races

I think my reply above addresses this a bit, but going to a put a few thoughts in general on this topic. In theory I love the idea of making it more collaborative and accessible for people to work together, but this could potentially have a lot of security things we have to think through (already had a bit of a scare with some PRs taking advantage of some actions a few months back).

Plus, contributors have the check box to "allow maintainers to edit this pull request" which I think will cover any "collaboration" I'd expect tbh. If we hit cases in the future where non-maintainers want to collaborate with each other then we can cross that bridge when we get there.

Going to do a bit of testing on this one later on. I'm still eye-ing that docker file a bit tbh and if it needs to have that many "convenience" things. But that one might be better to talk through a bit on Discord later.

One concern I have with this is commit signing. This doesn't necessarily change the difficulties we have with commit signing today. I'll maybe start a separate discussion on this to get some insight and feedback from the security team.

that many "convenience" things
It's mainly just these:

• Tabbing: I mean, you can get rid of it, but it's really nice for navigating the filesystem when you're a terminal user like myself
• Adding sudo: Just lets you run apt install and such in case something is missing in the devcontainer that people wanna use
• Apt clean: makes the image a bit smaller
• Package managers: We can remove the yarn and npm parts since we use pnpm. The line for pnpm is effectively the same as in starlight
• All the apt install stuff: Sets up git and git-lfs primarily which we should be using more than we seem to be, and installs some utilities for apt so that people don't run into issues when using it

The arguments at the top can be removed if you want to make it shorter but they're really not something you need to maintain, they just effectively expose those variables so that you can set them in devcontainer.json instead, in case someone needs to override them for some reason.

All in all I'd say that yes, we can take the image down to like 2-3 lines long, but the extras I've added don't actually involve any added maintenance, it's mainly just best practises for docker images and convenience stuff.

One concern I have with this is commit signing
This is something I had issues with too. In order for commit signing to work you really do need to one way or another get your credentials into Gitpod or wherever you add it, and I'm personally not at all comfortable with putting my GPG key in Gitpod. Sure I could make a new SSH key for contributing, but if that gets compromised I'll have to remove it from my account nonetheless resulting in all my signed commits no longer being signed.

Like, I don't see any solution for using Gitpod that doesn't involve putting keys in a place I'm not comfortable with, other than making unsigned commits first to your own fork of the project, then retroactively signing them, but that's not all that beginned friendly, which I feel is what Gitpod was mainly intended to solve.

The points make sense. I'll trust your guidance on this one as long as we keep maintainability front of mind.

On commit signing, I pinged security in Discord for their input but will also do it here.

@tauri-apps/wg-security Can you all give some input on yes/no to NOT require commit signing in the docs repo? I know that ideally we'd want it, but I'm really thinking of if there are any actual risks here that outweigh a (very high imo) barrier to entry for new people contributing.

We enforce commit signing for several reasons from my perspective but we don't have a central document describing the reasons (or at least I don't know of it). In general signing is just attribution of changes to someone.

For us this means whoever commits to our projects is actually identified properly through git commit signatures and not just through Github itself.
So what this protects against is that someone impersonates Lorenzo and is committing some hidden malware into the website/docs and we are all angry at him for doing such mean things. We would still have to merge these changes ;)

Signing does not protect us against missing reviews of the PR and merging malicious code. So the thing we are using commit signing for is for simple attribution of whoever wrote the code.

Having enforced reviews, ideally by 2 (core-)people, I think this is much more worth than enforcing commit signing for documentation changes from external contributors. However, signing should be the default and encouraged wherever possible. Unsigned code will then stick out and reviewers will have a more critical perspective when checking out the code.