A cryptographically verifiable code review system for the cargo (Rust) package manager.

Last update: Jun 17, 2022

Travis CI Build Status crates.io crev matrix channel crev gitter channel

jesus, that's a lot of dependencies

image credit

cargo-crev

A cryptographically verifiable code review system for the cargo (Rust) package manager.

Introduction

Crev is a language and ecosystem agnostic, distributed code review system.

cargo-crev is an implementation of Crev as a command line tool integrated with cargo. This tool helps Rust users evaluate the quality and trustworthiness of their package dependencies.

Features

cargo-crev can already:

  • warn you about untrustworthy crates and security vulnerabilities,
  • display useful metrics about your dependencies,
  • help you identify dependency-bloat,
  • allow you to review most suspicious dependencies and publish your findings,
  • use reviews produced by other users,
  • increase trustworthiness of your own code,
  • build a web of trust of other reputable users to help verify the code you use,

and many other things with many more to come.

Getting started

Static binaries are available from the releases page.

Follow the cargo-crev - Getting Started Guide (more documentation available on docs.rs).

cargo-crev is a work in progress, but it should be usable at all times. Join our matrix or gitter channel, get help, report problems and feedback. Thank you!

Raise awareness

If you're supportive of the cause, we would appreciate helping to raise awareness of the project. Consider putting the below note in the README of your Rust projects:

