Web-based UI for reviews (crates.rs)

[kornelski]

I'm thinking about creating a website for reviewing code (or more specifically, adding it to https://crates.rs). I already have components to interact with crates.io, to unpack crates, to do syntax highlighting, etc. so it should be relatively easy to put together.

The workflow could look like this:

1. Choose a crate to review (or take a suggestion)
2. Log in with GitHub
3. View/browse crate's source code in the browser
4. Answer whether the code is fine
5. crates.rs would then submit the review

The upsides are:

• It's a minimal amount of friction for the user. Just click OK a few times.
• The website can measure time spent and files viewed, and guesstimate thoroughness level.
• crates.rs has data about all dependencies of all crates and all crate authors, so it can suggest crates most needing reviews (i.e. most depended on, least trusted).

But I'm not clear how to publish reviews for users. Logging with GitHub could give access to the proofs repo, but that still needs Crev's own identity.

1. I could create a new identity such as "user via crates.rs", and perhaps ask the user to trust that identity. That would be reasonable from WoT perspective, but I'd have to keep a ton of private keys.

2. I could create a commit, and then ask user to sign it from cargo crev (that might need a new feature in cargo crev)

3. If GPG was used as the identity, then user could pull crates.rs' changes and GPG-sign them in a later commit.

[dpc]

It's a minimal amount of friction for the user. Just click OK a few times.

I actually wonder what are preferences here. I am personally heavy terminal Vim/Kakoune guy, and you can tell by the current cargo crev design. I'm now trying to make life better for IDE users in #139 . I would expect people to generally prefer looking at the code in the code editor of their choosing, but I guess there must be some people who prefer web-based workflow, so I am all happy to see it.

One question: would it be an app running entirely as webasm/js on the client side? Security-wise I'm worried about it being an natural place to to attack and eg. present users with different files than what they really are etc.

but I'd have to keep a ton of private keys.

As long as you encrypt them with user-provided passphrase (salt + keystretching), so that even when you get hacked they are not very useful, I don't see a big problem with it. If the whole app was running on the client, then you could maybe not even store it at all.

Alternative method seems clunky - UX wise, defeating the biggest benefit of web-UI, IMO.

[kornelski]

Security-wise I'm worried about it being an natural place to to attack and eg. present users with different files than what they really are etc.

I don't see a way around that. Even if it was purely client-side, you'd have to trust that I've served you JS that does what it claims it does. Web browsers have no way to anchor that trust, so everything done by the website ends up being a circular tautology (e.g. I could try to make JS with reproducible builds and signatures, but then key verification code would come from me too).

[dpc]

I don't see a way around that.

I guess we will just have to accept it. I would still prefer people to use their local environments, but if a web UI gets someone to start using crev and review some stuff, I guess it's a very worthwhile goal.

Maybe web UI could add some field in the proofs it is producing. Something like

from:
  agent: WebUI
  agent-type: hosted

WebUI should be whatever the name of the UI/project was used. At very least, it would help automatic tools and/or paranoid people, take into account that this review was not produced by user's local profile, or something.

[kornelski]

Yeah, having explicit agent relationship sounds good. In case the site is compromised, it'd help find the reviews.

[Nemo157]

The most important thing I think a web UI could provide is showing the current review status (whether from that web service's own trust root, or somehow being able to set the trust root), e.g. I was just thinking about giving cargo-crev a go, but before I install it I would want to see the trustedness of it and its dependencies.

Being able to provide the reviews from the web seems much lower priority to me than making it easy to see the trust status (especially for distrusted crates).

[dpc]

A service like that would be really useful indeed.

[kornelski]

Can someone help me get started?

I've got crates-io integration (crate download, extraction) code done, but I need:

1. "Log in with GitHub" — something that will verify user identity (implement the OAuth flow). Ideally it could be a separate, reusable crate. I'm using Actix, but I don't mind switching or writing an adapter if necessary.

2. UX design for the flow, and review screen. The goal is to make sure it's easy to review files, peek at other files to cross-reference them, keep track of what has been reviewed so far. Add notes/comments/warnings about findings if needed. I'm thinking about Bitbucket's pull request review screen (with sidebar to browse) and StackOverflow's admin for Suggested Edits.

3. Graphic design. I'll launch it as part of lib.rs, so might be similar.

[dpc]

@kornelski

So more than a year ago I was investigating the whole reviewing crates / building trust for Rust ecosystem. My initial attempt was building a website. A side-goal was trying out Rust for web-project (Rocket), along with NixOs and NixOps for deployment etc.

A had quite a bit stuff working, including github authentication: https://gitlab.com/hackeraudit/web/blob/master/src/auth/mod.rs

I eventually realized that I just can't get people to use it, and stopped working on it.