SignatureDoesNotMatch issue with s3-presign
还没有人认领这个 Issue。
评估
调研方向
从定制的 s3-presign 包以及 sync/src/sync.rs 中约位于第 394-425 行的 presigning 调用开始。使用 cmd/tools/signtest，结合短期 STS 凭证，将它生成的已签名 PUT URL 与 durch/rust-s3 生成的 URL 进行比较。完成的标准是上传能够可靠成功且不会出现 SignatureDoesNotMatch，就像使用替代实现时一样。
由索引模型根据 Issue 内容生成。
描述
I've been working on a self-hostable Logseq Sync backend, and I was having trouble with the issued STS credentials. The flow looked like:
- Client calls
/get_temp_credentials - Server issues new credentials via STS, scoped to just the
/temp:<region>/<random uuid>bucket prefix - Client generates presigned URLs to
PUTfiles to - Uploads fail with
SignatureDoesNotMatch
But I noticed it wasn't failing all the time! One out of every ten or twenty tries would succeed, indicating it wasn't some complete misconfiguration. There are many, many threads about the SignatureDoesNotMatch issue (here's a big one), some are user error, but many seemed to be resolved by regenerating credentials with no /, +, or = in the secret, but I tried that, and the same issue happened.
So to continue debugging, I did a few things:
- I wrote a quick tool that uses the credentials I was generating (via
/get_temp_credentials), and generates signed PUT URLs, then uploads files to them. That worked fine, indicating that the credentials aren't the problem - I swapped out the existing, bespoke
s3-presigncrate with durch/rust-s3, to see if that was the issue, you can see the relevant changes here.
And the swap worked, my local hacked up Logseq client can now reliably upload files with the presigned S3 URLs it generates with the short-lived STS credentials:
15:26:32.398 › update remote files[txid=1]: ["journals/2023_11_25.md", "pages/This is a test.md"]
15:26:32.626 › upload progress: 100% 360/360 journals/2023_11_25.md
15:26:32.627 › upload progress: 100% 304/304 pages/This is a test.md
15:26:33.758 › copy page file to version-files: "journals/2023_11_25.md"
15:26:33.759 › copy page file to version-files: "pages/This is a test.md"
15:26:33.759 › update remote files success, txid=2
So I'm pretty confident the issue is with the s3-presign package. I don't know what the official Logseq Sync server implementation does (likely during STS credential generation?) such that this issue doesn't occur, but it seems there's some edge case that causes it to generate invalid signatures.
- 主要语言
- Rust
- 星标
- 30
- 派生
- 6
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
bug llm translation
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复
-
skillfs: one malformed chat-log line aborts the entire skill-usage analysis (skill_usage_from_chat_logs.py)可能已有人在做 @zjncs 今天认领。 未关闭component:skillfs
难度 2/5 1-3 小时 新手友好度 82/100
agentic-os-org/ANOLISA#6116 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
indygreg/cryptography-rs#99 ·