example/local-using-builder panics

[mrceperka]

Description

Steps to reproduce

1. Clone this repo
2. cp examples/local-using-builders.rs src/main.rs
3. cargo run

This should verify the token, but it fails with this error mesage.

Error

```text Finished dev [unoptimized + debuginfo] target(s) in 0.08s Running `target/debug/paseto` "v2.local.DTpWpnjY9TKfl_pe4i86IEyY4a01zVBjjyFH9abs-xhIBSRKjNXK_W621g9Au0Q08iGo_q5n9qv7aSGaA8hEKau_GqrZXlX4jBSZdPBGBc_OYSdeQbCchl5PWlo8e9LCiq7AUR65P3T-x3evnJhiJ3caPw7RLPwGPeUZMIIPuRzI5qonZ0_aJn0Yr4H6pCgauVl1yvCOrM9H19kW6OEH4MyOv9ULBJFKOhAXO34C73F6x575XSOPrOQeBMKlpdDZMfB9LqhxHMpaWKIy29olMyiO8a7clTJ9MWWfADLNZ-2nUVLl0ba4_d0N.a2V5LWlkOmdhbmRhbGYw" thread 'main' panicked at 'Failed to validate token!: Error(JsonError, State { next_error: None, backtrace: InternalBacktrace { backtrace: Some(stack backtrace: 0: error_chain::backtrace::imp::InternalBacktrace::new::h648878bdcff53f4e (0x55687391c0f2) at /home/mrceperka/.cargo/registry/src/github.com-1ecc6299db9ec823/error-chain-0.12.0/src/backtrace.rs:56 1: ::default::hf3814f6738a31558 (0x55687391a782) at /home/mrceperka/.cargo/registry/src/github.com-1ecc6299db9ec823/error-chain-0.12.0/src/lib.rs:666 2: paseto::errors::Error::from_kind::h6f1c9a1a05350852 (0x55687386910a) at /tmp/paseto/<::error_chain::error_chain::impl_error_chain_processed macros>:53 3: >::from::hb93eaa51c87f0c64 (0x556873869308) at src/errors.rs:15 4: >::into::h5ee9fb1abfa3f2b5 (0x55687387ae18) at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libcore/convert.rs:455 5: paseto::tokens::validate_potential_json_blob::h769b5ab34b7d3ca5 (0x556873859f90) at src/tokens/mod.rs:41 6: paseto::tokens::validate_local_token::hb51002e1b8109a1b (0x55687385b351) at src/tokens/mod.rs:119 7: paseto::main::h7be5630e7543d4e7 (0x55687384f415) at src/main.rs:27 8: std::rt::lang_start::{{closure}}::h192db9481c263cb7 (0x55687384ebef) at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libstd/rt.rs:74 9: std::rt::lang_start_internal::{{closure}}::h6eb089a6fc5de4c9 (0x556873985872) at src/libstd/rt.rs:59 std::panicking::try::do_call::haa8c3812c8ee3dac at src/libstd/panicking.rs:310 10: __rust_maybe_catch_panic (0x556873993769) at src/libpanic_unwind/lib.rs:102 11: std::panicking::try::hb30f4e80d31f57ea (0x556873986243) at src/libstd/panicking.rs:289 std::panic::catch_unwind::h2d2435e0a6c5ec4e at src/libstd/panic.rs:398 std::rt::lang_start_internal::h209b9d62a82d0a63 at src/libstd/rt.rs:58 12: std::rt::lang_start::h1e7ba43d3fbb373f (0x55687384ebc8) at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libstd/rt.rs:74 13: main (0x55687384f809) 14: __libc_start_main (0x7fb6e4117b96) 15: _start (0x55687384dd69) 16: (0x0)) } })', src/libcore/result.rs:1009:5 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:71 2: std::panicking::default_hook::{{closure}} at src/libstd/sys_common/backtrace.rs:59 at src/libstd/panicking.rs:211 3: std::panicking::default_hook at src/libstd/panicking.rs:227 4: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:476 5: std::panicking::continue_panic_fmt at src/libstd/panicking.rs:390 6: rust_begin_unwind at src/libstd/panicking.rs:325 7: core::panicking::panic_fmt at src/libcore/panicking.rs:77 8: core::result::unwrap_failed at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libcore/macros.rs:26 9: >::expect at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libcore/result.rs:835 10: paseto::main at src/main.rs:27 11: std::rt::lang_start::{{closure}} at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libstd/rt.rs:74 12: std::panicking::try::do_call at src/libstd/rt.rs:59 at src/libstd/panicking.rs:310 13: __rust_maybe_catch_panic at src/libpanic_unwind/lib.rs:102 14: std::rt::lang_start_internal at src/libstd/panicking.rs:289 at src/libstd/panic.rs:398 at src/libstd/rt.rs:58 15: std::rt::lang_start at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libstd/rt.rs:74 16: main 17: __libc_start_main 18: _start ```

