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

Overview

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

Comments
  • cargo_crev_web - web server to query reviews from cargo-crev

    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.

    opened by bestia-dev 36
  • Own trust should override Web of Trust

    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.

    opened by kornelski 24
  • Is signing worth it?

    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?

    opened by Alexendoo 24
  • Usability issues with the command-line interface

    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.

    opened by kornelski 22
  • Add new

    Add new "proof reissue" command

    PoC implementation for this discussion: https://github.com/crev-dev/cargo-crev/discussions/492 "How to deal with a person leaving an organization?"

    This commands allows to find existing proofs and sign them again with a different id.

    This comes in handy when an id is going be revoked but the trust of the existing reviews should be retained by a new id.

    Scenarios:

    • Old id got compromised
    • Person leaves an organization, so organization can reissue existing reviews using a different id to maintain trust level.

    Checklist:

    • [x] cargo +nightly fmt --all
    • [ ] Modify CHANGELOG.md if applicable

    Code is originally based upon the "proof find" code.

    opened by thomasjfox 20
  • Can't commit or pull reviews: UnbornBranch

    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.

    bug enhancement maybe? 
    opened by kornelski 17
  • Want to help? Just try out `cargo crev` and give feedback.

    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.

    help needed good first issue 
    opened by dpc 17
  • Unable to connect to repo using Gitlab Access Token

    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:token@url

    When I do, I get the following error:

    Couldn't clone https:username:token@url remote authentication required but no callback set; class=Http (34)

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

    opened by desandy 16
  • Verification does not work as expected

    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?

    bug 
    opened by hirschenberger 16
  • Setup remote Github repo if username available

    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.

    opened by ffranr 16
  • Add new crev logo.

    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

    opened by ffranr 15
  • Bump derive_builder from 0.11.2 to 0.12.0

    Bump derive_builder from 0.11.2 to 0.12.0

    Bumps derive_builder from 0.11.2 to 0.12.0.

    Release notes

    Sourced from derive_builder's releases.

    v0.12.0

    • Produce error when default is used with field(type = "...") rather than silently ignoring default #269
    • Add support for crate = "..." to support re-export scenarios #274
    Commits
    • 5705f00 Bump version to 0.12.0
    • 378a3a3 Don't hide the Builder macro in docs
    • 2439b97 Add compile tests for crate = "..."
    • 757a8c5 Update unit tests to use ::db
    • e872faf Add #[builder(crate = "...")] at struct level
    • 53fd62f Fix spelling: conusuming -> consuming
    • 48a3033 Fix typo in custom setter documentation
    • e2a1a7b Produce error for default with field.type
    • 5cf5f0a Split trybuild tests out to own job
    • 45cf09a NFC: Remove unused lifetime
    • See full diff in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies rust 
    opened by dependabot[bot] 0
  • Bump blake2 from 0.9.2 to 0.10.6

    Bump blake2 from 0.9.2 to 0.10.6

    Bumps blake2 from 0.9.2 to 0.10.6.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies rust 
    opened by dependabot[bot] 0
  • Do not fetch anything after `cargo crev trust`

    Do not fetch anything after `cargo crev trust`

    I have just spent a bunch of time investigating a spooky error of not being able to fetch unrelated URL, after I was signing a trust proof.

    Fetching after creating new trust proof is a bit too much automation. It also delays the completion of the actual operation that was invoked.

    opened by dpc 4
  • Bump rprompt from 1.0.5 to 2.0.2

    Bump rprompt from 1.0.5 to 2.0.2

    Bumps rprompt from 1.0.5 to 2.0.2.

    Release notes

    Sourced from rprompt's releases.

    v2.0.2

    This release updates the API in line with recent changes in rpassword, to be more flexible.

    Migration guide

    Replace prompt_reply_stdout and prompt_reply_stderr with prompt_reply and in most cases you should be fine. The new function prints to the TTY, so if you rely on the output being on stdout/stderr, you'll have to use the prompt_reply_from_bufread version, passing std::io::stdin(), std::io::stdout() and/or std::io::stderr() as arguments.

    ⚠️ The read_reply() now reads from the TTY instead of stdin, so if you need the old behavior, use read_reply_from_bufread in combination with std::io::stdin(). This should be fine in most cases, but may break code using pipes.

    API changes

    Old API was:

    fn prompt_reply_stdout(prompt: &str) -> std::io::Result<String>
    fn prompt_reply_stderr(prompt: &str) -> std::io::Result<String>
    

    fn read_reply() -> std::io::Result<String>

    New API is:

    fn prompt_reply(prompt: impl ToString) -> std::io::Result<String>
    fn prompt_reply_from_bufread(reader: &mut impl BufRead, writer: &mut impl Write, prompt: impl ToString) -> std::io::Result<String>
    

    fn read_reply() -> std::io::Result<String> fn read_reply_from_bufread(reader: &mut impl BufRead) -> std::io::Result<String>

    Commits
    • 45a72f9 Publish rprompt, rclio and rooster
    • 8f7e807 Remove tests of individual crates
    • 32f601f Rename rutil to rtoolbox for publishing to crates.io
    • ae4ea51 Add contributing guidelines
    • 4e079a3 Simplify directory structure after switch to workspaces
    • d9716f3 Use Cargo workspaces instead of symlinks
    • b3b24c2 Handle Ctrl-U in rpassword
    • ef3972d Fix use of serde after removing it from rpassword
    • ca4e559 Remove serde dependencies from rpassword
    • 707d79f Bump rpassword to 6.0.0
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies rust 
    opened by dependabot[bot] 0
  • Bump base64 from 0.13.1 to 0.20.0

    Bump base64 from 0.13.1 to 0.20.0

    Bumps base64 from 0.13.1 to 0.20.0.

    Changelog

    Sourced from base64's changelog.

    0.20.0

    Breaking changes

    • Update MSRV to 1.57.0
    • Decoding can now either ignore padding, require correct padding, or require no padding. The default is to require correct padding.
      • The NO_PAD config now requires that padding be absent when decoding.

    0.20.0-alpha.1

    Breaking changes

    • Extended the Config concept into the Engine abstraction, allowing the user to pick different encoding / decoding implementations.
      • What was formerly the only algorithm is now the FastPortable engine, so named because it's portable (works on any CPU) and relatively fast.
      • This opens the door to a portable constant-time implementation (#153, presumably ConstantTimePortable?) for security-sensitive applications that need side-channel resistance, and CPU-specific SIMD implementations for more speed.
      • Standard base64 per the RFC is available via DEFAULT_ENGINE. To use different alphabets or other settings (padding, etc), create your own engine instance.
    • CharacterSet is now Alphabet (per the RFC), and allows creating custom alphabets. The corresponding tables that were previously code-generated are now built dynamically.
    • Since there are already multiple breaking changes, various functions are renamed to be more consistent and discoverable.
    • MSRV is now 1.47.0 to allow various things to use const fn.
    • DecoderReader now owns its inner reader, and can expose it via into_inner(). For symmetry, EncoderWriter can do the same with its writer.
    • encoded_len is now public so you can size encode buffers precisely.
    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies rust 
    opened by dependabot[bot] 0
  • Maintain reasonable MSRV so that this has chance of being packaged in distros

    Maintain reasonable MSRV so that this has chance of being packaged in distros

    The protection cargo-crev provides is flawed if cargo-crev itself can't be securely installed. Distro packaging is a very convenient and secure way to do that. However it needs a reasonable MSRV.

    The current MSRV seems to be 1.62.0 which is just above 1.61.0 being in Debian Bookworm (will be stable in a few months). Because I'm currently unable to get bookworm running I tried "packaging" 0.23.0 and there seem to be quite a few missing dependencies so it won't be an easy task.

    opened by Kixunil 0
Releases(v0.23.3)
Owner
crev - Code REView system
Repositories for the crev project
crev - Code REView system
Secure sandboxing system for untrusted code execution

Godbox Secure sandboxing system for untrusted code execution. It uses isolate which uses specific functionnalities of the Linux kernel, thus godbox no

Nathanael Demacon 19 Dec 14, 2022
Audit Cargo.lock files for dependencies with security vulnerabilities

RustSec Crates ?? ??️ ?? The RustSec Advisory Database is a repository of security advisories filed against Rust crates published via crates.io. The a

RustSec 1.2k Jan 5, 2023
A simple password manager written in Rust

ripasso A simple password manager written in Rust. The root crate ripasso is a library for accessing and decrypting passwords stored in pass format (G

Joakim Lundborg 548 Dec 26, 2022
MimiRust - Hacking the Windows operating system to hand us the keys to the kingdom with Rust.

MimiRust - Hacking the Windows operating system to hand us the keys to the kingdom with Rust. MimiRust is a program based on the wdigest attack vector

Thotty 0 Nov 29, 2022
Rust implementation of the H3 geospatial indexing system.

h3o Rust implementation of the H3 geospatial indexing system. Design This is not a binding of the reference implementation, but a reimplementation fro

Hydronium Labs 196 Jan 31, 2023
A private network system that uses WireGuard under the hood.

innernet A private network system that uses WireGuard under the hood. See the announcement blog post for a longer-winded explanation. innernet is simi

Tonari, Inc 4.1k Jan 6, 2023
Cover your tracks during Linux Exploitation by leaving zero traces on system logs and filesystem timestamps. 👻🐚

moonwalk Cover your tracks during Linux Exploitation / Penetration Testing by leaving zero traces on system logs and filesystem timestamps. ?? Table o

Mufeed VH 1.1k Jan 6, 2023
Cross-platform async library for system information fetching 🦀

heim Cross-platform library for system information fetching heim is an ongoing attempt to create the best tool for system information fetching (ex., C

null 782 Jan 2, 2023
Bottlerocket - An operating system designed for hosting containers

Bottlerocket OS Welcome to Bottlerocket! Bottlerocket is a free and open-source Linux-based operating system meant for hosting containers. If you’re r

null 7k Dec 31, 2022
Crate for calling NT System Calls easily

ntcall-rs Easily call NT System Calls from rust. All System Call ID’s are dumped at compile-time. To get started just import the function you would li

joshuа 7 Sep 14, 2022
cert_installer - a utility that adds a CA certificate to Android's System Trust Store

cert_installer is a utility that adds a CA certificate to Android's System Trust Store by overwriting the /system/etc/security/cacerts directory with a tmpfs mount. Changes made to the System Trust Store is not persistant across reboots.

Terry Chia 5 Apr 11, 2022
How-to: Sanitize your Rust code!

rust-san How-to: Sanitize your Rust code! Intro How to use the sanitizers? Examples AddressSanitizer Out of bounds access Use after free LeakSanitizer

Jorge Aparicio 359 Dec 22, 2022
Breaking your Rust code for fun and profit

Breaking your Rust code for fun & profit this is an architecture-preview, not all components are there This is a mutation testing framework for Rust c

null 542 Jan 4, 2023
Using fibers to run in-memory code in a different and stealthy way.

Description A fiber is a unit of execution that must be manually scheduled by the application rather than rely on the priority-based scheduling mechan

Kurosh Dabbagh Escalante 121 Apr 20, 2023
A library for building tools to determine if vulnerabilities are reachable in a code base.

Overview Vuln Reach is a library for developing tools that determine if a given vulnerability is reachable. Provided to the open source community by P

Phylum 3 May 5, 2023
Detects usage of unsafe Rust in a Rust crate and its dependencies.

cargo-geiger ☢️ Looking for maintainer: https://github.com/rust-secure-code/cargo-geiger/issues/210 A program that lists statistics related to the usa

Rust Secure Code Working Group 1.1k Jan 4, 2023
An esoteric language/compiler written with Rust and Rust LLVM bindings

MeidoLang (メイドラング) A not so useful and esoteric language. The goal of this project was to contain some quirky or novel syntax in a stack-style program

null 0 Dec 24, 2021
Rust-verification-tools - RVT is a collection of tools/libraries to support both static and dynamic verification of Rust programs.

Rust verification tools This is a collection of tools/libraries to support both static and dynamic verification of Rust programs. We see static verifi

null 253 Dec 31, 2022
Rust bindings for libinjection

libinjection-rs Rust bindings for libinjection. How to use Add libinjection to dependencies of Cargo.toml: libinjection = "0.2" Import crate: extern c

ArvanCloud 35 Sep 24, 2022