Contents VS crev

I've been using Qubes for the past 2 years while going to school, and I found it really fun and helpful. A lot of professors had me download random closed source software from random websites during the pandemic, and it was easier to download it to a VM than to convince them about Free Software. More than that though it's been really helpful just for my own workflow. I can hit a keybind and start working from essentially a fresh linux install. It's easier to stay on task when each VM is designed to only do one kind of task. It's also nice having debian, fedora, windows, kali, and whonix all easily accessible on the same machine.

The main sticking point for me is that Qubes is reasonably secure from _myself_. I make mistakes. I first started using linux with an Ubuntu install that I broke a year later because I accidentally added in a space when typing `rm -rf ~/Arduino` which made it `rm -rf ~ /Arduino`. On Qubes I can `sudo rm -rf /` on the VM I'm using right now and not break a sweat. I have a keybind to spawn a disposable "airgapped" VM to deal with sensitive or untrusted data, and it helps knowing that even if I mess up with whatever I'm doing, the VM will keep everything reasonably contained.

Some cool things that Qubes has outside of just VMs are its features enabled by the communication between VMs. Notable ones are Split GPG (https://www.qubes-os.org/doc/split-gpg/) which let you use a VM as if it were a smartcard for GPG and Split SSH (https://github.com/Qubes-Community/Contents/blob/master/docs...) which let you isolate your private SSH keys from your VM running your SSH client.

There are some sticking points around Qubes. For instance, I use Tailscale to connect my computers to each other from anywhere. Tailscale's install scripts add their keys to my VM's package manager for updates and installs. The proper way to do this in Qubes is to clone a TemplateVM, run Tailscale's install script, update, install, and then base an AppVM off of it. But that creates an entire new OS taking up storage and requiring updates. You can hack a way around this in an AppVM which saves a considerable amount of space, but it takes a lot of upfront time to do and requires you to manually update it.

Another sticking point is hardware acceleration. The desktop environment has access to hardware acceleration, so it runs fine, but opening videos in AppVMs is all software decoded. I'm on a Thinkpad T580 and it can run 1080p videos, but the fans turn on and can't do 4K. When I want to game or do something GPU heavy I either stream from my tower or completely switch over.

Overall, I'm really happy with Qubes and I'm planning to stick with it on my laptops.

I can't speak to 17+ GPUs - but have successfully passed through a single high-end GPU for gaming via following these instructions: https://github.com/Qubes-Community/Contents/blob/master/docs/customization/gaming-hvm.md

Yes its possible. But check here under "Audio Support", also says at the bottom that windows 7, 10 & 11 are fully supported. As for how to install Windows, here. And installing Windows 11 by disabling the TPM check: https://forum.qubes-os.org/t/windows-11-in-qubes/6759/8.

Follow this guide https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md

In other cases it may be more documented, such as Golangs baked-in telemetry.

There should be better ways to check these problems. The best I have found so far is Crev https://github.com/crev-dev/crev/. It's most used implementation is Cargo-crev https://github.com/crev-dev/cargo-crev, but hopefully it will become more required to use these types of tools. Certainty and metrics about how many eyes have been on a particular script, and what expertise they have would be a huge win for software.

Looks like there's an implementation of it for npm: https://github.com/crev-dev/crev

I've been willing to try it for a while for Rust projects but never committed to spend the time. Any feedback?

If you don't know the author, signatures do nothing. Anybody can sign their package with some key. Even if you could check the author's identity, that still does very little for you, unless you know them personally.

It makes a lot more sense to use cryptography to verify that releases are not malicious directly. Tools like crev [1], vouch [2], and cargo-vet [3] allow you to trust your colleagues or specific people to review packages before you install them. That way you don't have to trust their authors or package repositories at all.

That seems like a much more viable path forward than expecting package repositories to audit packages or trying to assign trust onto random developers.

[1]: https://github.com/crev-dev/crev [2]: https://github.com/vouch-dev/vouch [3]: https://github.com/mozilla/cargo-vet

I don't think it makes much sense to verify pypi authors. I mean you could verify corporations and universities and that would get you far, but most of the packages you use are maintained by random people who signed up with a random email address.

I think it makes more sense to verify individual releases. There are tools in that space like crev [1], vouch [2], and cargo-vet [3] that facilitate this, allowing you to trust your colleagues or specific people rather than the package authors. This seems like a much more viable solution to scale trust.

[1]: https://github.com/crev-dev/crev

Crev?

Alternatives to cargo-vet that has been mentioned before here on HN:

- https://github.com/crev-dev/crev

- https://github.com/vouch-dev/vouch

Anyone know of any more alternatives or similar tools already available?

I plug this every time, but here goes: https://github.com/crev-dev/crev solves this by providing code reviews, scales via a web-of-trust model, and relies on cryptographic identities. That way, you can depend on a package without having to trust its maintainers and all future versions.

I understand your worries about the number of dependencies you're "forced" to use, however, most of them tend to be doing something that's both non-trivial and useful for more than a single project. As for being able to trust all your transitive dependencies, well, that's something that the Crev project is trying to address, although I don't believe that has gained much traction yet.

It's good that having a reproducible build process is a requirement for the Gold rating, as is signed releases.

Perhaps there needs to be a Platinum level which involves storing the hash of each release in a distributed append-only log, with multiple third parties vouching that they can build the binary from the published source.

Obviously I'm thinking of something like sigstore[0] which the Arch Linux package ecosystem is being experimentally integrated with.[1] Then there's Crev for distributed code review.[2]

[0] https://docs.sigstore.dev/

[1] https://github.com/kpcyrd/pacman-bintrans

[2] https://github.com/crev-dev/crev