Additional Information

• Rust Version: rustc 1.32.0-nightly (6bfb46e4a 2018-11-26)
• Platform: Ubuntu 18.04.1 LTS

[Mythra]

Thanks for the bug report! This looks to be an issue with newer versions of rust. As on 1.31.1 (current stable), running:

$ SODIUM_BUILD_STATIC=yes cargo run --example local-using-builders
   Compiling serde_json v1.0.24                                                               
   Compiling chrono v0.4.5                                                                    
   Compiling libsodium-ffi v0.1.12                                                            
   Compiling paseto v1.0.1 (/home/CORP.INSTRUCTURE.COM/ecoan/paseto)                          
    Finished dev [unoptimized + debuginfo] target(s) in 26.41s                                
     Running `target/debug/examples/local-using-builders`
"v2.local.EyRRtKS95lUw9XgnC3gE4vd-Ko4Qqi7jGcnaw--LjE0Rzu393Gog7bIsgkOk3eNx-uo3ULIg5MjjhoI3wK7NupW8gQHrGVTX5Mlpw27ZXQQstuSJOvX5Fqur4Np5JC1mnNXsk2WSyT6qGQiIPQDsb5LOis57n5rDC_GDCrnMYkot662QKkfzPC39Ec30dWNIst-nPPF4ppj3LyjNp6bsI_xN7FFQOKDIeP30QBEK94Lw5cmHdxbf8gBpGOJ93H9-kxITBKWZ1TO-hs5_YehDxXDDEqCzBZCtCOnDWMIWyhpigoTwrv_vZooM.a2V5LWlkOmdhbmRhbGYw"
Object({"aud": String("wizards"), "exp": String("2020-07-08T09:10:11Z"), "go-to": String("mordor"), "iat": String("2019-01-05T19:38:57.657505361Z"), "iss": String("instructure"), "jti": String("gandalf0"), "nbf": String("2019-01-05T19:38:57.657558636Z"), "sub": String("gandalf")})

Works. However after running rustup update, and then:

SODIUM_BUILD_STATIC=yes rustup run nightly cargo run --example local-using-builders

I get the same error as you on the latest nightly (1.33). I wonder if this is because of our use of error-chain instead of using the newer failure APIs. (or something even more nebulous). Needless to say I'll look into it, so we don't start failing to compile on stable.

[mrceperka]

Thanks for the quick reply. I would like to add, that I was also having weird Utf8Error.

Here's the code.

use paseto;
use rocket::Outcome;
use rocket::Request;
use rocket::request;
use rocket::request::FromRequest;
use serde_json::Value;
use crate::modules::auth::enums::token::AuthTokenError;

#[derive(Debug)]
pub struct AuthToken(Result<Value, AuthTokenError>);

impl<'a, 'r> FromRequest<'a, 'r> for AuthToken {
    type Error = ();

    fn from_request(request: &'a Request<'r>) -> request::Outcome<AuthToken, ()> {
        let keys: Vec<_> = request.headers().get("x-api-key").collect();
        if keys.len() != 1 {
            return Outcome::Success(AuthToken(Err(AuthTokenError::MissingHeader)));
        }

        let token = keys[0];
        println!("{:?}", token);

        match paseto::tokens::validate_local_token(
            token.to_string(),
            None,
            Vec::from("YELLOW SUBMARINE, BLACK WIZARDRY".as_bytes()),
        ) {
            Ok(t) => match t {
                Value::String(_) => Outcome::Success(AuthToken(Ok(t))),
                _ => Outcome::Success(AuthToken(Err(AuthTokenError::UnexpectedContent)))
            },
            x => {
                println!("{:?}", x);
                Outcome::Success(AuthToken(Err(AuthTokenError::InvalidSignature)))
            }
        }
    }
}

