Want to help? Just try out `cargo crev` and give feedback.

[dpc]

cargo-crev is kind of working already. In a sense it's even quite feature complete (alpha quality though)

See https://github.com/dpc/crev/tree/master/cargo-crev for instructions.

[tylerlaberge]

Just went through building this project and trying this out and here are some things I ran into (for the most part it seems to be working and looks great)

Build notes:

Had some issues building this because of some dependencies I didn't have installed, specifically I did not have OpenSSL installed or a C compiler needed for argonautica. These were resolved with

sudo apt-get update
sudo apt-get upgrage

# openssl deps
sudo apt-get install openssl libssl-dev

# argonautica deps
sudo apt-get install clang llvm-dev libclang-dev

After getting those dependencies installed the project compiled successfully. Perhaps these dependencies should be called out in the build instructions?

cargo-crev notes:

1. cargo crev verify should color code trusted vs not trusted dependencies, currently its a little hard to parse since its all just one color. Green for trusted, Red for not trusted would be cool (maybe yellow for low/medium trusted?)

2. It's a little hard to see what has been reviewed with cargo crev review but not commited/pushed yet. You can do a cargo crev db git status to see files that haven't been pushed, but the filenames don't give any indication of the package the review was for. It would be cool if you could do something like cargo crev status and get a list of dependency names that you have reviewed but not pushed yet.

3. cargo crev db git push does not work for me.

$ cargo crev db git push
fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use

git push --set-upstream origin master

if I try the set-upstream command I get permission denied.

4. Finally, I wonder if the git commands should be kind of abstracted in some way?

So instead of

cargo crev db git add/cargo crev db git commit/cargo crev db git push

it could instead just be something like

cargo crev db save (adds/commits)
cargo crev db publish (pushes to remote)

Reason being is I don't exactly see the use case of having all the git commands available, seems like users really would only need the ability to save and publish to me.

Overall, really cool project and I'm excited to see where this goes (and the code looks well written too which is great), hope this feedback helps, when I have time I will try to make some contributions :)

[dpc]

I've just improved cargo crev verify output . Also created #39 for colors and other improvements.

It's a little hard to see what has been reviewed

cargo crev db git diff HEAD should show you this. Basically all git commands just work, so it should be fairly flexible. If this is not enough, we can definitely add something. It's just the matter of figuring out a consistent usage model.

cargo crev db git push does not work for me.

#36 - let me know in case it doesn't help (open a new issue with the actual error)

Finally, I wonder if the git commands should be kind of abstracted in some way?

I'm not sure myself. I am proficient git user, so for me issuing raw git commands is easier, I have my own shortcuts, additional commands etc.

But I guess not every user has to feel this way, so some helpers for most common workflows, could be useful.

Reason being is I don't exactly see the use case of having all the git commands available

For me, it enables any more powerful workflows and tools. Pushing to multiple places, changing branches, etc. Also - it was quicker to implement a generic git wrapper, than figuring out all the details. :D

[dpc]

@tylerlaberge I was rushing to go to sleep yesterday, but I really appreciate the feedback. Thank you!

[kornelski]

In the screencast the "and now you review code" part is handwaved. To me, this is the hard part. I know I can't trust package's source code as shown on github, and need to review the actual crate file from crates.io, but getting it is cumbersome. Then I have to ensure I reviewed every file and haven't overlooked anything, and that the crate I dug up is actually the same crate that I'm running trust commands for.

Could you have an interactive mode, similar to git add -p, where you display each file in the terminal, and ask "Is this good? (y/n)" and automatically create review data based on that?

[dpc]

@kornelski Yes. Of course the review part is the time consuming and difficult one. Part of the reason the thoroughness field exists. You can just glance through files, and not even review all, and just mark the thoroughness as none or low. It's still far better than if noone was reviewing them at all. Eventually, when there's enough reviewers and reviews floating around, there will be a time to start getting more methodological about it. I do have some plans for per-file reviews (in form of Code Review Proofs) but it's not complete atm. We could also add some helpful tooling to at least help mark files which were reviewed for the convenience of the reviewer.

[mglax]

Works fine on Mac OS X. One thing that stroke me first is that the "rating" should be split, the security aspect and the functional aspects are, to me, not really related. I am reviewing a deprecated crate, it appears first on crates.io (the name is an exact match) and I found myself installing it by mistake whilst it was deprecated. Yet, there are no security flaws that I can see (positive review), but since it's deprecated, I'd put a negative note for the functional part.

[dpc]

@mglax I don't really see how "functional but insecure" or "secure but non functional" states are any useful for the downstream user of the review. IMO, in both cases you just want to give rating: negative or rating: dangerous and describe in the comment what's wrong. For the mass-consumers, all of this will go through WoT graph and will have to spit out "OK to use" or "not OK to use" decision anyway.

