Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:41
    programmerjake commented #232
  • 06:39
    dpc closed #232
  • 06:29
    dpc commented #232
  • 06:29
    dpc commented #232
  • Sep 20 19:10

    dpc on master

    Double proof body limit from 16… Merge pull request #247 from Ma… (compare)

  • Sep 20 19:10
    dpc closed #247
  • Sep 20 19:09
    dpc commented #247
  • Sep 20 18:49
    lo48576 commented #247
  • Sep 20 18:47
    MaulingMonkey opened #247
  • Sep 20 17:37
    dpc commented #246
  • Sep 20 17:36
    dpc commented #246
  • Sep 20 17:34
    dpc commented #246
  • Sep 20 04:54
    lo48576 edited #246
  • Sep 20 04:53
    lo48576 edited #246
  • Sep 20 04:53
    lo48576 opened #246
  • Sep 18 06:35

    dpc on master

    WTF Fix `--recursive` in the worksp… `--recursive` to remove duplica… (compare)

  • Sep 17 22:53
    dpc edited #245
  • Sep 17 22:53
    dpc opened #245
  • Sep 17 06:16

    dpc on master

    We don't need `threadpool` anym… (compare)

  • Sep 17 06:08

    dpc on master

    Make dep graph dumber. Don't ca… Dependency graph works! Initial version of `--recursive… (compare)

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.
I don't know what's going on. It's either a problem that was there before and noone noticed, or recent bigger changes by some contributors broke someting (I kind of doubt it, but maybe).
I'll look into it.
Andrew Gallant
@BurntSushi
interesting... i was pretty careful in one of my reviews to not save any files or otherwise touch anything. i opened some files in vim, but vim should be writing swap files somewhere else. and it doesn't write backup files.
but the previous review i just did didn't end up with in an unclean state, so... ¯\_(ツ)_/¯
Dawid Ciężarkiewicz
@dpc
Truth be telling, I maintain and develop this crate with quality expectations and so on, because I have so little time.
The unclean state is mostly about something introducing a difference between what you reviewed and freshly downloaded copy.
Andrew Gallant
@BurntSushi
i see
yeah, time is the enemy of us all...
Dawid Ciężarkiewicz
@dpc
Might be your code editor / IDE / RLS/ cargo build, might be also crev's logic to check it being totally off.
*with low quality expectations
I'm just hopping to get to work well enough that other people will be interested in pushing it forward. :D
Andrew Gallant
@BurntSushi
i've taken some interest in this dependency review stuff because of an interesting conflation of life events (that i can't quite talk about yet), in addition to the recent kerfuffle about dependencies on reddit and the great post by icefox.
oh, yup, i bet it's rust-analyzer
good call
Dawid Ciężarkiewicz
@dpc
We ignore /target and (erroneously, it seems) Cargo.lock
Andrew Gallant
@BurntSushi
hmm
Dawid Ciężarkiewicz
@dpc
I also think this check kind of serves no purpose, so maybe we can just remove it altogether.
Andrew Gallant
@BurntSushi
but yeah, i'm actually kind of hoping that crev can serve as the much needed backpressure against the proliferation of large dependency trees.
Dawid Ciężarkiewicz
@dpc
It's a little bit of second guessing cargo, which is pointless
Yeah, once people actually have to review their dependency, they will get conscious about it.
We had the discussion about it on r/rust, I think. I have issues open to provide some better recursive metrics etc.
Andrew Gallant
@BurntSushi
yeah, right. i'm still super skeptical to be honest, but i'm giving it an earnest try.
RE: "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." --- this sounds interesting. could you say more about it? how would someone verify the relationship between github and crates.io?
Dawid Ciężarkiewicz
@dpc
There is no relationship like this right now. What I say is - your crate on crates.io can have shared ownership between 4 people, each of who could get compromised and try to publish a malicious version. The fact that you yourself has reviewed it (if I have you in my WoT) means that you are at least aware of it being published, and maybe you even compared with your local copy etc.
The crates.io is a side-feature to help with initial bootstrapping. There is a list of "known crates.io owners" (distinct from the WoT) and one can edit it and filter-out crates that are from known authors. This way you can focus on stuff from less trustworthy authors first, if so you desire.
Since we can't get the whole ecosystem reviewed in one go, we can at least look at the most suspicious crates first.
Ones with high geiger count, unknown authors, custom build scripts and so on.
Andrew Gallant
@BurntSushi
yeah the bootstrapping stuff makes total sense. i get that. i think i grok the other stuff too.
it would be nice if cargo crev could require or at least display whether the user has 2FA enabled for wherever they are hosting their proofs
Dawid Ciężarkiewicz
@dpc
If crates.io provides 2fa info for each user, we could easily do that.
Andrew Gallant
@BurntSushi
no 2FA is probably an immediate downgrade in trust
for me anyway
i think crates.io relies on github, and github provides 2FA. i don't know if it's queryable or not though.
Dawid Ciężarkiewicz
@dpc
The hosting their proofs is a tricker one, since we don't have a relationship of crates.io user - crev id/url
Andrew Gallant
@BurntSushi
yeah, i guess the extra key from crev makes this hard to exploit.
Dawid Ciężarkiewicz
@dpc
If the username is the same in both, we could do mapping, potentially. Donno. Maybe it's doable. On the other hand - it's a very specific and hardcoded datapoint, that could get broken in many ways. Also - would be nice to support other registries.
Andrew Gallant
@BurntSushi
even if an attacker gets access to someone's github account, the worst they could do is upload a new version of a package to crates.io with potentially malicious code in it. but they couldn't publish a review unless they also had that user's crev key.
Dawid Ciężarkiewicz
@dpc
So too much hardcoding for github.com can backfire.
Andrew Gallant
@BurntSushi
yeah makes sense
Dawid Ciężarkiewicz
@dpc
Exactly. Also crev is supposed to require some redundancy, eventually, if there is enough people actually providing proofs.
Andrew Gallant
@BurntSushi
yeah