Bump AWS SDK version#868
Conversation
See awslabs/aws-sdk-rust#1257. Also migrates from aws-smithy-experimental to aws-smithy-https-client. Signed-off-by: Sam Berning <bernings@amazon.com>
df532a7 to
407b240
Compare
0a7325f to
b62265c
Compare
ginglis13
left a comment
There was a problem hiding this comment.
LGTM - verified FIPS testing following #828 (comment)
| # failure-server is an integ test package that pulls in legacy http libraries | ||
| { name = "failure-server" }, |
There was a problem hiding this comment.
In this case, we're only skipping it for bans but not for licenses, right? That seems like a workable solution.
There was a problem hiding this comment.
If we're ignoring the failure-server branch, I wonder if we can add an explicit ban on ring?
We do an explicit ban on crates in bottlerocket-os/bottlerocket here
There was a problem hiding this comment.
In this case, we're only skipping it for bans but not for licenses, right? That seems like a workable solution.
Yes, this only skips it for bans.
If we're ignoring the
failure-serverbranch, I wonder if we can add an explicit ban onring?
The feature set of reqwest that we're using in tuftool still depends on ring: https://github.com/seanmonstar/reqwest/blob/master/Cargo.toml#L52. We'd need to remove that dependency before we can deny ring.
| # noxious-client is using an older version of reqwest | ||
| { name = "reqwest", version = "=0.11" }, |
There was a problem hiding this comment.
Might be able to remove this now that we're skipping failure-server?
| "aws-smithy-http", | ||
| "aws-smithy-http 0.60.11", |
There was a problem hiding this comment.
I see that we have multiple aws-smithy-http's here but no corresponding skip in deny.toml. Any idea why?
There was a problem hiding this comment.
No, that's really strange, I'm not sure how that wasn't flagged by cargo-deny! The 0.60.x version comes from tough-kms's dev-dependencies, where we specifically use that version. I'll bump it to 0.62.
There was a problem hiding this comment.
I've noticed sometimes the aws-sdk-rust crates will get ahead of themselves and pull multiple aws-smithy-https. You might be able to shake it by pulling newer (but not the newest) SDK crates.
| /// Steps 0 and 1 of the client application, which load the current root metadata file based on a | ||
| /// trusted root metadata file. | ||
| #[expect(clippy::too_many_arguments)] | ||
| #[allow(clippy::needless_continue)] |
There was a problem hiding this comment.
Can you use expect instead of allow?
There was a problem hiding this comment.
Hm, tried this and apparently not. There seems to be something odd with the macos Github actions runner, it doesn't register a needless_continue in this function so it will fail the expect (and it's also had a bunch of other strange failures on this PR). I couldn't replicate this on my mac, but switching this back to allow to pass the workflows.
There was a problem hiding this comment.
This suggests to me that the Mac actions runner must be using an older rust toolchain.
I think it points out to me that we probably don't want this to fail if you are using an older rust toolchain, so I'm OK to leave it as-is.
b62265c to
86a5c3a
Compare
Signed-off-by: Sam Berning <bernings@amazon.com>
Signed-off-by: Sam Berning <bernings@amazon.com>
62dac75 to
9ea3c3e
Compare
Signed-off-by: Sam Berning <bernings@amazon.com>
9ea3c3e to
646fc2a
Compare
Issue #, if available:
Description of changes:
Bump version of AWS SDK to leverage the updated HTTPS stack with
hyper 1.xandaws-lc. See awslabs/aws-sdk-rust#1257.Also migrates from
aws-smithy-experimentaltoaws-smithy-https-client.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.