Once the downstream user will get a dependency flagged for any reason, they are supposed to read the offending comments, and judge accordingly what to do, potentially overwriting the status with their own review. Eg. rating: neutral, comment: Yeah, there are problems, but for my particular purpose it's OK.

I'm open for discussion about it though.

[daxpedda]

If I only want to use cargo crev verify deps, why do I have to generate an ID first, which also implies me having to create a crev-proofs repo?
Shouldn't it be enough to just fetch proofs from your trusted source and then run verify?

I had a great experience otherwise. Wish this would be part of the official rust ecosystem. We really needed this desperately already yesterday.

[dpc]

@daxpedda You're right. I've created #107 to fix it. Thanks!

[dpc]

@daxpedda Fixed. I'd appreciate a lot if you could test the current git version. Thanks!

[daxpedda]

Is there a way to log out? Is there a way to find out where currently fetched proofs are located?

I can create seperate issues for those if you want.

[dpc]

@daxpedda "Log out"? What exactly do you mean?

Fetched proofs are stored in subdirectories for ~/.cache/crev/remotes/<urlid>. It is being displayed when crev fetch <smth> is used.

Your local proof repo is in ~/.config/crev/proofs/<urlid>.

In both cases the <urlid> is a base64 (url-safe) encoded blake hash of the url.

[daxpedda]

@daxpedda "Log out"? What exactly do you mean?

After deleting the cache folder, if I cargo crev query id current it will still tell me who I am and my ID. Is there a way to reset it? Like cargo crev switch none or something like that?

Fetched proofs are stored in subdirectories for ~/.cache/crev/remotes/<urlid>.

On Windows it saves it in X:\Users\<Username>\AppData\Local\Dawid Ci,281,,380,arkiewicz\crev\remotes, is that intended? Will that be changed? Should it be documented somewhere?

EDIT: The only way I found to "log out" is to delete the local proof directory, which on windows is in X:\Users\<Username>\AppData\Roaming\Dawid Ci,281,,380,arkiewicz\crev. Again same question as above with the other path.

EDIT 2: Running cargo crev fetch <URL> still gives me Error: User config not-initialized. Use `crev new id` to generate CrevID..

[dpc]

@daxpedda I've created #124 to address the "not-initialied". Initially crev was meant to require ID in all cases, and I still haven't changed it for all the commands.

There are two concepts here: one is cache of where cargo crev fetch ... stuff goes. The other one is local copy of your git proof repo (where your own proofs go). Your own repo repo might or might not happen to be fetched into a cache too. We're using app_dirs to create these dirs, I belive, and if you think on Windows these should be some other places, placase create a separate issue and let me know what do you think, or even better - submit a PR. I'm not a Windows user so Windows support will require some good people to step in and help out. :)

Right now there's no command to "unswitch" from an ID. I'm not sure if this is really needed. If you want to try things without any ID, I guess creating a new, fresh ID with invalid url would effectively do that. You can also delete the whole local crev diff (and possibly cache is well, if you really want).

I guess we could have a command for cleaning up the cache ...

Can you explain why exactly do you need this things? I knew, maybe there are some better ways to support such use case.

[daxpedda]

and if you think on Windows these should be some other places, placase create a separate issue and let me know what do you think, or even better - submit a PR.

Would love to submit a PR. I think the least we could change is Dawid Ci,281,,380,arkiewicz to something more appropriate. #125

Right now there's no command to "unswitch" from an ID. I'm not sure if this is really needed.

You are right, this is not really needed. Just needed it right now because I had to create an ID to verify and fetch and wanted to test if it works without. So I can't really think of any real world scenario where this is really needed.

I guess we could have a command for cleaning up the cache ...

I think this sounds useful, but again, I can't really think of any meaningful real world scenarios where this is really needed outside of testing.

Can you explain why exactly do you need this things? I knew, maybe there are some better ways to support such use case.

So I was thinking to use crev in my CI. Obviously there are still some pieces missing for that to work, but creating an ID is certainly not useful in this scenario or for any other scenario where people do not intend to do anything else then verify. Other then that I think it would be nice to be able to have a badge service or something similar that represents how many dependencies are trusted or reviewed.
Just putting out ideas here^^.

[dpc]

So I was thinking to use crev in my CI.

I totally want it, but just didn't get to implement it yet. Created #131

[arbitrix]

On Windows the build fails due to missing clang.dll while building argonautica.