It is recommended to always use [cargo-crev](https://github.com/crev-dev/cargo-crev)
to verify the trustworthiness of each of your dependencies, including this one.

Thank you!

Changelog

Changelog can be found here: https://github.com/crev-dev/cargo-crev/blob/master/cargo-crev/CHANGELOG.md

GitHub

https://github.com/crev-dev/cargo-crev
Comments
  • 1. cargo_crev_web - web server to query reviews from cargo-crev

    Hello, I like the cargo-crev system a lot. But it needs much more audience to spread. I think that the reviews of crates need to be on the web to allow anybody to see them. I prepared an idea. You can try it here: alternatives: https://bestia.dev/cargo_crev_web/query/btoi issues https://bestia.dev/cargo_crev_web/query/num-traits advisory https://bestia.dev/cargo_crev_web/query/protobuf The code is here: https://github.com/LucianoBestia/cargo_crev_web This is a prototype. I just copied the *.crev files from my cache to see how it works. I imagine the first question is: Every developer has a different list of trusted people. How to deal with it? I suppose that this reviews on the web are just informative. Better to have more reviews than less. Somebody with experience could suggest who to trust. This list could be modified any time. On the web server cargo-crev will update the cache/crev every day. The reviews are pulled from the repos of trusted persons - and their trusted persons.

    I would like to hear what do you think about that? Thanks.

    Reviewed by bestia-dev at 2020-04-29 17:52
  • 2. Own trust should override Web of Trust

    There's a user who through my WoT got medium trust. I didn't trust them so much, so I made a trust proof with low trust. It didn't change the level of trust.

    I assume WoT picks the maximum trust it can find, but I think my own Id should have the final say.

    It worked for distrust level, but that seems overly negative. I'd like to be able to override WoT's trust with none and low too.

    Reviewed by kornelski at 2020-04-12 23:22
  • 3. Is signing worth it?

    I hope not to come off as overly critical, but this was something on my mind after tinkering about with crev locally. I think it would be valuable to reconsider the fact that the design uses signing, my reasons being:

    From the security viewpoint, I can't personally see many scenarios the signing protects against. In practice it does not protect against GitHub going rogue (I think this is perfectly acceptable), as IDs to be trusted are fetched from a GitHub repository and then likely copy-pasted from the output into trust. That or they're copy-pasted from instructions hosted on GitHub.

    A rogue/compromised user is caught out by testing crates directly from the package manager rather than the source. A rogue package manager is caught out by including a digest in the review.

    Now for the main reason I opened this issue, I believe it would open up some benefits to adoption if there were no signing. Code review is a hard ask, and any barrier makes the ask harder still.

    There would be no more need for key management. You don't have to worry about transferring it between devices in order to be able to review. You don't have to worry about losing it. You don't have to manage yet another password.

    It would allow a simpler format and CLI. There would be no need for IDs, or to think of it another way the repo would be the ID. Trusting other users means just pointing at their repository. The file layout could be simplified to e.g. crev-proofs/reviews/*, the current format gives off an air of being opaque to human readers which may be off-putting.

    It would be simpler to produce tools/integrations. Good integrations will be a massive benefit to the ecosystem: be it in the editor, GitHub bots to show if something lacks reviews on PRs, web UIs etc. Both the simpler format and lower complexity will increase the ease of creating any such tools.

    It is of course a trade-off either way, the signing does provide trust on first use protection, my question would be is it worth the hit to usability?

    Reviewed by Alexendoo at 2019-07-17 18:40
  • 4. Usability issues with the command-line interface

    To me the "noun verb" grouping of commands is unhelpful. On a first glance it seems like a logical thing to do, but it has many problems in practice:

    • for many operations there's actually more than one thing involved, so it's unclear which noun is the special one. For example if an operation requires querying repositories about crate information it's entirely arbitrary whether that's crate info or repo query.

    • I can't develop intuition when to use cargo crev crate, because it changes the meaning of "crate" depending on subcommand. Sometimes it's the current crate, sometimes it's some other crate, sometimes it's search for crates. This seems wrong to me, because crate verify verifies my crate in the current directory, and given that I'd expect other crate subcommands to be consistent and also apply to my crate in the current directory, but they don't.

    • the choice of top-level nouns is odd. For example, reviews are an essential object for crev, but they weren't given a noun in the UI. There's no cargo crev review create. Instead of review delete there's crate unreview.

    • To me repositories are an implementation detail, more like a transport mechanism. So to me cargo crev repo is as weird as cargo crev http would be. Because most crev features are backed by some repo somewhere, the cargo crev repo subcommands perform lots of unrelated operations, from editing my readme to searching other people's reviews.

    • The commands are long to type. I've noticed you use an undocumented c v shortcut! Poor users who read cargo crev --help end up suffering the long versions.

    • There is no similarity between verbs. The verbs don't apply equally to the nouns. A "noun verb" design would make sense for a music player that allows song play and album play, but crev's nouns aren't interchangeable like that. In crev's case these are mostly just unique two-word commands.

    • structopt/clap doesn't think of them as nouns and verbs, but as nested subcommands. Because of that it doesn't display full commands, and cargo crev --help is useless.

    Look at cargo itself. It has cargo update, not cargo index update. It has cargo build, not cargo crate build. cargo publish, not cargo package publish. Flattening of options allows cargo --help to display the most common and most useful options.

    Reviewed by kornelski at 2020-01-17 18:08
  • 5. Can't commit or pull reviews: UnbornBranch

    After cargo crev review foo I get:

    Error: Could not not automatically commit caused by: reference 'refs/heads/master' not found; class=Reference (4); code=UnbornBranch (-9)

    There are two problems here:

    1. There is a not-completely-initialized repo somewhere. It may be my fault, as I've tried earlier version of cargo-crev and didn't fully follow instructions.

    2. The error doesn't show path to the repo, so I don't know where it is, and I can't fix it.

    Reviewed by kornelski at 2019-01-05 14:16
  • 6. Want to help? Just try out `cargo crev` and give feedback.

    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.

    Reviewed by dpc at 2018-12-03 06:26
  • 7. Unable to connect to repo using Gitlab Access Token

    Does cargo-crev support the use of Gitlab Access tokens?

    cargo crev id new --url username:[email protected]

    When I do, I get the following error:

    Couldn't clone https:username:[email protected] remote authentication required but no callback set; class=Http (34)

    I can successfully clone the same repo using git and that format.

    Reviewed by desandy at 2021-03-16 12:22
  • 8. Verification does not work as expected

    I've got a project, that uses the log-0.4.6 crate.

    I trust you and also fetched your reviews:

    $ cargo crev query id trusted
    8iUv_SPgsAQ4paabLfs1D9tIptMnuSRZ344_M-6m9RE
    Kvz2HoEIOc4U9Gg3vNDbTVO54yF1YX6RuGi2o8pZkIs
    
    $ cargo crev query review log
    version: -1
    date: "2018-12-16T14:37:00.691648406-08:00"
    from:
      id-type: crev
      id: 8iUv_SPgsAQ4paabLfs1D9tIptMnuSRZ344_M-6m9RE
      url: "https://github.com/dpc/crev-proofs"
    package:
      source: "https://crates.io"
      name: log
      version: 0.4.6
      digest: Y1F9HJSB_b1oFc1wz1qlblXXLoDyquDcVGM4g3SAhBk
    review:
      thoroughness: low
      understanding: medium
      rating: positive
    

    but when I want to verify my project's deps, the log crate has the status unknown

    $ cargo crev verify deps | grep log-
        Updating crates.io index
    unknown  /home/hirschen/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.6
    

    What am I doing wrong?

    Reviewed by hirschenberger at 2018-12-18 11:08
  • 9. Setup remote Github repo if username available

    Currently, users must setup a Github repository using the Github website before trying out crev. This PR should include changes which would allow a user to create a remote Github repo from crev directly using cargo crev new id.

    The Github username can be given directly or extracted from a github repo URL.

    This isn't perfect but should make it easier for people to try out crev.

    Reviewed by ffranr at 2018-12-15 15:20
  • 10. Add new crev logo.

    Last Sunday, I had a go at making a logo for crev. What do you guys think?

    I don't do this professionally, and I have thick skin, so please feel free to give honest feedback. It was fun to make regardless of whether you guys want to use it or not.

    I've tried to capture the idea of dependencies coupling together such as to form a protective shield.

    I took the README centering setup from here: https://github.com/meilisearch/MeiliSearch

    Light rendering on my computer: image

    Dark rendering on my computer: image

    Reviewed by ffranr at 2020-05-12 18:54
  • 11. Overwritting someone elses reviews.

    Sometimes people give a negative review to a crate, and we conciously would like to overwrite them.

    Current example. Me and other crev user reviewed smallvec and gave it a negative review, because it was ridden with unsafe and had a history of unsoundness. Then, I submitted a fuzzer to smallvec, and I think with a fuzzer we can have more confidence, and this crate does not deserve a negative rating anymore. At very least I don't want it to fail in my own crate verify output.

    So I'd like to overwrite the other persons (which I still trust) review in this case. I could ask them to change their review, but that's not the point.

    I am thinking, that a review could have an optional overrule/overwrite/override section with a list of reviews of other other people that should be ignored for some reason, because this review says they no longer apply, were a mistake, etc.

    We could identify other reviews by:

    • by id of their author
    • digest
    • signature

    The id is the longest, but is the easiest for the humans to understand and use, so I think I'll stick with it.

    For other users my override would only apply if they trust me more than then a person I'm trying to override here (more or equal maybe?).

    Should be fairly easy to implement, though I could use some second opinion.

    Reviewed by dpc at 2019-11-07 06:27
  • 12. Accidental changes during review

    I'm a bit afraid to do reviews using cargo crev crate goto because I might accidentally change files under ~/.cargo/registry/src and thus corrupt local builds. Wouldn't it be better to create and go to a temporary directory instead?

    Reviewed by stefankreutz at 2022-06-22 09:08
  • 13. Getting rid of dead URLs in `cargo crev update`

    When running cargo crev update, there are multiple repo URLs that are dead:

    $ cargo crev update
    ...
    ERROR: Error: Failed to fetch https://github.com/vctibor/crev-proofs: remote authentication required but no callback set; class=Http (34); code=Auth (-16)
    ERROR: Error: Failed to fetch https://github.com/cultpony/crev-proofs: corrupted loose reference file: FETCH_HEAD; class=Reference (4)
    ERROR: Error: Failed to fetch https://github.com/TheAlgorythm/crev-proofs: corrupted loose reference file: FETCH_HEAD; class=Reference (4)
    

    Is there a way to exclude those?

    • Please let us know:
      • Which version are you using: cargo-crev 0.23.0
      • How did you install crev: cargo build --release in the git repo
      • What OS/platform are you running on: Arch Linux
    Reviewed by dbrgn at 2022-03-05 00:40
  • 14. Adding a remote URL to a local_only repository fails to set the upstream branch for master

    I tried setting up cargo crev as a reviewer, using 0.21.3 installed from cargo install, on Arch Linux. I was unable to cargo crev publish.

    To reproduce this issue, I first removed/renamed ~/.config/crev, then ran the following commands:

    cargo crev trust --level high https://github.com/dpc/crev-proofs created ~/.config/crev/proofs/local_only_….

    [email protected] ~> cargo crev trust --level high https://github.com/dpc/crev-proofs
    Fetching https://github.com/dpc/crev-proofs... 
    https://github.com/dpc/crev-proofs                           no updates
    Found proofs from:
         185 FYlr8YoYGVvDwHQxqEIs89reKKDy-oWisoO0qXXEfHE (verified owner)
    note: Setting up a default CrevID. Run `cargo crev id new` to customize it.
    WARN: URL for … is not known yet
    WARN: URL for … is not known yet
    

    Then I tried setting up as a reviewer, using cargo crev id set-url https://github.com/nyanpasu64/crev-proofs (I think cargo crev id new --url https://github.com/nyanpasu64/crev-proofs does the same thing).

    [email protected] ~> cargo crev id set-url https://github.com/nyanpasu64/crev-proofs
    Using existing repository `/home/nyanpasu64/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-…`
    remote: Enumerating objects: 3, done.
    remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
    Unpacking objects: 100% (3/3), 341 bytes | 341.00 KiB/s, done.
    From github.com:nyanpasu64/crev-proofs
     * branch            HEAD       -> FETCH_HEAD
    Successfully rebased and updated refs/heads/master.
    …
    

    Then I tried running cargo crev publish, but apparently /home/nyanpasu64/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-… was missing an upstream branch:

    [email protected] ~> cargo crev publish
    From github.com:nyanpasu64/crev-proofs
     * branch            HEAD       -> FETCH_HEAD
    Successfully rebased and updated refs/heads/master.
    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
    

    Investigation

    I restarted the process, but ran strace -fs999 -o crev-set-url cargo crev id set-url https://github.com/nyanpasu64/crev-proofs instead. The log file shows that crev moves the local_only repository to ~/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-…, adds a remote by editing .git/config directly (not via a git remote child process), then runs git pull --rebase on the remote-tracking branch, but fails to set the upstream.

    33003 execve("/usr/bin/cargo", ["cargo", "crev", "id", "set-url", "https://github.com/nyanpasu64/crev-proofs"], 0x7fff5f6d84c8 /* 63 vars */) = 0
    …
    33003 rename("/home/nyanpasu64/.config/crev/proofs/local_only_…", "/home/nyanpasu64/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-…") = 0
    …
    33003 rename("/home/nyanpasu64/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-…/.git/config.lock", "/home/nyanpasu64/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-…/.git/config") = 0
    …
    33003 clone(child_stack=0x7f591300bff0, flags=CLONE_VM|CLONE_VFORK|SIGCHLD <unfinished ...>
    33004 execve("/usr/bin/git", ["git", "pull", "--rebase", "-Xours"], 0x7ffc8ca647e8 /* 71 vars */ <unfinished ...>
    33003 <... clone resumed>)              = 33004
    

    I think you added the remote unusually. If I look into .git/config, I see the following (missing a fetch tag):

    [remote "origin"]
    	url = [email protected]:nyanpasu64/crev-proofs.git
    

    When I run git fetch [origin [master]], I get the following output, and no origin/master ref created, and cargo crev publish fails:

    [email protected] ~/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-… (master)> git fetch
    From github.com:nyanpasu64/crev-proofs
     * branch            HEAD       -> FETCH_HEAD
    
    [email protected] ~/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-… (master)> cargo crev publish
    From github.com:nyanpasu64/crev-proofs
     * branch            HEAD       -> FETCH_HEAD
    Successfully rebased and updated refs/heads/master.
    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
    

    Is this deliberate?

    Fixing the repo

    If I recreate the remote using git remote remove origin && git remote add origin [email protected]:nyanpasu64/crev-proofs.git, it adds the following:

    [remote "origin"]
    	url = [email protected]:nyanpasu64/crev-proofs.git
    	fetch = +refs/heads/*:refs/remotes/origin/*
    

    And fetching creates an origin/master ref:

    [email protected] ~/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-… (master)> git fetch
    From github.com:nyanpasu64/crev-proofs
     * [new branch]      master     -> origin/master
    

    But then git pull --rebase -Xours doesn't work properly:

    [email protected] ~/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-… (master)> git pull --rebase -Xours
    From github.com:nyanpasu64/crev-proofs
     * [new branch]      master     -> origin/master
    There is no tracking information for the current branch.
    Please specify which branch you want to rebase against.
    See git-pull(1) for details.
    
        git pull <remote> <branch>
    
    If you wish to set tracking information for this branch you can do so with:
    
        git branch --set-upstream-to=origin/<branch> master
    

    If you instead run git pull --rebase -Xours --set-upstream origin master (I don't know what -Xours does but it's probably not important), it works and I can cargo crev publish:

    [email protected] ~/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-… (master)> git pull --rebase -Xours --set-upstream origin master
    From github.com:nyanpasu64/crev-proofs
     * branch            master     -> FETCH_HEAD
     * [new branch]      master     -> origin/master
    Successfully rebased and updated refs/heads/master.
    [email protected] ~/.config/crev/proofs/github_com_nyanpasu64_crev-proofs-… (master)> cargo crev publish
    Successfully rebased and updated refs/heads/master.
    Enumerating objects: 7, done.
    Counting objects: 100% (7/7), done.
    Delta compression using up to 12 threads
    Compressing objects: 100% (5/5), done.
    Writing objects: 100% (6/6), 951 bytes | 951.00 KiB/s, done.
    Total 6 (delta 1), reused 0 (delta 0), pack-reused 0
    remote: Resolving deltas: 100% (1/1), done.
    To github.com:nyanpasu64/crev-proofs.git
       56fcc25..79bd3b2  master -> master
    

    Fixing crev

    I'm still looking into it.

    Reviewed by nyanpasu64 at 2021-11-06 10:59
  • 15. Support using `ssh` as id url

    Hi!

    I am exploring cargo-crev for code review at my workplace. The reviews we would produce would be geared for our own use case and as such we would like to host the id repos in our internal git hosting.

    Right now, the getting started page mentions forking the github template and pointing to it with cargo crev id new --url.

    Because we have our own internal git repos, I manually cloned the github repo and pushed it to a new internal repo. I then used this url when creating my new id. Unfortunately, my git url is an ssh url which cargo-crev does not like:

    ❯ cargo crev id new --url ssh://[email protected]/nbigaouette/crev-proofs.git
    URL must start with 'https://'
    

    :(

    Exploring a bit I see that I can use cargo crev id new --no-url to create an id not linked to a git repo, which is what I did.

    Since I want to publish those reviews, I tried to set the ssh repo as the url but could not make this work:

    ❯ cargo crev id set-url ssh://...
    URL must be https://
    

    Using cargo crev id set-url https://... with the https url provided by the repo's web interface I get the following:

    ❯ cargo crev id set-url https://[email protected]/nbigaouette/crev-proofs.git
    WARN: Could not deduce `ssh` push url. Call:
    cargo crev git remote set-url --push origin <url>
    manually after the id is generated.
    Couldn't clone https://[email protected]/nbigaouette/crev-proofs.git: remote authentication required but no callback set; class=Http (34)
    

    I now see a cargo crev git subcommand! Let's try it:

    ❯ cargo crev git remote set-url --push origin ssh://[email protected]/nbigaouette/crev-proofs.git
    error: The subcommand 'git' wasn't recognized
    
    USAGE:
            cargo crev help <subcommands>...
    
    For more information try --help
    

    🤔 That's definitely a bug in the error message if the git subcommand does not exists anymore...

    If I try to set the url with the https url but without my username, I see the following:

    ❯ cargo crev id set-url https://internal-git.example.com/nbigaouette/crev-proofs.git
    WARN: Could not deduce `ssh` push url. Call:
    cargo crev git remote set-url --push origin <url>
    manually after the id is generated.
    Using existing repository `~/Library/Application Support/crev/proofs/internal_git_example__nbigaouette_crev-proofs_g-*********`
    Username for 'https://internal-git.example.com': nbigaouette
    Password for 'https://[email protected]':
    warning: no common commits
    remote: Counting objects: 3, done.
    remote: Compressing objects: 100% (2/2), done.
    remote: Total 3 (delta 0), reused 0 (delta 0)
    Unpacking objects: 100% (3/3), done.
    From https://internal-git.example.com/nbigaouette/crev-proofs
     * branch            HEAD       -> FETCH_HEAD
    Successfully rebased and updated refs/heads/master.
    ERROR: Error: Failed to fetch https://internal-git.example.com/nbigaouette/crev-proofs.git: remote authentication required but no callback set; class=Http (34)
    

    I can peek the git repo under ~/Library/Application Support/crev/proofs/internal_git_example__nbigaouette_crev_**** but I see a different git history from the original crev-proofs.git fork.

    So my questions are:

    • Can I use an internal (non-public) git repo for hosting my own proofs?
    • Can I use ssh as the protocol for communicating with my proofs repo? If so, how should I proceed?
    • Did I screw up my initial proofs repo creation (due to the different git history outlined above)?
    ❯ cargo crev --version
    cargo-crev 0.19.0
    # Installation:
    curl -L "https://github.com/crev-dev/cargo-crev/releases/download/v0.19.0/cargo-crev-v0.19.0-x86_64-apple-darwin.tar.gz" | tar -zxv - --directory ~/.cargo/bin --strip-components=1 cargo-crev-v0.19.0-x86_64-apple-darwin/cargo-crev
    

    Platform used: macOS Catalina 10.15.7.

    Thanks a lot!!

    Reviewed by nbigaouette at 2021-02-25 17:42
  • 16. Supporting usage without full crev id

    Currently crev verify uses empty TrustSet when own id is not configured, but a completely empty set is not reporting anything. That makes a poor first impression.

    Some trusted reviews could be easily added with a couple of crev trust …, but currently this also unhelpfully fails with "Current Id not set". Setting up an Id requires configuring a proof repo and a passphrase. That's a steep curve to run just one command.

    So I'm looking into:

    • Letting commands like verify run with non-empty ad-hoc trust sets. For example crev verify --trust https://proofs-repo could be useful in CI where you don't want to set up an identity, but want to automatically verify dependencies.

    • Allowing gradual setup of a CrevId, so that they can be configured with trust information without configuring publishing.

    • Having commands guide user to configure the missing parts as-needed, like adding trusted ids or configuring publishing URL.

    Reviewed by kornelski at 2021-02-21 11:39
A Linter for bevy code

Bevy Lint What is Bevy Lint? This crates provides Lints for Bevy Code using dylint.

Jun 18, 2022
Source code spell checker

eztd is meant to close the ergonomics gap between Rust and Python.

Jun 3, 2022
Detects usage of unsafe Rust in a Rust crate and its dependencies.
Detects usage of unsafe Rust in a Rust crate and its dependencies.

cargo-geiger ☢️ A program that lists statistics related to the usage of unsafe Rust code in a Rust crate and all its dependencies. This cargo plugin w

Jun 22, 2022
Find the ideal fuzz targets in a Rust codebase

Siderophile Siderophile finds the "most unsafe" functions in your Rust codebase, so you can fuzz them or refactor them out entirely. It checks the cal

Jun 7, 2022
Rust Memory Safety & Undefined Behavior Detection

Rudra is a static analyzer to detect common undefined behaviors in Rust programs. It is capable of analyzing single Rust packages as well as all the packages on crates.io.

Jun 22, 2022
A cryptographically verifiable code review system for the cargo (Rust) package manager.
A cryptographically verifiable code review system for the cargo (Rust) package manager.

image credit cargo-crev A cryptographically verifiable code review system for the cargo (Rust) package manager. Introduction Crev is a language and ec

Jun 17, 2022
A cryptographically verifiable code review system for the cargo (Rust) package manager.
A cryptographically verifiable code review system for the cargo (Rust) package manager.

image credit cargo-crev A cryptographically verifiable code review system for the cargo (Rust) package manager. Introduction Crev is a language and ec

Jun 25, 2022
A distributed, cryptographically-verifiable blog / social network

FeoBlog FeoBlog is a distributed blogging platform. It takes a lot of its inspiration from Mastodon and Scuttlebutt. It aims to solve a couple of prob

Jun 10, 2022
Distributed, version controlled, SQL database with cryptographically verifiable storage, queries and results. Think git for postgres.

SDB - SignatureDB Distributed, version controlled, SQL database with cryptographically verifiable storage, queries and results. Think git for postgres

Apr 26, 2022
Easy c̵̰͠r̵̛̠ö̴̪s̶̩̒s̵̭̀-t̶̲͝h̶̯̚r̵̺͐e̷̖̽ḁ̴̍d̶̖̔ ȓ̵͙ė̶͎ḟ̴͙e̸̖͛r̶̖͗ë̶̱́ṉ̵̒ĉ̷̥e̷͚̍ s̷̹͌h̷̲̉a̵̭͋r̷̫̊ḭ̵̊n̷̬͂g̵̦̃ f̶̻̊ơ̵̜ṟ̸̈́ R̵̞̋ù̵̺s̷̖̅ţ̸͗!̸̼͋

Rust S̵̓i̸̓n̵̉ I̴n̴f̶e̸r̵n̷a̴l mutability! Howdy, friendly Rust developer! Ever had a value get m̵̯̅ð̶͊v̴̮̾ê̴̼͘d away right under your nose just when

Jun 24, 2022
Experimental package manager/system configurator for system hoppers

mascara An experimental package manager/config initializer tool for system hoppers. mascara.toml [mascara] feature = "Debian" logs = { stdout = "blue"

Apr 15, 2022
Cargo - The Rust package manager

Cargo downloads your Rust project’s dependencies and compiles your project.

Jun 17, 2022
Wally is a modern package manager for Roblox projects inspired by Cargo

Wally is a package manager for Roblox inspired by Cargo (Rust) and npm (JavaScript). It brings the familiar, community-oriented world of sharing code from other communities into the Roblox ecosystem.

Jun 24, 2022
Easy to use, configurable C/C++ package manager and build system

Easy to use, configurable C/C++ package manager and build system

Apr 23, 2022
BSP 19&20&21 Review tool

BSP review tool Limitations PAKFILE&ENTITIES lumps can't be bigger than the original ToDo WASM - needs file action interops Proper serialisation - rig

Sep 25, 2021
A package manager for the Lite-XL code editor

Lite-XL Package Manager (lpm) (Under Development) lpm is an attempt to create a package manager for the Lite-XL code editor. It's primary goal is to p

Mar 20, 2022
Cargo-eval - A cargo plugin to quickly evaluate some Rust source code.

cargo eval A cargo plugin to quickly evaluate some Rust source code. Installation $ cargo install --git https://github.com/timClicks/cargo-eval.git Us

Jan 1, 2022
A shiny new package manager written in rust explicitly for gemlock/linux and it's distributions

Gem A shiny new package manager written in rust explicitly for gemlock/linux and it's distributions. List of content How to setup Systems Ubuntu Arch

Feb 22, 2022
Yet another package manager for Rust.

Rpip Installing. Make sure you have just (packages) installed! Once you have just installed move into the root directory (where this file is) and run

Apr 27, 2022
Semi-automatic OSINT framework and package manager

sn0int sn0int (pronounced /snoɪnt/) is a semi-automatic OSINT framework and package manager. It was built for IT security professionals and bug hunter

Jun 23, 2022