Earlier I was getting Utf8Error, now I am getting JsonError

"v2.local.WJFZC1UctPksan2FETxdX8v8qbxPwVs7s25iMur6mRuxQDmEyS8mjfW-EnGcmdZbyPlWGNtTPNMKPze5VTk3EONyKfBV8qHZAwj8Ue47ExNcER4O8oVqzeiY28iWCsWrE6IVaVWjOxOVu8n9tKRyoYykyoQ35GktGqdd7y5BnQ7PJeE4qqZ9HPhFNjaPcWxmz1gDEqkfJem9K-WpHdvFUsvo3qgKQSfZDkFAw-1XSwixtLY0A0_S9iToFRtNwYDA3YHK94mBWNJx2vd8K9udEuNnNhkcAQv9uOfw6J6QxuDTJ-sfbwVrLlFf"

Err(Error(JsonError, State { next_error: None, backtrace: InternalBacktrace { backtrace: None } }))

[Mythra]

Hmmm not sure why you were getting a Utf8 error, but something is definitely going on. Upgrading dependencies, and porting over to rust-2018 still leaves with this error. After doing some more digging it seems on nightly we end up writing an invalid payload.

Specifically I got a payload that looks like:

To parse: wizards","jti":"gandalf0","go-to":"mordor","exp":"2020-07-08T09:10:11Z","iss":"instructure","iat":"2019-01-06T17:42:12.183088168Z","nbf":"2019-01-06T17:42:12.183134561Z","sub":"gandalf"}

Which is part of the json, just not all of it (thus leading to the json parse error). This should all be handled through serde, so perhaps serde is having problems in nightly? That seems suspect though, anyway I'll keep digging just wanted to update.

[Mythra]

Turns out this bug was caused by our custom libsodium_ffi code, on newer versions of rust. Which we originally had in because sodiumoxide didn't have the functions we needed. Luckily sodiumoxide does contain the functions we need!

So I've pushed a commit that fixes it locally for me to master. I'll be testing with some of our internal applications before cutting a release, but would you mind testing it out yourself? See if you still run into the issue?

[mrceperka]

Will do that. But my use case is rather simple.

[mrceperka]

Any idea, how to fix this? Do I still have to export vars?

error: failed to run custom build command for `libsodium-sys v0.2.0`
process didn't exit successfully: `/var/docker/target/debug/build/libsodium-sys-9aa2fd22823c122b/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=SODIUM_LIB_DIR
cargo:rerun-if-env-changed=SODIUM_SHARED
cargo:rerun-if-env-changed=SODIUM_USE_PKG_CONFIG
cargo:rerun-if-env-changed=SODIUM_DISABLE_PIE

--- stderr
thread 'main' panicked at 'SODIUM_STATIC is deprecated. Use SODIUM_SHARED instead.', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/libsodium-sys-0.2.0/build.rs:50:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Got it!

unset SODIUM_STATIC
unset SODIUM_BUILD_STATIC

[mrceperka]

Hm, you have moved paseto::errors::Error... So now, there is not an error enum, that contains all errors? Maybe I just don't know how to use it..

[Mythra]

Doh, didn't realize you couldn't set those env vars at all anymore. I'll be sure to include that in the changelog.

As for the internal error type, yes it has been moved to: failure::Error: https://github.com/rust-lang-nursery/failure , since error-chain no longer works in rust-2018, and recommends switching to failure (which my understanding will eventually move into the std::error::Error type)

[mrceperka]

Well, I've got my app running. Thanks for help with errors.

And verification seems to work! Great :1st_place_medal:

[Mythra]

Good to hear it! I still have some testing to do, but we should cut an official version by end of day Monday.

[mrceperka]

Thanks again for fix and help :) You are awesome maintainer :tada: