Skip to content
This repository has been archived by the owner on Apr 30, 2024. It is now read-only.

example/local-using-builder panics #3

Closed
mrceperka opened this issue Jan 5, 2019 · 11 comments
Closed

example/local-using-builder panics #3

mrceperka opened this issue Jan 5, 2019 · 11 comments
Assignees

Comments

@mrceperka
Copy link

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
    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: <error_chain::State as core::default::Default>::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: <paseto::errors::Error as core::convert::From<paseto::errors::ErrorKind>>::from::hb93eaa51c87f0c64 (0x556873869308)
             at src/errors.rs:15
   4: <T as core::convert::Into<U>>::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: <unknown> (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: <core::result::Result<T, E>>::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
Copy link
Collaborator

Mythra commented Jan 5, 2019

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.

@Mythra Mythra self-assigned this Jan 5, 2019
@mrceperka
Copy link
Author

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
Copy link
Collaborator

Mythra commented Jan 6, 2019

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 Mythra closed this as completed in e2b06aa Jan 6, 2019
@Mythra
Copy link
Collaborator

Mythra commented Jan 6, 2019

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
Copy link
Author

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

@mrceperka
Copy link
Author

mrceperka commented Jan 6, 2019

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
Copy link
Author

mrceperka commented Jan 6, 2019

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
Copy link
Collaborator

Mythra commented Jan 6, 2019

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
Copy link
Author

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

And verification seems to work! Great 🥇

@Mythra
Copy link
Collaborator

Mythra commented Jan 6, 2019

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

@mrceperka
Copy link
Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants