Safe, fast, small crypto using Rust

Overview

THE SOFTWARE IS PROVIDED "AS IS" AND BRIAN SMITH AND THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL BRIAN SMITH OR THE AUTHORS BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

ring

ring is focused on the implementation, testing, and optimization of a core set of cryptographic operations exposed via an easy-to-use (and hard-to-misuse) API. ring exposes a Rust API and is written in a hybrid of Rust, C, and assembly language.

Particular attention is being paid to making it easy to build and integrate ring into applications and higher-level frameworks, and to ensuring that ring works optimally on small devices, and eventually microcontrollers, to support Internet of Things (IoT) applications.

ring is focused on general-purpose cryptography. WebPKI X.509 certificate validation is done in the webpki project, which is built on top of ring. Also, multiple groups are working on implementations of cryptographic protocols like TLS, SSH, and DNSSEC on top of ring.

ring is the successor of an earlier project called GFp. GFp implemented some elliptic curve cryptography over prime finite fields, also known as prime Galois fields and often denoted GF(p). When we implemented RSA, the name GFp did not make as much sense, since modular arithmetic over RSA public moduli is not GF(p) arithmetic but rather finite commutative ring arithmetic. Also note that ring started as a subset of BoringSSL, and “ring” is a substring of “BoringSSL”.

Most of the C and assembly language code in ring comes from BoringSSL, and BoringSSL is derived from OpenSSL. ring merges changes from BoringSSL regularly. Also, several changes that were developed for ring have already been merged into BoringSSL.

Documentation

See the documentation at https://briansmith.org/rustdoc/ring/.

See BUILDING.md for instructions on how to build it. These instructions are especially important for cross-compiling and for building on Windows when not building from crates.io, as there are build prerequisites that need to be installed.

Benchmarks

ring's benchmarks are in the crypto-bench project. Because there is lots of platform-specific code in ring, and because ring chooses dynamically at runtime which optimized implementation of each crypto primitive to use, it is very difficult to publish a useful single set of benchmarks; instead, you are highly encouraged to run the benchmarks yourselves on your target hardware.

Contributing

The most important contributions are uses of ring. That is, we're very interested in seeing useful things built on top of ring, like implementations of TLS, SSH, the Noise Protocol, etc.

Of course, contributions to ring's code base are highly appreciated too. The ring project happily accepts pull requests without you needing to sign any formal license agreement. The portions of pull requests that modify existing files must be licensed under the same terms as the files being modified. New files in pull requests, including in particular all Rust code, must be licensed under the ISC-style license. Please state that you agree to license your contributions in the commit messages of commits in pull requests, e.g. by putting this at the bottom of your commit message:


I agree to license my contributions to each file under the terms given
at the top of each file I changed.

If you want to work directly on ring and you don't have an idea for something to contribute already, see these curated lists of open issues:

  • good-first-bug: Bugs that we think newcomers might find best to start with. Note that what makes a bug a good fit depends a lot on the developer's background and not just the hardness of the work.

In addition, we're always interested in these kinds of contributions:

  • Expanded benchmarks in the crypto-bench project.
  • Additional testing code and additional test vectors.
  • Static analysis and fuzzing in the continuous integration.
  • Support for more platforms in the continuous integration (e.g. Android, iOS, ARM microcontrollers).
  • Documentation improvements.
  • More code simplification, especially eliminating dead code.
  • Improving the code size, execution speed, and/or memory footprint.
  • Fixing any bugs you may have found.
  • Better IDE support for Windows (e.g. running the tests within the IDE) and macOS (e.g. Xcode project files).

Before submitting pull requests, make sure that the tests succeed both when running cargo test and cargo test --no-default-features. See BUILDING.md for more info about the features flags that are useful for people hacking on ring.

Versioning & Stability

