dpc/crev

CREV - Code REView system that we desperately need; consider joining the Matrix channel instead: https://matrix.to/#/!uBhYhtcoNlyEbzfYAW:matrix.org ; they are bridged

Konrad Borowski

@KonradBorowski_gitlab

also, is it just me, or dangerous and negative are the same? i wrote "dangerous", but ended up with "negative"

it's also sorta annoying that cargo crev diff is not an unified diff

Konrad Borowski

@KonradBorowski_gitlab

oh, you can pass an argument, okay then

matrixbot

@matrixbot

MaulingMonkey Huh, yeah, negaitve = dangerous it looks like to me too.

MaulingMonkey For diff I've mostly been explicitly using --dst and --src for versions

matrixbot

@matrixbot

MaulingMonkey As for dangerous it looks like it got aliased to negative in this commit: dpc/crev@7538c55

matrixbot

@matrixbot

dpc > <@mauling-monkey:matrix.org> Huh, yeah, negaitve = dangerous it looks like to me too.

Yes. I've decided that having this distinction is not very useful, now that we have a whole advisory and issues system. Is something is dangerous, it should have an issue reported.

dpc I'm back in bussiness!

MaulingMonkey Makes sense to me... some old lingering references to "dangerous" in the toml comments worth cleaning up

matrixbot

@matrixbot

dpc Yes. Will get there eventually. :)

matrixbot

@matrixbot

dpc Generally the whole codebase was endlessly modified, and I optimized for getting things done. I guess now that there seem to be more people, "running fast and breaking things" is no longer going to be the best approach. :)

matrixbot

@matrixbot

MaulingMonkey But running fast and breaking things is fun...!

dpc Yeah, unless it was your stuff that got broken :D

matrixbot

@matrixbot

dpc Opinion needed on commands structure in the CLI dpc/crev#219

Andrew Gallant

@BurntSushi

if i am in a checkout of the regex crate, i notice that cargo crev verify doesn't show regex itself in the output. is that intentional?

(maybe a better question is, what is the mental model i should have here? maybe the one i have is all wrong.)

Andrew Gallant

@BurntSushi

is there a field in a proof review that permits one to say, "i'm the author/maintainer of this crate"? or does crev figure that out automatically?

is there a way to reference past reviews of a crate? i can imagine that for a crate that doesn't change often, you might want to say, "review N-2 still applies, yadda yadda yadda about the diff between then and now"

Dawid Ciężarkiewicz

@dpc

Yes. I guess the overarching idea is that you want verify deps, not your own code. If you want to review random crate, you can just use -u switch in any rust repo, even unrelated

@BurntSushi comment? :D

There is cargo crev diff and cargo crev review --diff or something like that that will let you write a differential review.

So keeping up with reviewing incremental updates is quite effortless.

Dawid Ciężarkiewicz

@dpc

@BurntSushi Regarding the github issue. You probably want to explore the --skip-known and --skip-trusted

BTW. I'm trying to rewrite the parallelized scanning implementation, because I am not happy with all the details there. If anyone was to start furiously hacking on cargo-crev please let me know, as we might conflict a lot.

Andrew Gallant

@BurntSushi

@dpc thanks for the answers! i have another question: how does cargo crev update my crev-proofs repo? will it just do a git pull and introduce merge commits?

"I guess the overarching idea is that you want verify deps, not your own code" --- interesting. so it is not good to provide reviews of your own crates? many of my dependencies were authored by me.

Dawid Ciężarkiewicz

@dpc

I think right now anything flies, and I wouldn't worry about it too much. Do as you please.

But in the end goal, it is a bit implied that author would trust their own crate.

Right know you're even on the list of "known crate owners", so the crates you own on crates.io are assummed to be potentailly somewhat trusted because of that.

Andrew Gallant

@BurntSushi

hah really? hmm okay.

Dawid Ciężarkiewicz

@dpc

You can cargo crev edit known and edit that list.

Merge commits are prevented by the use of "host-side tags".

Andrew Gallant

@BurntSushi

so i guess that's where i was starting, and since i know the crate very well, i can provide some crucial context without a lot of work: https://github.com/BurntSushi/crev-proofs/blob/master/VylyTuk8CMGqIxgHixWaqfiUn3xZyzOA1wFrQ0sR1As/reviews/2019-08-packages-QCBmBg.proof.crev

Dawid Ciężarkiewicz

@dpc

Every system you use will generate a random number so each will maintain a different file, side by side.

Andrew Gallant

@BurntSushi

oh interesting, doesn't git automatically create a merge commit if it can't fast forward though?

Dawid Ciężarkiewicz

@dpc

Yeah, I think reviewing your own crates is valuable.

Andrew Gallant

@BurntSushi

even if there's no actual merging happening in a single file

Dawid Ciężarkiewicz

@dpc

I think we're doing pull --rebase or something like hat.

Andrew Gallant

@BurntSushi

oh good, phew

Dawid Ciężarkiewicz

@dpc

cargo crev publish takes care of that.

Andrew Gallant

@BurntSushi

i hate merge commits :)

Dawid Ciężarkiewicz

@dpc

I'm using cargo crev on my home and work computer and it mostly works fine.

Andrew Gallant

@BurntSushi

ah nice

Dawid Ciężarkiewicz

@dpc

Though it seems I forgot to do that on trust proofs, and I'll have to fix that.

You can use cargo crev export id on one host and cargo crev import id on the other to share identity.

You can also generate two and have one trust the other. They can share (or not) the git repo.

Andrew Gallant

@BurntSushi

yeah i saw that, t hat's good

another question: after i'm done a review, crev always tells me that the crate is unclean. but i don't understand what that means, so running cargo crev clean <crate> is basically turning into a ritual. can you shed some light on that?

Dawid Ciężarkiewicz

@dpc

With reviewing own crates - there's also a value in it, especially if the credentials to github repo and crates.io are shared. These way you rubber stamp that you approve the crate, and it's not eg. someone maliciously uploading something without main author noticing it.

That's basically https://github.com/dpc/crev/issues/224#issuecomment-524098614

Where communities thrive

People

Repo info

Activity