error: failed to run custom build command for `argonautica v0.1.5`
process didn't exit successfully: `C:\Users\jeroeng\AppData\Local\Temp\cargo-install3yInmN\release\build\argonautica-a3b6f88e156ef6b8\build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-pc-windows-msvc")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-pc-windows-msvc")
CC_x86_64-pc-windows-msvc = None
CC_x86_64_pc_windows_msvc = None
HOST_CC = None
CC = None
CFLAGS_x86_64-pc-windows-msvc = None
CFLAGS_x86_64_pc_windows_msvc = None
HOST_CFLAGS = None
CFLAGS = None
DEBUG = Some("false")
CC_x86_64-pc-windows-msvc = None
CC_x86_64_pc_windows_msvc = None
HOST_CC = None
CC = None
CFLAGS_x86_64-pc-windows-msvc = None
CFLAGS_x86_64_pc_windows_msvc = None
HOST_CFLAGS = None
CFLAGS = None
CC_x86_64-pc-windows-msvc = None
CC_x86_64_pc_windows_msvc = None
HOST_CC = None
CC = None
CFLAGS_x86_64-pc-windows-msvc = None
CFLAGS_x86_64_pc_windows_msvc = None
HOST_CFLAGS = None
CFLAGS = None
running: "C:\\Program Files (x86)\\Microsoft Visual Studio\\Preview\\Community\\VC\\Tools\\MSVC\\14.14.26316\\bin\\HostX64\\x64\\cl.exe" "/nologo" "/MD" "/O2" "/I" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\argonautica.bgM4iUey8c3j" "/FoC:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src\\core.o" "/c" "phc-winner-argon2/src/core.c"
running: "C:\\Program Files (x86)\\Microsoft Visual Studio\\Preview\\Community\\VC\\Tools\\MSVC\\14.14.26316\\bin\\HostX64\\x64\\cl.exe" "/nologo" "/MD" "/O2" "/I" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\argonautica.bgM4iUey8c3j" "/FoC:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src\\argon2.o" "/c" "phc-winner-argon2/src/argon2.c"
running: "C:\\Program Files (x86)\\Microsoft Visual Studio\\Preview\\Community\\VC\\Tools\\MSVC\\14.14.26316\\bin\\HostX64\\x64\\cl.exe" "/nologo" "/MD" "/O2" "/I" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\argonautica.bgM4iUey8c3j" "/FoC:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src\\encoding.o" "/c" "phc-winner-argon2/src/encoding.c"
running: "C:\\Program Files (x86)\\Microsoft Visual Studio\\Preview\\Community\\VC\\Tools\\MSVC\\14.14.26316\\bin\\HostX64\\x64\\cl.exe" "/nologo" "/MD" "/O2" "/I" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\argonautica.bgM4iUey8c3j" "/FoC:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src/blake2\\blake2b.o" "/c" "phc-winner-argon2/src/blake2/blake2b.c"
argon2.c
core.c
blake2b.c
encoding.c
exit code: 0
running: "C:\\Program Files (x86)\\Microsoft Visual Studio\\Preview\\Community\\VC\\Tools\\MSVC\\14.14.26316\\bin\\HostX64\\x64\\cl.exe" "/nologo" "/MD" "/O2" "/I" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\argonautica.bgM4iUey8c3j" "/FoC:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src\\thread.o" "/c" "phc-winner-argon2/src/thread.c"
exit code: 0
running: "C:\\Program Files (x86)\\Microsoft Visual Studio\\Preview\\Community\\VC\\Tools\\MSVC\\14.14.26316\\bin\\HostX64\\x64\\cl.exe" "/nologo" "/MD" "/O2" "/I" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\argonautica.bgM4iUey8c3j" "/FoC:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src\\ref.o" "/c" "phc-winner-argon2/src/ref.c"
thread.c
exit code: 0
ref.c
exit code: 0
exit code: 0
exit code: 0
running: "C:\\Program Files (x86)\\Microsoft Visual Studio\\Preview\\Community\\VC\\Tools\\MSVC\\14.14.26316\\bin\\HostX64\\x64\\lib.exe" "/OUT:C:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\libargon2.a" "/nologo" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src\\argon2.o" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src\\core.o" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src/blake2\\blake2b.o" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src\\encoding.o" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src\\thread.o" "C:\\Users\\jeroeng\\AppData\\Local\\Temp\\cargo-install3yInmN\\release\\build\\argonautica-fde779f44774584e\\out\\phc-winner-argon2/src\\ref.o"
exit code: 0
cargo:rustc-link-lib=static=argon2
cargo:rustc-link-search=native=C:\Users\jeroeng\AppData\Local\Temp\cargo-install3yInmN\release\build\argonautica-fde779f44774584e\out

--- stderr
thread 'main' panicked at 'Unable to find libclang: "couldn\'t find any of [\'clang.dll\', \'libclang.dll\'], set the LIBCLANG_PATH environment variable to a path where one of these files can be found (skipped: [])"', src\libcore\result.rs:999:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

warning: build failed, waiting for other jobs to finish...
error: failed to compile `cargo-crev v0.4.0`, intermediate artifacts can be found at `C:\Users\jeroeng\AppData\Local\Temp\cargo-install3yInmN`

[dpc]

@arbitrix https://github.com/dpc/crev/tree/master/cargo-crev#windows

If you can think of more specific instructions, I would be happy to land a PR with them. :) I myself, don't have any Windows box, so I rely on other devs/users for Windows support.