mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 13:26:00 +03:00
[GH-ISSUE #2513] About automatic downgrade to sigv2 on failed authentication attempts #1225
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#1225
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ggtakec on GitHub (Aug 17, 2024).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2513
About downgrade to sigv2 automatically
When s3fs checks authentication at startup, if sigv2/sigv4 is not specified intentionally and authentication fails, it downgrades to sigv2 and retries.
We would like to consider whether or not to continue supporting this function.
If all AWS regions have switched to sigv4, automatic downgrade seems unnecessary.
However, the situation of compatible S3 products other than AWS will also need to be taken into consideration. (I think this can be avoided by forcing the specification of either sigv2 or sigv4.)
@gaul commented on GitHub (Aug 24, 2024):
I also dislike the existing behavior of falling back to v2 which can confuse error reporting. I prefer that s3fs defaults to
-o sigv4and allow users to override with-o sigv2. This will upset and break some users but v4 signatures should be well-supported 10 years after they were introduced. I also believe there are some security advantages to v4-only.