Impossible de reconstruire en raison de la mise à jour de la gem AWS SDK et des nouvelles protections d'intégrité des données AWS

Installation
28

Salut, je suis Pat Patterson, évangéliste technique en chef chez Backblaze ; je suis tombé sur ce fil de discussion car j’ai un forum Discourse auto-hébergé en preuve de concept, et je suis tombé sur ce problème exact aujourd’hui en configurant mon forum pour utiliser Backblaze B2 pour les sauvegardes et les téléchargements.

Définir AWS_REQUEST_CHECKSUM_CALCULATION et AWS_RESPONSE_CHECKSUM_CALCULATION sur WHEN_REQUIRED est une solution de contournement utile pour les cas de base de téléchargement et de téléversement de fichiers, mais il est utile de savoir que cela ne couvre pas un certain nombre de scénarios, notamment :

  • Suppression de fichiers - Discourse utilise l’opération S3 DeleteObjects pour supprimer plusieurs fichiers en un seul appel API, comme il se doit.
  • Téléversement de fichiers vers des compartiments avec verrouillage d’objets activé.

Le problème est qu’une somme de contrôle (soit l’en-tête Content-MD5, soit l’un des nouveaux en-têtes de somme de contrôle) est requise (plutôt que simplement prise en charge) pour ces opérations, et cela amène les SDK AWS actuels à fournir le nouvel en-tête de somme de contrôle. Autant que je sache, il n’y a aucun moyen de contourner cela et de faire en sorte que le SDK fournisse Content-MD5 comme il le faisait auparavant.

Nos ingénieurs travaillent à résoudre tout cela ; en attendant, la meilleure mesure d’atténuation est d’utiliser la version 1.177.0 ou antérieure de la gemme aws-sdk-s3.

J’ai essayé de rétrograder les versions de la gemme AWS SDK dans mon déploiement PoC en modifiant le Gemfile et en remplaçant

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

par

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

mais mon bundle-fu n’est pas assez fort, et je n’ai réussi qu’à casser mon déploiement avec l’erreur :

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

Je suppose que j’ai manqué une étape vitale.

Sans vouloir jeter l’ombre sur nos amis de DO, ils l’ont fait en mettant à jour leur service pour ignorer simplement les nouveaux en-têtes de somme de contrôle plutôt que de rejeter l’appel API en raison de la somme de contrôle non prise en charge.

Leur rapport d’incident indique :

Notez que Spaces ne vérifie actuellement pas les sommes de contrôle d’intégrité des données envoyées par l’AWS CLI et les SDK AWS dans le cadre des demandes de téléchargement.

Nous avons décidé qu’accepter et stocker des données qui pourraient ne pas correspondre à la somme de contrôle fournie par le client API était une mauvaise chose.

9 « J'aime »