Migrate from v0.10 to v0.11

[hansonchar]

I just realized this crate has a new release v0.11 but when I tried to compile my existing code based on v0.10.4, it failed with

error[E0432]: unresolved imports `scratchstack_aws_signature::sigv4_verify`, `scratchstack_aws_signature::Request`, `scratchstack_aws_signature::SigningKey`, `scratchstack_aws_signature::SigningKeyKind`
  --> src/xks_proxy/sigv4.rs:14:5
   |
14 |     sigv4_verify, Request as Sigv4Request, SigningKey, SigningKeyKind::KSecret,
   |     ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^  ^^^^^^^^^^^^^^ could not find `SigningKeyKind` in `scratchstack_aws_signature`
   |     |             |                        |
   |     |             |                        no `SigningKey` in the root
   |     |             |                        help: a similar name exists in the module: `KSigningKey`
   |     |             no `Request` in the root
   |     no `sigv4_verify` in the root

It seems the previous function sigv4_verify is now replaced by sigv4_validate_request which has an additional parameter of required_headers of type &SignedHeaderRequirements). Any suggestion on how to migrate to the latest API? This is what the existing code like:

...
use scratchstack_aws_signature::{
    sigv4_verify, Request as Sigv4Request, SigningKey, SigningKeyKind::KSecret,
};
...
    let signing_key = SigningKey {
        kind: KSecret,
        key: xks.sigv4_secret_access_key.as_str().as_bytes().to_vec(),
    };
    let allowed_mismatch = Some(Duration::minutes(5));
    if let Err(signature_error) = sigv4_verify(
        &sigv4_req,
        &signing_key,
        allowed_mismatch,
        SETTINGS.server.region.as_str(),
        SETTINGS.server.service.as_str(),
    ) {
        tracing::warn!("SigV4 failure: {signature_error}");
        return Err(AuthenticationFailedException.as_axum_error(signature_error.to_string()));
    }

Also, I don't seem to find a 0.11.x branch or tag. Is the main branch going to be used for 0.11.x?

[dacut]

Hi Hanson,

Alas, I had to release 0.11 prematurely due to a Cargo bug that prohibited some unrelated crates from building properly. It's probably not quite ready for consumption, and the interfaces are not settled/stable; I do want to make 0.10 compatibility better.

Do you have time to chat next week? I'm curious how you're using this, as it looks like I might be starting to duplicate some work over on scratchstack-http-framework, e.g.: sigv4.rs. Looks like you're using Axum; would love to hear how that's working for what you're doing.

In particular, Warp (whose author is at AWS now) looks nice, but doesn't like middleware snooping on the HTTP body, which is obviously required for SigV4.

Thanks!
Dave

[hansonchar]

Thanks Dave for the info. Good to know the current status of v0.11, etc.

Many rust folks especially developers from the tokio team has joined AWS. axum is one of the recommended crates for use in this eco system.

Do you have time to chat next week?

I see many meetings on my calendar next week, but we can/should try.

[dacut]

No hurry, we can push it out to fit your schedule. But I am quite interested in hearing how this would better fit your use case, especially as I design/redesign scratchstack-http-framework to work better around frameworks that people are using (especially tokio/async based). I have a general idea, but it's kind of an echo chamber over here in my head on Bainbridge. 😆

[dacut]

Bah, just realizing I should have tagged 0.11.0 with something like 0.11.0-preview0. I forget that you can do that with semver.

[dacut]

Ok, versioning snafu fixed:

• 0.11.0 has been yanked.
• Republished as 0.11.1-preview.0 (and tagged, and pushed with tags this time).

[hansonchar]

Awesome!

[dacut]

Hey Hanson,

In the latest preview release (0.11.1-preview.2), I added an optimization to allow the signing key provider to optionally return a policy if it's readily available (would save a round trip asking for it later on): https://github.com/dacut/scratchstack-aws-signature/blob/main/src/signing_key.rs#L317-L320

However, I'm beginning to think this was a mistake as it starts to tie the authn implementation (here) with a specific authz implementation (namely scratchstack-aspen), and might also be a premature optimization. Curious to know what you think.

Feel free to hit me up via email (dacut at kanga dot org) if it's more convenient.

Thanks,
Dave