Users of ring should always use the latest released version, and users should upgrade to the latest released version as soon as it is released. ring has a linear release model that favors users of the latest released version. We have never backported fixes to earlier releases and we don't maintain branches other than the main branch. Further, for some obscure technical reasons it's currently not possible to link two different versions of ring into the same program; for policy reasons we don't bother to try to work around that. Thus it is important that libraries using ring update to the latest version of ring ASAP, so that libraries that depend on their libraries can upgrade to the latest version of ring.

ring is tested on the latest Stable, Beta, and Nightly releases of Rust. We do not spend effort on backward compatibility with older releases of Rust; for example, when Rust 1.53 (Stable) is released, we don't care if ring stops working with Rust 1.52 or earlier versions. Thus, we can always use the latest stable features of the Rust language in ring. So far we've never used unstable features of Rust except for the benchmarking support (#[bench]), and we're hoping to remove even that Nightly dependency. Sometimes things are broken with Nightly Rust. We prioritize keeping things working on Stable; if things break on Beta and Nightly then that breakage won't be considered urgent, though it will eventually get resolved, one way or another.

We prefer to improve ring's API over keeping ring's API stable. We don't keep old APIs around for the sake of backward compatibility; we prefer to remove old APIs in the same change that adds new APIs. This makes it easier for people to contribute improvements. This means that sometimes upgrading to the newest version of ring will require some code changes. Over time the rate of change in the API will probably slow to the point where it will be stable in practice.

We don't have release notes. Instead, we try to clearly document each change in each commit. Read the the commit message, the tests, and the patch itself for each change. If anything is still unclear, let us know by submitting a pull request or by filing an issue in the issue tracker so that we can improve things.

This model of development is different than the model a lot of other open source libraries use. The idea behind our model is to encourage all users to work together to ensure that the latest version is good as it is being developed. In particular, because users know that correctness/security fixes (if any) aren't going to get backported, they have a strong incentive to help review pull requests before they are merged and/or review commits on the main branch after they've landed to ensure that code quality on the main branch stays high.

The more common model, where there are stable versions that have important security patches backported, lowers people's incentives to actively participate in mainline development. Maintaining stable APIs also discourages improving API design and internal code quality. Thus that model doesn't seem like a good fit for ring.

Every six months we have a meeting to revisit this policy. Email [email protected] if you want to attend the next meeting. Please don't file issues regarding this policy.

Bug Reporting

Please report bugs either as pull requests or as issues in the issue tracker. ring has a full disclosure vulnerability policy. Please do NOT attempt to report any security vulnerability in this code privately to anybody.

Online Automated Testing

The following targets are tested in GitHub Actions. The tests are run in debug and release configurations, for the current release of each Rust channel (Stable, Beta, Nightly). A C compiler is currently required to compile some parts of ring; ring should be compatible with GCC 4.8+, Clang 10+, and MSVC 2019+, at least.

Target Notes
aarch64-apple-darwin Build-only (GitHub Actions doesn't have a way to run the tests)
aarch64-apple-ios Build-only (GitHub Actions doesn't have a way to run the tests)
aarch64-unknown-linux-gnu Tested on 64-bit Linux using QEMU user emulation
aarch64-unknown-linux-musl Tested on 64-bit Linux using QEMU user emulation. Needs more work; issue 713
aarch64-linux-android API level 21 (Android 5.0+); Build-only; issue 486
arm-unknown-linux-gnueabihf Tested on 64-bit Linux using QEMU user emulation
armv7-linux-androideabi API level 18 (Android 4.3+); Build-only; issue 838
armv7-unknown-linux-musleabihf Tested on 64-bit Linux using QEMU user emulation. Needs more work; issue 713
i686-pc-windows-msvc Tested on 64-bit Windows Server 2019 Datacenter
i686-unknown-linux-gnu Tested on 64-bit Linux using multilib support
i686-unknown-linux-musl Tested on 64-bit Linux using multilib support. Needs more work; issue 713
x86_64-apple-darwin
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc Tested on 64-bit Windows Server 2019 Datacenter
x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl Needs more work; issue 713
wasm32-unknown-unknown Tested using wasm-bindgen-test-runner on Linux in Chrome and Firefox.

License

See LICENSE.

Comments
  • Version all C/asm symbols to enable cross-version linking.

    Version all C/asm symbols to enable cross-version linking.

    Resolves #535.

    Due to a bug in the current stable Rust compiler (https://github.com/rust-lang/rust/issues/44851), this fix won't work on a stable release until the next stable version. Thankfully this is only a few days away as version 1.23 is scheduled to be released on January 4, 2018.

    I've tested this on OS X, Linux (Debian), and Windows (Server 2016) with cargo test and cargo test --features=rsa_signing. I've confirmed that all public symbols exported from compiled binaries are versioned on each of these platforms. The only caveat is that I'm getting a warning somewhere along the chain on Windows that I've yet to track down.

    This makes use of a new crate I've written for this purpose; I've named that crate native_versioning for now. For an explanation of how this works, please see that crate's docs. In short:

    The general idea is that all symbols in C, C++, and assembly code are mangled with the current crate version. For instance, a symbol some_func will become some_func_v1_23_2_beta. On the Rust side, all symbols will be linked to using the mangled name. The C, C++, and assembly name mangling will happen transparently; only a versioned.h file needs to be maintained, and no changes need to be made to the C, C++, or assembly code. On the Rust side, all non-system extern blocks are modified to use the versioned_extern! macro.

    Once the PR is ready to be accepted, I'll publish the native_versioning crate and update the PR with the crate's final name.

    opened by SergioBenitez 45
  • Implement RSA PSS verification and signing.

    Implement RSA PSS verification and signing.

    Steps taken so far:

    • Create separate module for padding.
    • Refactor existing PKCS padding to use this system.
    • Implement PSS padding (encoding and verification).
    • Add test cases for PSS signatures.

    This is a bit rough at the moment. There are some fairly large changes made by this so I thought it would be best to put it out there for feedback before proceeding.

    Relevant issues: #115 and #213

    opened by samscott89 43
  • [On Hold] Add support for builds without assembly.

    [On Hold] Add support for builds without assembly.

    Set feature "no_asm" to use. This currently disables use of aead, ec, and rsa/signature modules due to missing code.

    Also adds the mipsel-unknown-linux-gnu target to the travis builds. These builds currently fail in anticipation of PR#199.

    opened by samscott89 40
  • Detect cpu features on ARM with getauxval()

    Detect cpu features on ARM with getauxval()

    This is 1 and 2 of your suggested PR disassembly in #392. I elected to do them together because otherwise this would have failed to build on arm because there wouldn't be a replacement for GFp_cpuid_setup.

    opened by marshallpierce 39
  • [WIP]: Rsa keygen

    [WIP]: Rsa keygen

    Opened the PR so that I can discuss with @briansmith about the code. Nothing works yet. DON'T MERGE!

    List of tasks:

    • [x] Implement division by small primes as suggested here
    • [x] Implement miller-rabin primality test based on FIPS 186-4 C.3.1
    • [x] Tests for the miller-rabin primality test
    • [x] Implement FIPS 186-4 section B 3.3 algorithm to obtain (p,q) prime pair
    • [x] Use (p,q) to create the needed p,q,dP,dQ,qInv,r_i,d_i,t_i
    • [x] DER formatting of the created key
    • [ ] Implement primitive for multiplication
    • [x] Implement primitive for inverse modulo m

    Important reading:

    • FIPS 186-4: https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.186-4.pdf
    • https://eprint.iacr.org/2018/749
    • https://tools.ietf.org/html/draft-mavrogiannopoulos-pkcs8-validated-parameters-00
    • Formatting of the keys: https://tools.ietf.org/html/rfc5958 and https://tools.ietf.org/html/rfc3447#section-3

    Fixes #219

    opened by est31 37
  • Add ECDSA P-256 signing support

    Add ECDSA P-256 signing support

    This is harder than EdDSA because there's no code to do the actual ECDSA signing anymore; the ECDSA_sign function in crypto/ecdsa/ecdsa.c was removed to help with the migration to the new Rust ECC code. So, a new implementation of ECDSA signing in Rust is necessary.

    For all platforms it is OK (preferable, even) to use crypto::ec::PrivateKey::generate for the key generation (i.e. base point multiplication). So, that part is already done.

    I have some code sitting around to do the constant-time modular inversions (mod q) and (mod n). I will try to integrate it...soonish.

    For 64-bit platforms, we can use crypto/ec/p256-64.c and crypto/ec/p256-x86_64.c for the variable point multiplication (the multiplication done during the signing operation). However, we don't have any usable code for 32-bit platforms yet (at least, not checked in).

    For 32-bit ARM, x86, and AAarch64, I will eventually import in the ecp_nistz256 field operations from OpenSSL. Actually, I'm planning to do this real soon. However, I don't think the ecp_nistz256 group operations are good to use for any platform except x86-64 (even then...). We might try, instead, adapting the p256-64.c variable point multiplication to work using the ecp_nistz256 field operations (which would require adapting it to work on Montgomery-encoded field elements).

    Similarly, we need to do make new nonce generation, as the old C code that Adam Langley wrote was removed. It may be worth copying how golang is doing it. Regardless, it would be nice to do as much of this as possible in Rust.

    NIST has some test vectors for ECDSA signing, which are the absolute minimum level of testing necessary before the API can be exposed.

    There is also no code for serializing private keys or deserializing them, which is pretty essential to most users of ECDSA signing. This should probably be split off into its own task as it is a fair amount of work on its own.

    See also any general notes about signing APIs in #205.

    opened by briansmith 36
  • Start Ed25519 port

    Start Ed25519 port

    For #459.

    Todo:

    • [x] Try out a guard!/check! macro
    • [x] Change private representation of Ed25519KeyPair
    • [ ] Avoid unnecessary recomputations
    • [ ] Add comments
    • [ ] Gather updated benchmarks
    opened by ranweiler 35
  • spin-rs no longer maintained (dependency)

    spin-rs no longer maintained (dependency)

    https://rustsec.org/advisories/RUSTSEC-2019-0031

    The spin dependency is no longer maintained it appears. This causes cargo audit to fail on downstream projects. I haven't had a chance to look into potential fixes.

    opened by bluejekyll 33
  • add `powerpc` target

    add `powerpc` target

    10: 0x10307a6b7 - build_script_build::build_c_code::hd9ffeb4799056596 at /Users/fl0120/github/ring/build.rs:372 11: 0x10307996d - build_script_build::ring_build_rs_main::h5507f897a7458b6f at /Users/fl0120/github/ring/build.rs:294 12: 0x10307910e - build_script_build::main::h912ac4a7682e0b5c at /Users/fl0120/github/ring/build.rs:256

    When cross compile ring for power target which not in ASM_TARGETS, the build.rs will crash on unwrap()

    RustCrypto/hashes#82

    opened by flier 32
  • Compilation fails on aarch64-apple-darwin

    Compilation fails on aarch64-apple-darwin

    I noticed it in the CI output of https://github.com/rust-lang/rustup/pull/2517 :

      running "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-arch" "arm64" "-I" "include" "-Wall" "-Wextra" "-pedantic" "-pedantic-errors" "-Wall" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-fstack-protector" "-gfull" "-DNDEBUG" "-c" "-o/Users/runner/work/rustup/rustup/target/aarch64-apple-darwin/release/build/ring-fcf530fe8716448c/out/aesv8-armx-linux64.o" "/Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S"
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:18:17: error: unexpected token in '.section' directive
      .section .rodata
                      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:28:1: error: unknown directive
      .hidden GFp_aes_hw_set_encrypt_key
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:29:1: error: unknown directive
      .type GFp_aes_hw_set_encrypt_key,%function
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:161:1: error: unknown directive
      .size GFp_aes_hw_set_encrypt_key,.-GFp_aes_hw_set_encrypt_key
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:163:1: error: unknown directive
      .hidden GFp_aes_hw_encrypt
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:164:1: error: unknown directive
      .type GFp_aes_hw_encrypt,%function
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:191:1: error: unknown directive
      .size GFp_aes_hw_encrypt,.-GFp_aes_hw_encrypt
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:193:1: error: unknown directive
      .hidden GFp_aes_hw_decrypt
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:194:1: error: unknown directive
      .type GFp_aes_hw_decrypt,%function
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:221:1: error: unknown directive
      .size GFp_aes_hw_decrypt,.-GFp_aes_hw_decrypt
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:223:1: error: unknown directive
      .hidden GFp_aes_hw_ctr32_encrypt_blocks
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:224:1: error: unknown directive
      .type GFp_aes_hw_ctr32_encrypt_blocks,%function
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:403:1: error: unknown directive
      .size GFp_aes_hw_ctr32_encrypt_blocks,.-GFp_aes_hw_ctr32_encrypt_blocks
      ^
      /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:407:19: error: unexpected token in '.section' directive
      .section .note.GNU-stack,"",%progbits
                        ^
      thread 'main' panicked at 'execution failed', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/build.rs:664:9
    

    cc @shepmaster

    opened by est31 30
  • Why were all versions prior to 0.14 of this crate yanked?

    Why were all versions prior to 0.14 of this crate yanked?

    On January 10 all versions from 0.9.4 to 0.14.0-alpha4 were yanked, along with the versions of untrusted that they depended on. This has broken the build of any crate which had a dependency on older versions of ring anywhere in their build. For example, crates.io can no longer accept any pull request which makes any changes to our Cargo.toml, as any attempts to do so will resolve several of our dependencies to ancient versions from before they depended on Ring, since the versions used can no longer be resolved.

    Was there a reason for yanking all of these versions? Yanking is typically only done if there is a severe bug or security vulnerability found in a version, but I cannot find any security advisory involving Ring. I also can't find a changelog anywhere to see if there was a critical fix listed in 0.14.

    Given the severe effects this has on the ecosystem, could you elaborate on why these were yanked?

    opened by sgrif 30
  • Failed  to run custom build command targeting aarch64-unknown-linux-gnu

    Failed to run custom build command targeting aarch64-unknown-linux-gnu

    Hey,

    I am trying to cross compile it on windows for aarch64 linux sytem. I found the following problem. The error was reproduced in some computers.

    The command was cargo build --target aarch64-unknown-linux-gnu .

    error: failed to run custom build command for ring v0.16.20

    Caused by: process didn't exit successfully: G:\client\target\debug\build\ring-450a68265133bae7\build-script-build (exit code: 101) --- stdout OPT_LEVEL = Some("0") TARGET = Some("aarch64-unknown-linux-gnu") HOST = Some("x86_64-pc-windows-msvc") cargo:rerun-if-env-changed=CC_aarch64-unknown-linux-gnu CC_aarch64-unknown-linux-gnu = None cargo:rerun-if-env-changed=CC_aarch64_unknown_linux_gnu CC_aarch64_unknown_linux_gnu = None cargo:rerun-if-env-changed=TARGET_CC TARGET_CC = None cargo:rerun-if-env-changed=CC CC = None RUSTC_LINKER = Some("G:\Program Files (x86)\Arm GNU Toolchain aarch64-none-linux-gnu\12.2 rel1\bin\aarch64-none-linux-gnu-gcc") cargo:rerun-if-env-changed=CROSS_COMPILE CROSS_COMPILE = None cargo:rerun-if-env-changed=CFLAGS_aarch64-unknown-linux-gnu CFLAGS_aarch64-unknown-linux-gnu = None cargo:rerun-if-env-changed=CFLAGS_aarch64_unknown_linux_gnu CFLAGS_aarch64_unknown_linux_gnu = None cargo:rerun-if-env-changed=TARGET_CFLAGS TARGET_CFLAGS = None cargo:rerun-if-env-changed=CFLAGS CFLAGS = None cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS CRATE_CC_NO_DEFAULTS = None DEBUG = Some("true") CARGO_CFG_TARGET_FEATURE = Some("neon")

    --- stderr running "aarch64-linux-gnu-gcc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-4" "-fno-omit-frame-pointer" "-I" "include" "-Wall" "-Wextra" "-pedantic" "-pedantic-errors" "-Wall" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-fstack-protector" "-g3" "-DNDEBUG" "-c" "-oG:\4.installedSoftware\office365\client\target\aarch64-unknown-linux-gnu\debug\build\ring-c28f4785134456e7\out\aesv8-armx-linux64.o" "C:\Users\admin\.cargo\registry\src\rsproxy.cn-8f6827c7555bfaf8\ring-0.16.20\pregenerated\aesv8-armx-linux64.S" thread 'main' panicked at 'failed to execute ["aarch64-linux-gnu-gcc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-4" "-fno-omit-frame-pointer" "-I" "include" "-Wall" "-Wextra" "-pedantic" "-pedantic-errors" "-Wall" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-fstack-protector" "-g3" "-DNDEBUG" "-c" "-oG:\4.installedSoftware\office365\client\target\aarch64-unknown-linux-gnu\debug\build\ring-c28f4785134456e7\out\aesv8-armx-linux64.o" "C:\Users\admin\.cargo\registry\src\rsproxy.cn-8f6827c7555bfaf8\ring-0.16.20\pregenerated\aesv8-armx-linux64.S"]: program not found', C:\Users\admin.cargo\registry\src\rsproxy.cn-8f6827c7555bfaf8\ring-0.16.20\build.rs:653:9 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace warning: build failed, waiting for other jobs to finish...

    opened by youngzhaozju 0
  • Failed to build with PMOS build system

    Failed to build with PMOS build system

    error: failed to run custom build command for `ring v0.16.20`
    
    Caused by:
      process didn't exit successfully: `/home/pmos/build/src/messenger-notify-0.2.3/target/release/build/ring-9d8e9630d389e5ef/build-script-build` (exit status: 101)
      --- stdout
      OPT_LEVEL = Some("s")
      TARGET = Some("x86_64-alpine-linux-musl")
      HOST = Some("x86_64-alpine-linux-musl")
      CC_x86_64-alpine-linux-musl = None
      CC_x86_64_alpine_linux_musl = None
      HOST_CC = None
      CC = Some("gcc")
      CFLAGS_x86_64-alpine-linux-musl = None
      CFLAGS_x86_64_alpine_linux_musl = None
      HOST_CFLAGS = None
      CFLAGS = Some("-Os -fomit-frame-pointer")
      CRATE_CC_NO_DEFAULTS = None
      DEBUG = Some("false")
      CARGO_CFG_TARGET_FEATURE = Some("neon")
    
      --- stderr
      running "gcc" "-Os" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-Os" "-fomit-frame-pointer" "-I" "include" "-pedantic" "-pedantic-errors" "-Wall" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-fstack-protector" "-g3" "-U_FORTIFY_SOURCE" "-DNDEBUG" "-c" "-o/home/pmos/build/src/messenger-notify-0.2.3/target/release/build/ring-082db86d6dcfc6fc/out/aesv8-armx-linux64.o" "/home/pmos/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/pregenerated/aesv8-armx-linux64.S"
      aarch64-alpine-linux-musl-gcc: error: unrecognized command-line option '-m64'
    
    opened by bellegarde-c 0
  • build error

    build error

    The crate compiles properly with Linux and with the msvc toolchain but fails with gnu toolchain (other crates compile OK):

    Compiling ring v0.16.20
    error: failed to run custom build command for `ring v0.16.20`
    
    Caused by:
     process didn't exit successfully: `C:\Users\01894832\RUST\iris\target\release\build\ring-eafcd483b9227c36\build-script-build` (exit code: 101)
     --- stdout
     OPT_LEVEL = Some("3")
     TARGET = Some("x86_64-pc-windows-gnu")
     HOST = Some("x86_64-pc-windows-gnu")
     cargo:rerun-if-env-changed=CC_x86_64-pc-windows-gnu
     CC_x86_64-pc-windows-gnu = None
     cargo:rerun-if-env-changed=CC_x86_64_pc_windows_gnu
     CC_x86_64_pc_windows_gnu = None
     cargo:rerun-if-env-changed=HOST_CC
     HOST_CC = None
     cargo:rerun-if-env-changed=CC
     CC = None
     cargo:rerun-if-env-changed=CFLAGS_x86_64-pc-windows-gnu
     CFLAGS_x86_64-pc-windows-gnu = None
     cargo:rerun-if-env-changed=CFLAGS_x86_64_pc_windows_gnu
     CFLAGS_x86_64_pc_windows_gnu = None
     cargo:rerun-if-env-changed=HOST_CFLAGS
     HOST_CFLAGS = None
     cargo:rerun-if-env-changed=CFLAGS
     CFLAGS = None
     cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
     CRATE_CC_NO_DEFAULTS = None
     DEBUG = Some("false")
     CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
    
     --- stderr
     running "gcc.exe" "-O3" "-ffunction-sections" "-fdata-sections" "-m64" "-I" "include" "-Wall" "-Wextra" "-std=c1x" "-Wbad-function-cast" "-Wnested-externs" "-Wstrict-prototypes" "-pedantic" "-pedantic-errors" "-Wall" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-g3" "-DNDEBUG" "-c" "-oC:\\Users\\01894832\\RUST\\iris\\target\\release\\build\\ring-e163d10086ee687e\\out\\aes_nohw.o" "crypto/fipsmodule/aes/aes_nohw.c"
     thread 'main' panicked at 'failed to execute ["gcc.exe" "-O3" "-ffunction-sections" "-fdata-sections" "-m64" "-I" "include" "-Wall" "-Wextra" "-std=c1x" "-Wbad-function-cast" "-Wnested-externs" "-Wstrict-prototypes" "-pedantic" "-pedantic-errors" "-Wall" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-g3" "-DNDEBUG" "-c" "-oC:\\Users\\01894832\\RUST\\iris\\target\\release\\build\\ring-e163d10086ee687e\\out\\aes_nohw.o" "crypto/fipsmodule/aes/aes_nohw.c"]: program not found', C:\Users\01894832\.cargo\registry\src\github.com-1ecc6299db9ec823\ring-0.16.20\build.rs:653:9
     note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    
    opened by james-elliot 0
  • Support for wasm32-wasi

    Support for wasm32-wasi

    This PR adds support for the wasm32-wasi target.

    To get the CI working, i had to use the dtolnay/rust-toolchain@stable action. The toolchain only seems to work when it is installed with rustup, see a similar issue here: https://bugs.archlinux.org/task/75269.

    Currently the clippy and audit CI runs are failing. I didn't include them in this PR because I thought it would make it more difficult to see the actual changes. If I should include the clippy and audit changes, please let me know.

    I agree to license my contributions to each file under the terms given at the top of each file I changed.

    opened by JanKaul 0
Owner
Brian Smith
Code farmer.
Brian Smith
Usable, easy and safe pure-Rust crypto

orion About Orion is a cryptography library written in pure Rust. It aims to provide easy and usable crypto while trying to minimize the use of unsafe

Orion - Rust cryptography library 477 Dec 29, 2022
Rust FFI bindings for StarkWare's crypto-cpp library

starkware-crypto-rs Rust FFI bindings for StarkWare's crypto-cpp library Note that currently target x86_64-pc-windows-msvc is not supported. If you're

Jonathan LEI 11 Aug 22, 2022
Cross-chain hub for Crypto Asset on Polkadot

ChainX ChainX is a community-driven project built on the next-generation blockchain framework substrate, the largest Layer-2 network of Bitcoin using

ChainX 261 Dec 28, 2022
Highly modular & configurable hash & crypto library

Octavo Highly modular & configurable hash & crypto library written in pure Rust. Installation [dependencies] octavo = { git = "https://github.com/libO

Octavo Developers 139 Dec 29, 2022
A modern, portable, easy to use crypto library.

Sodium is a new, easy-to-use software library for encryption, decryption, signatures, password hashing and more. It is a portable, cross-compilable, i

Frank Denis 10.7k Jan 3, 2023
A young, simple and naive file crypto lib based on AES.

naive-file-crypto A young, simple and naive file crypto lib based on AES. The MAC implementation is not standard GCM, so it may be vulnerable. All cpu

DF_XYZ 1 Jan 16, 2022
Crypto in, power out

Cipo Crypto in, power out Cipo makes it easy to let users pay for electricity for their camper-van, electric cars, boat, caravan and other high load c

Jonny Heggheim 9 Dec 9, 2022
The parser library to parse messages from crypto-crawler.

crypto-msg-parser The parser library to parse messages from crypto-crawler. Architecture crypto-msg-parser is the parser library to parse messages fro

null 5 Jan 2, 2023
A boringssl-based rustls crypto provider

boring-rustls-provider This is supposed to be the start to a boringssl-based rustls crypto provider. Status This is just a dump of me figuring out how

Jan 5 Nov 28, 2023
A blazing fast, type-safe template engine for Rust.

markup.rs A blazing fast, type-safe template engine for Rust. markup.rs is a template engine for Rust powered by procedural macros which parses the te

Utkarsh Kukreti 209 Dec 24, 2022
A blazingly fast and memory safe password cracker with user interface.

HashVat A blazingly fast and memory safe password cracker with user interface. HashVat runs with user interface and is capable of cracking the 1.000.0

JBLDSKY 2 Dec 6, 2022
A type-safe Rust interface to the Nix CLI

runix A typesafe interface to the nix CLI. by flox Installation Install with cargo add (Rust >= 1.64) cargo add runix Alternatively, manually add runi

flox 43 Mar 6, 2023
A safe implementation of the secure remote password authentication and key-exchange protocol (SRP), SRP6a and legacy are as features available.

Secure Remote Password (SRP 6 / 6a) A safe implementation of the secure remote password authentication and key-exchange protocol (SRP version 6a). Ver

Sven Assmann 10 Nov 3, 2022
Tool for computing vanity Gnosis Safe addresses

0xdeadbeef Tool used for computing vanity Gnosis Safe addresses. This tool is currently hard-coded to only support the v1.3.0 Safe deployment: GnosisS

Nicholas Rodrigues Lordello 44 Dec 22, 2022
Gnosis Safe Tx Service API client & associated tooling

Safe Transaction Service API Client Using the SDK Instantiate an API client use safe_sdk::SafeClient; /// From a chain id, by looking up hardcoded en

Nomad 3 Dec 15, 2022
A type-safe, K-sortable, globally unique identifier

type-safe-id A type-safe, K-sortable, globally unique identifier. Typed implementation of https://github.com/jetpack-io/typeid in Rust. Examples Stati

Conrad Ludgate 13 Jul 10, 2023
Hash trait that is object-safe

Hash trait that is object-safe This crate provides a DynHash trait that can be used in trait objects. Types that implement the standard library's std:

David Tolnay 19 Nov 12, 2023
A small block explorer for geth PoAs written in rust

Tesseracts A minimalistic block explorer initially created to learn rust. This block explorer has been created as a rust self-learning project to give

adria0.eth 15 Jun 25, 2022
A small, 8-byte, ID type for use in rust applications that need a pretty unique identifier

TinyId A small, 8-byte, ID type for use in rust applications that need a pretty unique identifier that is not required to be cryptographically secure

Tony B 1 May 4, 2022