Rust-Rust openssl: rust-openssl — OpenSSL bindings

rust-openssl

CircleCI crates.io

OpenSSL bindings for the Rust programming language.

Documentation.

Release Support

The current supported release of openssl is 0.10 and openssl-sys is 0.9.

New major versions will be published at most once per year. After a new release, the previous major version will be partially supported with bug fixes for 3 months, after which support will be dropped entirely.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed under the terms of both the Apache License, Version 2.0 and the MIT license without any additional terms or conditions.

Comments

  • Add X25519 and X448 key types. Add raw key import and export functions.
    Add X25519 and X448 key types. Add raw key import and export functions.

    May 21, 2020

                                                                                                                                                                                                           
    Reply
  • Possibly change Signer/Crypter to be lower level bindings
    Possibly change Signer/Crypter to be lower level bindings

    May 25, 2020

    These types currently try to expose a decently high level interface, but there are enough weird edge cases (like CCM IV configuration #1237) that I wonder if it would be better to try to have those types be direct wrappers over the underlying OpenSSL APIs. This would depend on OpenSSL having appropriate error handling when calling methods in the wrong contexts.

    Reply
  • Can't reproduce signature verification from CLI
    Can't reproduce signature verification from CLI

    Jun 2, 2020

    I have the hash of a file that I'm trying to verify against a signature. I can verify this successfully with the openssl CLI (shown below). I wrote what I think is the equivalent Rust program to do the exact same verification, but am failing to get it to verify.

    The 3 files used (hash, signature, pubkey) are attached if anyone wants to reproduce. data.zip

    I apologize if I'm just making a simple mistake, but as far as I can tell it looks like an issue with this library currently.

    using the openssl CLI

    $ openssl version
    OpenSSL 1.1.1f  31 Mar 2020
    $ openssl pkeyutl -in hash.bin -inkey publickey.pem -pubin -verify -sigfile signature.bin
    Signature Verified Successfully
    
    

    Rust program

    println!("{}", openssl::version::version());
    
    let mut public_key_bytes = vec![];
    std::fs::File::open("publickey.pem").unwrap().read_to_end(&mut public_key_bytes).unwrap();
    let public_key = openssl::pkey::PKey::public_key_from_pem(&public_key_bytes).unwrap();
    
    let mut hash_result = vec![];
    std::fs::File::open("hash.bin").unwrap().read_to_end(&mut hash_result).unwrap();
    
    let mut signature= vec![];
    std::fs::File::open("signature.bin").unwrap().read_to_end(&mut signature).unwrap();
    
    let mut verifier = openssl::sign::Verifier::new_without_digest(&public_key).unwrap();
    let verify_result = verifier.verify_oneshot(&signature, &hash_result);
    println!("Verify result: {:?}", verify_result);
    
    [dependencies]
    openssl = "0.10.29"
    

    Output of Rust program

    OpenSSL 1.1.1f  31 Mar 2020
    Verify result: Ok(false)
    
    Reply
  • Segfault when using X509Store and not waiting for threads to finish
    Segfault when using X509Store and not waiting for threads to finish

    Jun 11, 2020

    In rust should be safe to not wait for threads to finish.

    use openssl::x509::store::X509StoreBuilder;
    
    fn main()
    {
      for _ in 0..100
      {
        std::thread::spawn(move ||
        {
          X509StoreBuilder::new().unwrap().set_default_paths().unwrap();
        });
      }
    }
    
    * thread #2, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
      * frame #0: 0x00007fff6f488dde libsystem_pthread.dylib`pthread_rwlock_unlock + 1
        frame #1: 0x00000001003120f7 libcrypto.1.1.dylib`CRYPTO_THREAD_unlock + 9
        frame #2: 0x00000001002c5190 libcrypto.1.1.dylib`OPENSSL_init_crypto + 640
        frame #3: 0x000000010019341c libssl.1.1.dylib`OPENSSL_init_ssl + 104
        frame #4: 0x000000010000d506 openssl_sys::init::_$u7b$$u7b$closure$u7d$$u7d$::hf3dca76fa6caed25((null)=closure-0 @ 0x000070000fc4cb08) at lib.rs:105:9
        frame #5: 0x000000010000d86b std::sync::once::Once::call_once::_$u7b$$u7b$closure$u7d$$u7d$::h23b9973b98f37cd1((null)=false) at once.rs:264:41
        frame #6: 0x0000000100032114 std::sync::once::Once::call_inner::h638f254fcca36049 at once.rs:416:21 [opt]
        frame #7: 0x000000010000d7fc std::sync::once::Once::call_once::h4894d7500c9c8446(self=0x0000000100039580, f=closure-0 @ 0x000070000fc4cbf8) at once.rs:264:9
        frame #8: 0x000000010000d4e3 openssl_sys::init::h2f222efa8d39d786 at lib.rs:104:5
        frame #9: 0x0000000100009eb8 openssl::x509::store::X509StoreBuilder::new::hf8fa69cd0c36c6b0 at store.rs:68:13
        frame #10: 0x0000000100003011 main::_$u7b$$u7b$closure$u7d$$u7d$::hf9f263d01f3172c4((null)=closure-0 @ 0x000070000fc4ccc8) at main.rs:9:7
    

    Following code is attempting to initialise openssl before running threads. Now it sometimes panics on unwrap in these threads what is how it should be. But sometimes it causes segfault.

    use openssl::x509::store::X509StoreBuilder;
    
    fn main()
    {
      X509StoreBuilder::new().unwrap().set_default_paths().unwrap();
      for _ in 0..100
      {
        std::thread::spawn(move ||
        {
          X509StoreBuilder::new().unwrap().set_default_paths().unwrap();
        });
      }
    }
    
    * thread #32, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
      * frame #0: 0x00007fff6f488dde libsystem_pthread.dylib`pthread_rwlock_unlock + 1
        frame #1: 0x00000001003120f7 libcrypto.1.1.dylib`CRYPTO_THREAD_unlock + 9
        frame #2: 0x00000001002c2827 libcrypto.1.1.dylib`CRYPTO_new_ex_data + 179
        frame #3: 0x000000010021ab7a libcrypto.1.1.dylib`BIO_new + 80
        frame #4: 0x00000001002d8a5c libcrypto.1.1.dylib`PEM_read_bio_ex + 231
        frame #5: 0x00000001002d6dbb libcrypto.1.1.dylib`PEM_X509_INFO_read_bio + 140
        frame #6: 0x000000010031ca0e libcrypto.1.1.dylib`X509_load_cert_crl_file + 78
        frame #7: 0x000000010031cb69 libcrypto.1.1.dylib`by_file_ctrl + 65
        frame #8: 0x000000010031f407 libcrypto.1.1.dylib`X509_STORE_set_default_paths + 57
        frame #9: 0x0000000100009eec openssl::x509::store::X509StoreBuilderRef::set_default_paths::hdb561cfe1601dd70(self=0x0000000101080ca0) at store.rs:95:22
        frame #10: 0x0000000100002f91 main::_$u7b$$u7b$closure$u7d$$u7d$::hf9f263d01f3172c4((null)=closure-0 @ 0x00007000136a2cc8) at main.rs:10:7
    

    This is probably because openssl already de-initialised and freed its mutexes.

    Reply
  • Time-stamping api support
    Time-stamping api support

    Jun 12, 2020

    There are functions, structures and constants defined in ts.h mainly prefixed with TS_. They are useful for creating time-stamp requests (and can create time-stamp itself) for time-stamp authorities RFC 3161. Time-stamp can be included for example in PKCS#7 signature.

    Reply
  • Trouble compiling on MSYS2
    Trouble compiling on MSYS2

    Jun 16, 2020

    I'm trying to build libtor for Windows. Seemed like MSYS2 is the best option (open to alternatives!). Here's my example project which I'm trying to build below.

    I installed the MSYS2 "openssl", "openssl-devel" & "pkg-config" packages.

    $ pkg-config --cflags openssl
    -IC:/msys64/mingw64/include
    
    $ pkg-config --libs openssl
    -LC:/msys64/mingw64/lib -lssl -lcrypto
    

    Based ^^ and the docs, I would assume that the following would work:

    $ OPENSSL_DIR=/mingw64 cargo run
    ...
    thread 'main' panicked at 'OpenSSL libdir at `C:\msys64\home\justin\runlibtor\target\debug\build\openssl-sys-05e3c077a4469148\out\openssl-build\install\lib` does not contain the required files to either statically or dynamically link OpenSSL', C:\Users\justin\.cargo\registry\src\github.com-1ecc6299db9ec823\openssl-sys-0.9.54\build/main.rs:316:13
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    
    Reply
  • Doesn't support OpenSSL 1.1.0
    Doesn't support OpenSSL 1.1.0

    Sep 9, 2016

    If I'm correct, OpenSSL 1.1.0 doesn't include some methods relied upon by this crate, e.g. CRYPTO_set_locking_callback.

    Reply
  • Support builds of OpenSSL from vendored source (take 2)
    Support builds of OpenSSL from vendored source (take 2)

    Jul 27, 2018

    This is a revival of #684 to see if I can help push it across the finish line!

    Closes #580

    Reply
  • Adds world to the link path; bad neighbor
    Adds world to the link path; bad neighbor

    Sep 3, 2016

    As openssl-sys adds the world to the link path, it prevents linking against any libs that have a different version in /usr/lib

    cargo:rustc-link-search=native=/usr/lib/x86_64-linux-gnu
    cargo:rustc-link-lib=ssl
    cargo:rustc-link-lib=crypto
    

    It appears that link path order is randomized by cargo, so this will cause nicely randomized link failures if other native crates are in use (or silently cause the wrong/unpatched version of a lib to be linked instead).

    This can be fixed by producing the following output instead:

    cargo:rustc-link-search=native=/usr/lib/x86_64-linux-gnu/libssl*
    cargo:rustc-link-search=native=/usr/lib/x86_64-linux-gnu/libcrypto*
    cargo:rustc-link-lib=ssl
    cargo:rustc-link-lib=crypto
    
    Reply
  • [openssl][0.9.24] Fail to build on hosts with openssl 1.1.1
    [openssl][0.9.24] Fail to build on hosts with openssl 1.1.1

    Sep 15, 2018

    Today I updated my host development machine and found that it was not building my source code anymore.

    Got the following failure:

    error: failed to run custom build command for `openssl v0.9.24`
    process didn't exit successfully: `.../target/debug/build/openssl-4dcd4d0c1d4575a6/build-script-build` (exit code: 101)
    --- stderr
    thread 'main' panicked at 'Unable to detect OpenSSL version', .../.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14
    note: Run with `RUST_BACKTRACE=1` for a backtrace.
    

    It needs to be upgraded to openssl-sys last releases. This is important as multiple vendors will start upgrading OpenSSL and more people will face it. For now, I downgraded my host to openssl 1.1.0

    Reply
  • Faild build On OSX 10.11(Elp)
    Faild build On OSX 10.11(Elp)

    Aug 19, 2015

    failed to run custom build command for openssl-sys v0.6.4 Process didn't exit successfully: /Users/misko/developer/rust_projects/aws-simple-sdk.rs/target/debug/build/openssl-sys-149f6ef08ad7404d/build-script-build (exit code: 101) --- stdout cargo:rustc-link-search=native=/usr/lib cargo:rustc-link-lib=ssl cargo:rustc-link-lib=crypto cargo:rustc-link-lib=z TARGET = Some("x86_64-apple-darwin") TARGET = Some("x86_64-apple-darwin") CARGO_MANIFEST_DIR = Some("/Users/misko/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.6.4") OUT_DIR = Some("/Users/misko/developer/rust_projects/aws-simple-sdk.rs/target/debug/build/openssl-sys-149f6ef08ad7404d/out") OPT_LEVEL = Some("0") PROFILE = Some("debug") debug 0 TARGET = Some("x86_64-apple-darwin") HOST = Some("x86_64-apple-darwin") CC_x86_64-apple-darwin = None CC_x86_64_apple_darwin = None HOST_CC = None CC = None TARGET = Some("x86_64-apple-darwin") HOST = Some("x86_64-apple-darwin") CFLAGS_x86_64-apple-darwin = None CFLAGS_x86_64_apple_darwin = None HOST_CFLAGS = None CFLAGS = None running: "cc" "-O0" "-c" "-ffunction-sections" "-fdata-sections" "-g" "-m64" "-fPIC" "-o" "/Users/misko/developer/rust_projects/aws-simple-sdk.rs/target/debug/build/openssl-sys-149f6ef08ad7404d/out/src/openssl_shim.o" "/Users/misko/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.6.4/src/openssl_shim.c"

    command did not execute successfully, got: exit code: 1

    --- stderr /Users/misko/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.6.4/src/openssl_shim.c:1:10: fatal error: 'openssl/hmac.h' file not found

    include <openssl/hmac.h>

         ^
    

    1 error generated. thread '

    ' panicked at 'explicit panic', /Users/misko/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.13/src/lib.rs:510

    Reply
  • Relicense under dual MIT/Apache-2.0
    Relicense under dual MIT/Apache-2.0

    Jan 10, 2016

    This issue was automatically generated. Feel free to close without ceremony if you do not agree with re-licensing or if it is not possible for other reasons. Respond to @cmr with any questions or concerns, or pop over to #rust-offtopic on IRC to discuss.

    You're receiving this because someone (perhaps the project maintainer) published a crates.io package with the license as "MIT" xor "Apache-2.0" and the repository field pointing here.

    TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that license is good for interoperation. The MIT license as an add-on can be nice for GPLv2 projects to use your code.

    Why?

    The MIT license requires reproducing countless copies of the same copyright header with different names in the copyright field, for every MIT library in use. The Apache license does not have this drawback. However, this is not the primary motivation for me creating these issues. The Apache license also has protections from patent trolls and an explicit contribution licensing clause. However, the Apache license is incompatible with GPLv2. This is why Rust is dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for GPLv2 compat), and doing so would be wise for this project. This also makes this crate suitable for inclusion and unrestricted sharing in the Rust standard distribution and other projects using dual MIT/Apache, such as my personal ulterior motive, the Robigalia project.

    Some ask, "Does this really apply to binary redistributions? Does MIT really require reproducing the whole thing?" I'm not a lawyer, and I can't give legal advice, but some Google Android apps include open source attributions using this interpretation. Others also agree with it. But, again, the copyright notice redistribution is not the primary motivation for the dual-licensing. It's stronger protections to licensees and better interoperation with the wider Rust ecosystem.

    How?

    To do this, get explicit approval from each contributor of copyrightable work (as not all contributions qualify for copyright, due to not being a "creative work", e.g. a typo fix) and then add the following to your README:

    ## License
    
    Licensed under either of
    
     * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
     * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
    
    at your option.
    
    ### Contribution
    
    Unless you explicitly state otherwise, any contribution intentionally submitted
    for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
    additional terms or conditions.
    

    and in your license headers, if you have them, use the following boilerplate (based on that used in Rust):

    // Copyright 2016 rust-openssl Developers
    //
    // Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
    // http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
    // http://opensource.org/licenses/MIT>, at your option. This file may not be
    // copied, modified, or distributed except according to those terms.
    

    It's commonly asked whether license headers are required. I'm not comfortable making an official recommendation either way, but the Apache license recommends it in their appendix on how to use the license.

    Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these from the Rust repo for a plain-text version.

    And don't forget to update the license metadata in your Cargo.toml to:

    license = "MIT OR Apache-2.0"
    

    I'll be going through projects which agree to be relicensed and have approval by the necessary contributors and doing this changes, so feel free to leave the heavy lifting to me!

    Contributor checkoff

    To agree to relicensing, comment with :

    I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.
    

    Or, if you're a contributor, you can check the box in this repo next to your name. My scripts will pick this exact phrase up and check your checkbox, but I'll come through and manually review this issue later as well.

    • [ ] @sfackler
    • [ ] @manuels
    • [x] @vhbit
    • [x] @kballard
    • [x] @erickt
    • [x] @jmesmon
    • [x] @cjcole
    • [x] @alexcrichton
    • [ ] @elly
    • [ ] @gkoz
    • [x] @DiamondLovesYou
    • [x] @mlalic
    • [x] @ebfe
    • [x] @randombit
    • [x] @Geal
    • [x] @jedisct1
    • [x] @jroesch
    • [x] @mvdnes
    • [x] @andrew-d
    • [x] @Manishearth
    • [x] @josephglanville
    • [x] @zzmp
    • [x] @Cyberunner23
    • [x] @aatxe
    • [ ] @Noxivs
    • [x] @semmaz
    • [ ] @pyrho
    • [x] @cybergeek94
    • [x] @alex
    • [ ] @brson
    • [ ] @brycefisher
    • [x] @chris-morgan
    • [x] @Ryman
    • [x] @operutka
    • [x] @reaperhulk
    • [x] @retep998
    • [ ] @quentinbaradat
    • [ ] @xorpse
    • [x] @kinghajj
    • [x] @uasi
    • [ ] @wg
    • [ ] @bheart
    • [x] @bozaro
    • [x] @bombless
    • [ ] @akiss77
    • [x] @andor44
    • [ ] @ajroetker
    • [x] @brunoqc
    • [x] @CarlColglazier
    • [x] @coyotebush
    • [x] @dkhenry
    • [x] @davbo
    • [x] @ebarnard
    • [x] @cheme
    • [x] @Kroisse
    • [x] @fhartwig
    • [x] @Florob
    • [x] @glennw
    • [x] @isra17
    • [x] @jameshurst
    • [x] @jamwt
    • [x] @yjerem
    • [x] @jimmycuadra
    • [x] @jtdowney
    • [x] @reem
    • [x] @larsbergstrom
    • [x] @ltratt
    • [x] @mbrubeck
    • [x] @zr40
    • [x] @maximih
    • [ ] @miloshadzic
    • [x] @Ms2ger
    • [x] @nixpulvis
    • [x] @nstoddard
    • [x] @overminder
    • [x] @globin
    • [x] @seanmonstar
    • [x] @Byron
    • [x] @s-panferov
    • [ ] @boggle
    • [x] @thommay
    • [x] @Ummon
    • [x] @gentoo90
    • [ ] @iseki-masaya
    • [x] @panicbit
    • [ ] @radare
    Reply