# AWS SDK gem 버전 상승 및 새로운 AWS 데이터 무결성 보호 기능으로 인해 재빌드 불가

**URL:** https://meta.discourse.org/t/cant-rebuild-due-to-aws-sdk-gem-bump-and-new-aws-data-integrity-protections/354217
**Category:** Self-hosting
**Created:** [2월 24, 2025, 5:39오후 UTC](https://meta.discourse.org/t/cant-rebuild-due-to-aws-sdk-gem-bump-and-new-aws-data-integrity-protections/354217 "2025-02-24T17:39:21Z")
**Posts on this page:** 1
**Showing post:** 28

<div class="post-metadata">

### Author: ![PatPatterson](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/patpatterson/32/445451_2.png) [@PatPatterson](https://meta.discourse.org/u/PatPatterson)
#### Post date: [2월 25, 2025, 11:19오후 UTC](https://meta.discourse.org/t/cant-rebuild-due-to-aws-sdk-gem-bump-and-new-aws-data-integrity-protections/354217/28 "2025-02-25T23:19:39Z")

</div>

안녕하세요 - 저는 Backblaze의 수석 기술 전도사(Chef Technical Evangelist)인 Pat Patterson입니다. 저는 자체 호스팅된 proof-of-concept Discourse 포럼을 운영하고 있으며, 포럼의 백업 및 업로드에 Backblaze B2를 설정하던 중 오늘 우연히 이 동일한 문제에 부딪히게 되어 이 스레드에 참여하게 되었습니다.

`AWS_REQUEST_CHECKSUM_CALCULATION` 및 `AWS_RESPONSE_CHECKSUM_CALCULATION`을 `WHEN_REQUIRED`으로 설정하는 것은 파일 업로드 및 다운로드의 기본적 경우에 유용한 우회책이지만, 다음을 포함한 여러 시나리오에는 적용되지 않는다는 점을 알아두는 것이 좋습니다:

- 파일 삭제 - Discourse는 여러 파일을 단일 API 호출로 삭제하기 위해 `DeleteObjects` S3 연산을 사용하고 있으며, 이는 올바른 방식입니다.
- 오브젝트 락(object lock)이 활성화된 버킷으로 파일 업로드.

문제는 이러한 연산에 대해 체크섬(`Content-MD5` 헤더 또는 새로운 체크섬 헤더 중 하나)이 단순히 지원되는 것을 넘어 _필수_라는 점입니다. 이로 인해 현재 AWS SDK들은 새로운 체크섬 헤더를 제공하게 됩니다. 제가 아는 한, 이를 오버라이드하여 SDK가 예전처럼 `Content-MD5`를 제공하도록 하는 방법은 없습니다.

저희 엔지니어들은 이 문제를 해결하기 위해 노력하고 있으며, 그 동안 최선의 완화 조치는 `aws-sdk-s3` gem의 `1.177.0` 이하 버전을 사용하는 것입니다.

저는 Gemfile을 편집하여 다음을

```plaintext
gem "aws-sdk-s3", require: false
gem "aws-sdk-sns", require: false

```

다음으로 교체함으로써 PoC 배포 환경에서 AWS SDK gem 버전을 하향하는 것을 시도해 보았습니다.

```plaintext
gem "aws-sdk-core", "~> 3.215.1", require: false
gem "aws-sdk-kms", "~> 1.96.0", require: false
gem "aws-sdk-s3", "~> 1.177.0", require: false
gem "aws-sdk-sns", "~> 1.92.0", require: false

```

하지만 제 `bundle` 사용 실력이 부족하여, 다음과 같은 오류로 배포 환경을 망가뜨리는 데만 성공했습니다:

```plaintext
/var/www/discourse/config/initializers/100-sidekiq.rb:69:in `<main>': undefined method `logger=' for module Sidekiq (NoMethodError)

  Sidekiq.logger = Logger.new(nil)
         ^^^^^^^^^
	from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `load'
	from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `block in load_config_initializer'
...

```

아마도 중요한 단계를 놓친 것 같습니다.

> [@pfaffman](#):
>
> 참고로, Digital Ocean은 백업 삭제나 누락된 자산 만료 처리에 문제가 없는 것으로 보입니다.

Digital Ocean의 친구들에게 불이익을 주려는 의도는 아니지만, 그들은 서비스 업데이트를 통해 API 호출을 거부하는 대신 새로운 체크섬 헤더를 단순히 무시하는 방식으로 이 문제를 해결했습니다.

[그들의 사고 보고서](https://status.digitalocean.com/incidents/zbrpd3j7hrrd)에는 다음과 같이 적혀 있습니다:

> Spaces는 현재 업로드 요청의 일부로 AWS CLI 및 AWS SDK에서 전송하는 데이터 무결성 체크섬을 검증하지 않습니다.

우리는 API 클라이언트가 제공한 체크섬과 일치하지 않을 수 있는 데이터를 단순히 수락하고 저장하는 것은 잘못된 일이라고 판단했습니다.

---

_[View the full topic](https://meta.discourse.org/t/cant-rebuild-due-to-aws-sdk-gem-bump-and-new-aws-data-integrity-protections/354217)._
