[PR #2806] [MERGED] Abort requests when SSE headers cannot be set #2802

New issue

Closed

opened 2026-03-04 02:07:21 +03:00 by kerem · 0 comments

kerem commented

2026-03-04 02:07:21 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/s3fs-fuse/s3fs-fuse/pull/2806
Author: @CarstenGrohmann
Created: 2/22/2026
Status: ✅ Merged
Merged: 2/22/2026
Merged by: @ggtakec

Base: master ← Head: add_missing_returns

📝 Commits (1)

a76f84d Abort requests when SSE headers cannot be set

📊 Changes

1 file changed (+18 additions, -9 deletions)

View changed files

📝 src/curl.cpp (+18 -9)

📄 Description

AddSseRequestHead() returned true even when the SSE-C key lookup failed, and all eight callers logged a warning but continued without encryption. If something goes wrong with SSE setup, data would be sent unencrypted.

In practice the error path is unreachable today because startup validation in FinalCheckSse() prevents s3fs from running with SSE-C and an empty key list. But the code should not rely on that -- if AddSseRequestHead fails, the request must not proceed.

Return false from AddSseRequestHead on SSE-C key failure and abort with -EIO at all call sites, consistent with how PreHeadRequest already handles this case.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/s3fs-fuse/s3fs-fuse/pull/2806 **Author:** [@CarstenGrohmann](https://github.com/CarstenGrohmann) **Created:** 2/22/2026 **Status:** ✅ Merged **Merged:** 2/22/2026 **Merged by:** [@ggtakec](https://github.com/ggtakec) **Base:** `master` ← **Head:** `add_missing_returns` --- ### 📝 Commits (1) - [`a76f84d`](https://github.com/s3fs-fuse/s3fs-fuse/commit/a76f84ddf259d41bce9f49d71dd9183dc3341bb1) Abort requests when SSE headers cannot be set ### 📊 Changes **1 file changed** (+18 additions, -9 deletions) <details> <summary>View changed files</summary> 📝 `src/curl.cpp` (+18 -9) </details> ### 📄 Description `AddSseRequestHead()` returned true even when the SSE-C key lookup failed, and all eight callers logged a warning but continued without encryption. If something goes wrong with SSE setup, data would be sent unencrypted. In practice the error path is unreachable today because startup validation in `FinalCheckSse()` prevents s3fs from running with SSE-C and an empty key list. But the code should not rely on that -- if `AddSseRequestHead` fails, the request must not proceed. Return false from `AddSseRequestHead` on SSE-C key failure and abort with `-EIO` at all call sites, consistent with how `PreHeadRequest` already handles this case. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>