Impossibile ricostruire a causa dell'aggiornamento della gem AWS SDK e delle nuove protezioni di integrità dei dati AWS

Installazione
28

Ciao, sono Pat Patterson, Chief Technical Evangelist di Backblaze; sono arrivato su questo thread perché ho un forum Discourse self-hosted proof-of-concept e mi sono imbattuto esattamente in questo problema oggi mentre configuravo il mio forum per utilizzare Backblaze B2 per backup e caricamenti.

Impostare AWS_REQUEST_CHECKSUM_CALCULATION e AWS_RESPONSE_CHECKSUM_CALCULATION su WHEN_REQUIRED è una soluzione utile per casi base di caricamento e download di file, ma è utile sapere che non copre una serie di scenari, tra cui:

  • Eliminazione di file: Discourse utilizza l’operazione S3 DeleteObjects per eliminare più file in un’unica chiamata API, come dovrebbe.
  • Caricamento di file in bucket con object lock abilitato.

Il problema è che un checksum (o l’header Content-MD5 o uno dei nuovi header checksum) è richiesto (piuttosto che solo supportato) per queste operazioni, e questo fa sì che gli attuali SDK AWS forniscano il nuovo header checksum. Per quanto ne so, non c’è modo di sovrascrivere questo e far sì che l’SDK fornisca Content-MD5 come faceva in precedenza.

I nostri ingegneri stanno lavorando per risolvere tutto questo; nel frattempo, la migliore mitigazione è utilizzare la versione 1.177.0 o precedente della gemma aws-sdk-s3.

Ho provato a eseguire il downgrade delle versioni della gemma AWS SDK nel mio PoC modificando il Gemfile e sostituendo

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

con

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

ma il mio bundle-fu non è forte e sono riuscito solo a rompere il mio deployment con l’errore:

/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'
...

Suppongo di aver perso qualche passaggio fondamentale.

Senza voler gettare ombra sui nostri amici di DO, lo hanno fatto aggiornando il loro servizio per ignorare semplicemente i nuovi header checksum piuttosto che rifiutare la chiamata API a causa del checksum non supportato.

Il loro rapporto sull’incidente dice:

Si noti che Spaces attualmente non verifica i checksum di integrità dei dati inviati dalla AWS CLI e dagli SDK AWS come parte delle richieste di caricamento

Abbiamo deciso che accettare e archiviare semplicemente dati che potrebbero non corrispondere al checksum fornito dal client API era una cosa negativa.

9 Mi Piace