active_storage_encryption 0.1.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 9c79ba1ae2b68a8d4e76c9d02092e426a41ddd414a968a082121cab647c2e239
+  data.tar.gz: ee60709d1843c4a814c52496a4fffcdec44b36bd3a48f18513fb0b56ba4a0c05
+SHA512:
+  metadata.gz: 2d73fa7ea374c47f4fea531791db5962d469c8e1a95e9e7f9b0f64b9904e1b5948fd298b788b2a6c93a2e8beff0d58fde6ba24aa00c3c852b316232780a4ba4e
+  data.tar.gz: 7a2427499a85bec52196dfbdf304193618febcf7c3ceb0eb0944a01452683dbbb2ff2304a716ae3694fb9f55f6683c337b4d19189f67ce034abe8a58e093a0f5

data/Appraisals

@@ -0,0 +1,7 @@
+appraise "rails-7" do
+  gem "rails", "< 8.0"
+end
+
+appraise "rails-8" do
+  gem "rails", ">= 8.0"
+end

data/MIT-LICENSE

@@ -0,0 +1,20 @@
+Copyright Cheddar Payments BV, Julik Tarkhanov, Sebastian van Hesteren
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.md

@@ -0,0 +1,236 @@
+## What does this do?
+
+This library will enable the use of per-blob encryption keys with ActiveStorage. It enables file encryption with a separate encryption key generated for every `ActiveStorage::Blob`. It uses [CSEK](https://cloud.google.com/storage/docs/encryption/using-customer-supplied-keys) on Google Cloud, [SSE-C](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html#specifying-s3-c-encryption) on AWS, and [block_cipher_kit](https://rubygems.org/gems/block_cipher_kit) for files on disk to add a layer of encryption to every uploaded file. Every `Blob` gets its own, random encryption key.
+
+During streaming download, either the cloud provider or a Rails controller will decrypt the requested chunk of the file as it gets served to the client.
+
+## Installation
+
+Install the gem and run the migration.
+
+```shell
+bundle add active_storage_encryption
+bin/rails active_storage_encryption:install
+bin/rails db:migrate
+```
+
+Then, set up an encrypted service in `config/storage.yml` like so (in this example we use an `EncryptedDisk` service, which you can play around with in development):
+
+```yaml
+# storage.yml
+encrypted_local_disk:
+  service: EncryptedDisk # this is the service implementation you need to use
+  private_url_policy: stream
+  root: <%= Rails.root.join("storage", "encrypted") %>
+```
+
+Then, on your model carrying the attachments:
+
+```ruby
+class User < ApplicationRecord
+  has_one_attached :id_document_scan, service: :encrypted_local_disk
+end
+```
+
+And.. that's it! For both GCS and S3, you will need to create an additional ActiveStorage service. The configuration is exactly the same as stock ActiveStorage services, with the addition of the `private_url_policy` [parameter.](#private-url-constraints)
+
+Note that you need to appropriately configure CORS on your storage bucket to allow direct uploads [for S3](#S3Service) and for [GCP.](#EncryptedGCSService)
+
+## How it works
+
+This gem protects from a relatively common data breach scenario - cloud account access. Should an attacker gain access to your cloud storage bucket, the files stored there will be of no use to them without them also having a separate, specific encryption key for every file they want to retrieve.
+
+The standard implementation of this usually works like this:
+
+* You generate an encryption key which satisfies the provider's requirements
+* You then send that key in a header along with your upload PUT request. The PUT request sends the file unencrypted to the provider, along with the key you have generated and signed.
+* Before depositing your file in the bucket, the provider applies its encryption (and usually - some form of chunking, but that is transparent to you) to the data it receives from you
+* Once the encrypted file is in the cloud storage, there is no plaintext version present anywhere
+* Every read access to the file requires that you provide the encryption key
+
+With this gem, you configure encrypted storage services in your `storage.yml` config, and run the included migration - which adds the `encryption_key` column to your `active_storage_blobs` table. Interactions with the cloud storage will then add the encryption key to all requests.
+
+Once a `Blob` destined to be stored on an encrypted storage service (you set the `service:` where the blob should go in your `has_attached` calls) gets created in Rails, the blob will get a random encryption key generated for it. All further operations with the `Blob` are going to use that generated encryption key, automatically. None of the calls to the Blob will require the encryption key to be provided explicitly - everything should work as if you were dealing with a standard `ActiveStorage::Blob`.
+
+This enables enhanced security for sensitive data, such as uploaded documents of all sorts, identity photos, biometric data and the like.
+
+## Configuration
+
+The use of encrypted file storage can be enabled by plugging an appropriate Service in your storage configuration. With the way the library works, your standard ActiveStorage services you already have will not magically start encrypting the data stored in them. It is recommended to define separate services for your sensitive data, as behaviour of the encrypted data stores differs in subtle ways from a standard ActiveStorage service.
+
+## What this gem _can_ do
+
+It is a tool for additional protection of sensitive files.
+
+Normally, your cloud storage used for binary data will already support some form of encryption-at-rest, usually using the could provider's KMS (key management service). This is a sensible default, however it does not protect you from one important attack vector: a party obtaining access to your cloud storage bucket. If they do manage to obtain that access, they usually also have access to the KMS (by virtue of having access to a cloud account you control) and can bulk-download all of your data, unencrypted. All an attacker needs are cloud credentials for an account with "read" and "list" permissions.
+
+With per-object encryption, however, just access to the bucket does not give the attacker much. Since every object is encrypted with a separate key, they need to have a key for every single file. That key is not stored in the provider's KMS, so even an account with KMS access won't be able to decrypt them.
+
+Additionally, neither the cloud console (web UI) nor the API client will be able to download those objects without the keys.
+
+The only way to obtain access would be for the attacker to have access to:
+
+* A database dump of the `active_storage_blobs` table
+* Your application's secrets (to decrypt the values in the table).
+* The cloud storage bucket
+
+It's way more work, and way more hassle. This is great for sensitive files, and increases security considerably.
+
+## What this gem _cannot_ do
+
+This gem does not provide an E2E encrypted solution. The file still gets encrypted by your cloud provider, and decrypted by your cloud provider. While it offers a strong protection _at rest_ it does not offer extra protection _in transit._ If you need that level of protection, you may want to look into [S3 client encryption](https://ankane.org/activestorage-s3-encryption) or other similar tech.
+
+## Encrypted Service implementations
+
+At the moment, we provide a few encrypted `Service` subclasses that you can use.
+
+### EncryptedGCSService - Google Cloud Storage
+
+The `EncryptedGCSService` supports most of the features of the stock `GCSService`:
+
+* Upload and download
+* Presigned PUT requests (direct upload)
+* Preset metadata (content-disposition, content-type etc.)
+
+Implementation details:
+
+* Presigned URLs are subject to the [same constraints](#private-url-constraints) as the other providers. GCP will only serve you objects if you supply the headers. If you wish to generate URLs that can be used without headers, streaming goes through our provided controller.
+* In the stock `Service` the `#compose` operation is "hopless": you tell GCP to "splice" multiple objects in-situ without having to download their content into your application. With encryption, `#compose` can't be performed "hoplessly" as the "compose" RPC call for encrypted objects requires the source objects be encrypted with the same encryption key - all of them. The resulting object will also be encrypted with that key. With this gem, every `Blob` gets encrypted with its own random key, so performing a `#compose` requires downloading the objects, decrypting them and reuploading the composed object. This gets done in a streaming manner to conserve disk space and memory (we provide a resumable upload client for GCS even though the official SDK does not), but the operation is no longer "hopless".
+* You will need to enable the following headers in your bucket CORS configuration for `PUT` requests:
+  * `x-goog-encryption-algorithm`
+  * `x-goog-encryption-key`
+  * `x-goog-encryption-key-sha256`
+
+### EncryptedS3Service - AWS S3
+
+The `EncryptedS3Service` supports most of the features of the stock `S3Service`.
+
+Implementation details:
+
+* SSE-C is a feature that AWS provides. Other services offering S3-compatible object storage (Minio, Ceph...) may not support this feature - check the documentation of your provider.
+* Presigned URLs are subject to the [same constraints](#private-url-constraints) as with GCS. S3 will only serve you objects if you supply the headers. If you wish to generate URLs that can be used without headers, streaming goes through our provided controller.
+* The `#compose` operation is not hopless with S3, so there is no reduction in functionality vis-a-vis the standard `S3Service`.
+* You will need to enable the following headers in your bucket CORS configuration for `PUT` requests:
+  * `x-amz-server-side-encryption-customer-algorithm`
+  * `x-amz-server-side-encryption-customer-key`
+  * `x-amz-server-side-encryption-customer-key-MD5`
+
+### EncryptedDiskSevice - Filesystem
+
+Can be used instead of the cloud services in development, or on the server if desired. The service will use AES-256-GCM encryption, with a way to switch to a different/more modern encryption scheme in the future.
+
+Implementation details:
+
+* Files will have the `.encrypted-v<N>` filename extension. The `v-<N>` stands for the version of the encryption scheme applied.
+* Presigned URLs are subject to the [same constraints](#private-url-constraints) as the other providers. To resemble other encrypted Services, presigned URLs with header requirement will only be served by the provided controller if appropriate headers are sent with the request. If you wish to generate URLs that can be used without headers, streaming goes through our provided controller.
+* The schemes for encryption are in the `block_cipher_kit` gem. Currently we use AES-256-GCM for blobs, with the authentication tag verified in case of a full download. Random access uses AES-256-CTR.
+* A SHA2 digest of the encryption key is stored at the beginning of the encrypted file. This is used to deny download rapidly if an incorrect encryption key is provided.
+* The IV is stored at the start of the ciphertext, after the digest of the encryption key. The IV gets generated at random for every Blob being encrypted.
+
+## Additional information
+
+* The stored `digest` (the Base64-encoded MD5 of the blob) will be for the plaintext file contents. This reduces security somewhat, because MD5 has known collisions and facilitates (to some extend) mounting a "known plaintext" attack.
+* The stored `filesize` will be for the plaintext. This, again, facilitates an attack somewhat.
+
+## Downloading the plaintext file contents in full or in part
+
+Data will be automatically decrypted using the correct key on `Blob#open` or `Blob#download`. `EncryptedDiskSevice` will also apply the GCM validation check at the end of download/read (authenticate the cipher).
+
+All of our encrypted Services support `download_range` for random access to the blob's plaintext. The decryption will be done in a streaming manner, without buffering:
+
+* Cloud providers give you access to plaintext segments of the file using the HTTP `Range:` header (ranges are in plaintext offsets)
+* `EncryptedDiskSevice` provides the same, but inside the app will access OS files - decrypting them in a streaming manner.
+
+## Constraints with encrypted Blobs
+
+There are also subtle differences in how cloud providers treat encrypted objects in their object storage vs. how other objects are treated, as well as which facilities change or become unavailable once your object is encrypted. Additionally, some ActiveStorage operations change semantics or start requiring an `encryption_key:` argument. Understanding those limitations is key to using active_storage_encryption correctly and effectively.
+
+Key differences are as follows:
+
+* If a Service supports encryption, _every_ blob stored on it will be encrypted. No exceptions. You cannot supply an encryption key of `nil` to bypass encryption on that service.
+* A blob stored onto - or retrieved from - an encrypted Service must have an `#encryption_key` that is not `nil`
+* Most operations performed on an encrypted Service must supply the encryption key, or multiple encryption keys (in case of `Service#compose`)
+* An encrypted Service cannot be `public: true` - no CDNs we are aware of can proxy objects with per-object encryption keys.
+* An encrypted Service cannot generate a signed GET URL unless you let that URL go through a streaming controller (we provide one), or you are going to send headers to the cloud providers' download endpoint. We default to using the streaming controller, which may cause a performance impact on your app due to slow clients. See more [here.](#private-url-constraints)
+* Objects using per-object encryption are usually **inaccessible for cloud automation** - for example, scripts that load files into a cloud database using paths to the bucket will likely not work, as data is no longer readable for them. There will also be limitations for CLI clients. For example, the `gcloud` CLI only allows you to supply 100 encryption keys, and thus will only be able to download 100 objects at once.
+
+## Private URL constraints
+
+Both major cloud providers (S3 and GCP cloud storage) disallow using signed GET URLs unless you also supply the encryption key (and encryption parameters, as well as the key checksum) in the GET request headers. This has _severe_ implications for use of `Blob#url` and `rails_blob_path` / `rails_blob_url`, namely:
+
+* You cannot redirect to a signed GET URL for an ActiveStorage blob (for downloading). Standard Rails `blob_path` helpers lead to an ActiveStorage controller which will try to redirect your browser to such a URL, but the browser will then receive a `403 Forbidden` response.
+* You can no longer use a signed GET URL for an ActiveStorage blob as the `src` attribute for an `img`, `video` or `audio` element
+
+Cloud providers presumably disallow supplying the encryption key inside the URL itself because they want to prevent those URLs gettng saved in web server / load balancer logs, and from being shared. This is a valid security concern, as most URL signing schemes are just for _signing_ but not for _encryption._ An encryption key of this nature could also be retained by a malicious party and reused.
+
+However, for practical purposes you _may_ want to permit such URLs to be generated by your application, with very limited expiry time. We allow for this, with an associated limitation that the blob binary data **is then going to be streamed.** In that setup your Rails app functions as a streaming proxy, which will perform the request to cloud storage - passing along the requisite credentials - and stream the output to your client. This may not be the most performant way to stream data, but when per-file encryption is required this usually concerns sensitive files, which are not very widely shared anyway. We believe streaming to be a sensible compromise. Note that you want the streaming URLs to be short-lived!
+
+To configure this facility, every encrypted `Service` we provide supports the `private_url_policy` configuration parameter. The possible values are as follows:
+
+* `private_url_policy: disable` will make every call to `Blob#url` raise an exception. This will be raised by the stock Rails `ActiveStorage::Blobs::RedirectController#show`
+* `private_url_policy: require_headers` will generate signed URLS, and you will need to ensure these URLs are only requested with the correct HTTP headers. The URLs will not expose the encryption key. When trying to use `rails_blob_path` you will end up receiving a 403 from the cloud storage provider after the redirect. You still may want to generate those URLs if you want to use them elsewhere and will be willing to manually add HTTP headers to the request.
+* `private_url_policy: stream` will stream the decrypted Blob through our Rails controller. The URLs to that controller will not expose the encryption key. `rails_blob_path` will work, and generate a URL to the stock Rails `ActiveStorage::Blobs::RedirectController#show` action. That action, in turn, will generate a URL leading to `ActiveStorageEncryption::EncryptedBlobsController#show`. That action will stream out your file from whichever encrypted service your Blob is using.
+
+For using the `require_headers` option you may want to use `Blob#headers_for_private_download` method - it will return you a `Hash` of headers that have to be supplied along with your request to the signed URL of the cloud service.
+
+## Key exposure on upload
+
+Both implementations of customer-supplied encryption keys (S3 and GCP) sign the checksum of the encryption key issued to the uploading client, so that the client may not alter the encryption key your application has issued. However, neither of them support key wrapping - encrypting the key before giving it to the client for performing the upload. GCP does support key wrapping, but only for its Compute Platform, and not for Cloud Storage. Therefore, the uploading client (the one that performs the PUT to the cloud storage or to our controller) is going to be able to decode and retain the raw encryption key.
+
+You can, of course, rewrite the object in storage to decrypt it and re-encrypt it with a new encryption key, which the original uploader does not possess. This takes extra resources, however.
+
+## Key exposure on download
+
+When we stream through the controller, we encrypt the token instead of just signing it. This conceals the encryption key of the Blob, and uses standard Rails encryption. For our purposes we consider this configuration sufficiently secure.
+
+## Direct uploads
+
+All supported services accept the encryption key as part of the headers for the PUT direct upload. The provided Service implementations will generate the correct headers for you. However, your upload client _must_ use the headers provided to you by the server, and not invent its own. The standard ActiveStorage JS bundles honor those headers - but if you use your own uploader you will need to ensure it honors and forwards the headers too.
+
+We also configure the services to generate _and_ require the `Content-MD5` header. The client doing the PUT will need to precompute the MD5 for the object before starting the PUT request or getting a PUT url (as the checksum gets signed by the cloud SDK or by our `EncryptedDiskService`). This is so that any data transmission errors can be intercepted early (we know of one case where a bug in Ruby, combined with a particular HTTP client library, led to bytes getting uploaded out of order).
+
+## Security considerations / notes
+
+* It is imperative that you let the server generate the encryption key, and not generate one on the client. Where possible, we add the headers for the encryption key to the signed URL parameters, so client generated keys will deliberately _not_ function. Letting the client generate the keys can lead to key reuse (unintentional or - worse - intentional).
+* The key used is _not_ a passphrase or a password. It is a high-entropy bag of bytes, generated for every blob separately using `SecureRandom`. We generate more bytes than the cloud providers usually expect (32 bytes for AES) and take the starting bytes off that longer key - that is to allow mirroring to services that have varying key lengths, using the same encryption key.
+* To the best of our knowledge, both S3 and GCS use AES-256-GCM (or a variation thereof) for encryption. Random access to GCM blocks requires dropping the auth tag validation (cipher authentication) of GCM, and downgrades it to CTR. We find this an acceptable tradeoff to enable random access.
+* You must use `attribute_encrypted` and encrypt your `encryption_key` in the `active_storage_blobs` table, otherwise your data is not really safe in case a database dump gets exfiltrated.
+* active_storage_encryption has not been verified by information security experts or cryptographers. While we do our best to have it be robust and secure, mishaps may happen. You have been warned.
+* While cloud providers do publish some information about their encryption approaches, we do not know several crucial details allowing one to say that "this encryption scheme is secure enough for our needs". Namely:
+  * Neither GCP nor AWS say how the IV gets generated. A compromised IV (repeated IV) simplifies breaking a block cipher considerably.
+  * Neither GCP nor AWS say when they reset the IV. Counter-based IVs have a limit on the number of counter values and blocks that they support. For GCM and CTR the practical limit is around 64GB per encrypted message. To add extra safety, it is sometimes advised to "stitch" the message from multiple messages with the IV getting regenerated at random, for every message. If providers do use such "chunking", we could not find information about the size of the chunks nor the mechanics by which the IV gets generated for them.
+
+Finally: this gem has not been verified by an information security expert or a cryptographer. While we did take all the possible precautions with regards to producing a secure design, we are all humans and might have omitted something.
+
+## Mirroring
+
+We provide a version of the `EncryptedMirrorService` which is going to use the same encryption key when mirroring to multiple services. It needs some modifications in comparison to a standard `MirrorService` because if any services it mirrors to use encryption, it needs an encryption key to be provided upstream for all write operations - so that it can be passed on to downstream Services. You can only mirror an encrypted `Blob` to encrypted services.
+
+## Key truncation
+
+In practice, all services use some form of AES-256 and therefore use a 32-byte encryption key. However, we can't exclude the possibility that there will be support for newer encryption schemes in the future with a longer encryption key being available. Because we potentially may need to allow a `Blob` to be encrypted and decrypted by service A, and then encrypted by service B, there is a possibility that key length requirements for those services could differ. Therefore, we generate a longer `encryption_key` (from the same random byte source) than strictly necessary for AES-256 and save it in your `active_storage_blobs` table. This key then gets truncated to satisfy the key length requirements of a particular encrypted Service.
+
+This has an important implication for how the Service classes are written: they need to truncate the encryption keys to their conformant length themselves.
+
+Important, once again: **do not use passwords for this encryption key.** If you really want to use passwords, use something like PBKDF (available via [ActiveSupport::KeyGenerator](https://api.rubyonrails.org/classes/ActiveSupport/KeyGenerator.html) to derive a high-entropy key from your passphrase in a safe manner.
+
+## Storing your encryption keys securely
+
+The `encryption_key` must be subjected to ActiveRecord attribute encryption. Of course, you may not do it, but... no - wait. Once more:
+
+> [!WARNING]  
+> The `ActiveStorage::Blob#encryption_key` attribute must be an encrypted ActiveRecord attribute. Do set up your attribute encryption.
+
+The value in that column is what's called "key material". It is highly sensitive and the attacker obtaining a database dump will immediately have unfettered access to all the encryption keys, for all Blobs that you have. You can refer to [this guide](https://guides.rubyonrails.org/active_record_encryption.html) on how to set up attribute encryption. The variant you want is **non-deterministic encryption** (you likely do not want to search for a specific encryption key in your database).
+
+## Migrating your blobs into an encrypted store
+
+We provide a method on the `Blob` for this - called `migrate_to_encrypted_service(service)`. The method will:
+
+* Generate an `encryption_key` for the blob in question
+* Stream the plaintext data into a copy on the encrypted service, applying encryption
+* Transactionally store the encryption key on the `Blob` _and_ switch its `service` to the encrypted service.
+
+
+## License
+The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).

data/Rakefile

@@ -0,0 +1,17 @@
+# frozen_string_literal: true
+
+require "bundler/setup"
+require "bundler/gem_tasks"
+
+APP_RAKEFILE = File.expand_path("test/dummy/Rakefile", __dir__)
+load "rails/tasks/engine.rake"
+load "rails/tasks/statistics.rake"
+
+require "bundler/gem_tasks"
+
+task :format do
+  `bundle exec standardrb --fix`
+  `bundle exec magic_frozen_string_literal .`
+end
+
+task default: ["app:test"]

data/bin/rails

@@ -0,0 +1,26 @@
+#!/usr/bin/env ruby
+# This command will automatically be run when you run "rails" with Rails gems
+# installed from the root of your application.
+
+ENGINE_ROOT = File.expand_path("..", __dir__)
+ENGINE_PATH = File.expand_path("../lib/active_storage_encryption/engine", __dir__)
+APP_PATH = File.expand_path("../test/dummy/config/application", __dir__)
+
+# Set up gems listed in the Gemfile.
+ENV["BUNDLE_GEMFILE"] ||= File.expand_path("../Gemfile", __dir__)
+require "bundler/setup" if File.exist?(ENV["BUNDLE_GEMFILE"])
+
+require "rails"
+# Pick the frameworks you want:
+require "active_model/railtie"
+# require "active_job/railtie"
+require "active_record/railtie"
+# require "active_storage/engine"
+require "action_controller/railtie"
+# require "action_mailer/railtie"
+# require "action_mailbox/engine"
+# require "action_text/engine"
+require "action_view/railtie"
+# require "action_cable/engine"
+require "rails/test_unit/railtie"
+require "rails/engine/commands"

data/bin/rubocop

@@ -0,0 +1,8 @@
+#!/usr/bin/env ruby
+require "rubygems"
+require "bundler/setup"
+
+# explicit rubocop config increases performance slightly while avoiding config confusion.
+ARGV.unshift("--config", File.expand_path("../.rubocop.yml", __dir__))
+
+load Gem.bin_path("rubocop", "rubocop")

data/config/initializers/active_storage_encryption.rb

@@ -0,0 +1,9 @@
+# frozen_string_literal: true
+
+ActiveSupport::Reloader.to_prepare do
+  require "active_storage_encryption"
+  ActiveStorage::Blob.send(:include, ActiveStorageEncryption::Overrides::EncryptedBlobClassMethods)
+  ActiveStorage::Blob.send(:prepend, ActiveStorageEncryption::Overrides::EncryptedBlobInstanceMethods)
+  ActiveStorage::Blob::Identifiable.send(:prepend, ActiveStorageEncryption::Overrides::BlobIdentifiableInstanceMethods)
+  ActiveStorage::Downloader.send(:prepend, ActiveStorageEncryption::Overrides::DownloaderInstanceMethods)
+end

data/config/routes.rb

@@ -0,0 +1,7 @@
+# frozen_string_literal: true
+
+ActiveStorageEncryption::Engine.routes.draw do
+  put "/blob/:token", to: "encrypted_blobs#update", as: "encrypted_blob_put"
+  get "/blob/:token/*filename(.:format)", to: "encrypted_blobs#show", as: "encrypted_blob_streaming_get"
+  post "/blob/direct-uploads", to: "encrypted_blobs#create_direct_upload", as: "create_encrypted_blob_direct_upload"
+end

data/gemfiles/rails_7.gemfile

@@ -0,0 +1,7 @@
+# This file was generated by Appraisal
+
+source "https://rubygems.org"
+
+gem "rails", "< 8.0"
+
+gemspec path: "../"

data/gemfiles/rails_7.gemfile.lock

@@ -0,0 +1,276 @@
+PATH
+  remote: ..
+  specs:
+    active_storage_encryption (0.1.0)
+      activestorage
+      block_cipher_kit (>= 0.0.4)
+      rails (>= 7.2.2.1)
+
+GEM
+  remote: https://rubygems.org/
+  specs:
+    actioncable (7.2.2.1)
+      actionpack (= 7.2.2.1)
+      activesupport (= 7.2.2.1)
+      nio4r (~> 2.0)
+      websocket-driver (>= 0.6.1)
+      zeitwerk (~> 2.6)
+    actionmailbox (7.2.2.1)
+      actionpack (= 7.2.2.1)
+      activejob (= 7.2.2.1)
+      activerecord (= 7.2.2.1)
+      activestorage (= 7.2.2.1)
+      activesupport (= 7.2.2.1)
+      mail (>= 2.8.0)
+    actionmailer (7.2.2.1)
+      actionpack (= 7.2.2.1)
+      actionview (= 7.2.2.1)
+      activejob (= 7.2.2.1)
+      activesupport (= 7.2.2.1)
+      mail (>= 2.8.0)
+      rails-dom-testing (~> 2.2)
+    actionpack (7.2.2.1)
+      actionview (= 7.2.2.1)
+      activesupport (= 7.2.2.1)
+      nokogiri (>= 1.8.5)
+      racc
+      rack (>= 2.2.4, < 3.2)
+      rack-session (>= 1.0.1)
+      rack-test (>= 0.6.3)
+      rails-dom-testing (~> 2.2)
+      rails-html-sanitizer (~> 1.6)
+      useragent (~> 0.16)
+    actiontext (7.2.2.1)
+      actionpack (= 7.2.2.1)
+      activerecord (= 7.2.2.1)
+      activestorage (= 7.2.2.1)
+      activesupport (= 7.2.2.1)
+      globalid (>= 0.6.0)
+      nokogiri (>= 1.8.5)
+    actionview (7.2.2.1)
+      activesupport (= 7.2.2.1)
+      builder (~> 3.1)
+      erubi (~> 1.11)
+      rails-dom-testing (~> 2.2)
+      rails-html-sanitizer (~> 1.6)
+    activejob (7.2.2.1)
+      activesupport (= 7.2.2.1)
+      globalid (>= 0.3.6)
+    activemodel (7.2.2.1)
+      activesupport (= 7.2.2.1)
+    activerecord (7.2.2.1)
+      activemodel (= 7.2.2.1)
+      activesupport (= 7.2.2.1)
+      timeout (>= 0.4.0)
+    activestorage (7.2.2.1)
+      actionpack (= 7.2.2.1)
+      activejob (= 7.2.2.1)
+      activerecord (= 7.2.2.1)
+      activesupport (= 7.2.2.1)
+      marcel (~> 1.0)
+    activesupport (7.2.2.1)
+      base64
+      benchmark (>= 0.3)
+      bigdecimal
+      concurrent-ruby (~> 1.0, >= 1.3.1)
+      connection_pool (>= 2.2.5)
+      drb
+      i18n (>= 1.6, < 2)
+      logger (>= 1.4.2)
+      minitest (>= 5.1)
+      securerandom (>= 0.3)
+      tzinfo (~> 2.0, >= 2.0.5)
+    appraisal (2.5.0)
+      bundler
+      rake
+      thor (>= 0.14.0)
+    ast (2.4.2)
+    aws-eventstream (1.3.1)
+    aws-partitions (1.1060.0)
+    aws-sdk-core (3.220.0)
+      aws-eventstream (~> 1, >= 1.3.0)
+      aws-partitions (~> 1, >= 1.992.0)
+      aws-sigv4 (~> 1.9)
+      base64
+      jmespath (~> 1, >= 1.6.1)
+    aws-sdk-kms (1.99.0)
+      aws-sdk-core (~> 3, >= 3.216.0)
+      aws-sigv4 (~> 1.5)
+    aws-sdk-s3 (1.182.0)
+      aws-sdk-core (~> 3, >= 3.216.0)
+      aws-sdk-kms (~> 1)
+      aws-sigv4 (~> 1.5)
+    aws-sigv4 (1.11.0)
+      aws-eventstream (~> 1, >= 1.0.2)
+    base64 (0.2.0)
+    benchmark (0.4.0)
+    bigdecimal (3.1.9)
+    block_cipher_kit (0.0.4)
+    builder (3.3.0)
+    concurrent-ruby (1.3.5)
+    connection_pool (2.5.0)
+    crass (1.0.6)
+    date (3.4.1)
+    drb (2.2.1)
+    erubi (1.13.1)
+    globalid (1.2.1)
+      activesupport (>= 6.1)
+    i18n (1.14.7)
+      concurrent-ruby (~> 1.0)
+    io-console (0.8.0)
+    irb (1.15.1)
+      pp (>= 0.6.0)
+      rdoc (>= 4.0.0)
+      reline (>= 0.4.2)
+    jmespath (1.6.2)
+    json (2.10.1)
+    language_server-protocol (3.17.0.4)
+    lint_roller (1.1.0)
+    logger (1.6.6)
+    loofah (2.24.0)
+      crass (~> 1.0.2)
+      nokogiri (>= 1.12.0)
+    magic_frozen_string_literal (1.2.0)
+    mail (2.8.1)
+      mini_mime (>= 0.1.1)
+      net-imap
+      net-pop
+      net-smtp
+    marcel (1.0.4)
+    mini_mime (1.1.5)
+    minitest (5.25.4)
+    net-http (0.6.0)
+      uri
+    net-imap (0.5.6)
+      date
+      net-protocol
+    net-pop (0.1.2)
+      net-protocol
+    net-protocol (0.2.2)
+      timeout
+    net-smtp (0.5.1)
+      net-protocol
+    nio4r (2.7.4)
+    nokogiri (1.18.3-x86_64-darwin)
+      racc (~> 1.4)
+    nokogiri (1.18.3-x86_64-linux-gnu)
+      racc (~> 1.4)
+    parallel (1.26.3)
+    parser (3.3.7.1)
+      ast (~> 2.4.1)
+      racc
+    pp (0.6.2)
+      prettyprint
+    prettyprint (0.2.0)
+    psych (5.2.3)
+      date
+      stringio
+    racc (1.8.1)
+    rack (3.1.11)
+    rack-session (2.1.0)
+      base64 (>= 0.1.0)
+      rack (>= 3.0.0)
+    rack-test (2.2.0)
+      rack (>= 1.3)
+    rackup (2.2.1)
+      rack (>= 3)
+    rails (7.2.2.1)
+      actioncable (= 7.2.2.1)
+      actionmailbox (= 7.2.2.1)
+      actionmailer (= 7.2.2.1)
+      actionpack (= 7.2.2.1)
+      actiontext (= 7.2.2.1)
+      actionview (= 7.2.2.1)
+      activejob (= 7.2.2.1)
+      activemodel (= 7.2.2.1)
+      activerecord (= 7.2.2.1)
+      activestorage (= 7.2.2.1)
+      activesupport (= 7.2.2.1)
+      bundler (>= 1.15.0)
+      railties (= 7.2.2.1)
+    rails-dom-testing (2.2.0)
+      activesupport (>= 5.0.0)
+      minitest
+      nokogiri (>= 1.6)
+    rails-html-sanitizer (1.6.2)
+      loofah (~> 2.21)
+      nokogiri (>= 1.15.7, != 1.16.7, != 1.16.6, != 1.16.5, != 1.16.4, != 1.16.3, != 1.16.2, != 1.16.1, != 1.16.0.rc1, != 1.16.0)
+    railties (7.2.2.1)
+      actionpack (= 7.2.2.1)
+      activesupport (= 7.2.2.1)
+      irb (~> 1.13)
+      rackup (>= 1.0.0)
+      rake (>= 12.2)
+      thor (~> 1.0, >= 1.2.2)
+      zeitwerk (~> 2.6)
+    rainbow (3.1.1)
+    rake (13.2.1)
+    rdoc (6.12.0)
+      psych (>= 4.0.0)
+    regexp_parser (2.10.0)
+    reline (0.6.0)
+      io-console (~> 0.5)
+    rubocop (1.71.2)
+      json (~> 2.3)
+      language_server-protocol (>= 3.17.0)
+      parallel (~> 1.10)
+      parser (>= 3.3.0.2)
+      rainbow (>= 2.2.2, < 4.0)
+      regexp_parser (>= 2.9.3, < 3.0)
+      rubocop-ast (>= 1.38.0, < 2.0)
+      ruby-progressbar (~> 1.7)
+      unicode-display_width (>= 2.4.0, < 4.0)
+    rubocop-ast (1.38.1)
+      parser (>= 3.3.1.0)
+    rubocop-performance (1.23.1)
+      rubocop (>= 1.48.1, < 2.0)
+      rubocop-ast (>= 1.31.1, < 2.0)
+    ruby-progressbar (1.13.0)
+    securerandom (0.4.1)
+    sqlite3 (2.6.0-x86_64-darwin)
+    sqlite3 (2.6.0-x86_64-linux-gnu)
+    standard (1.45.0)
+      language_server-protocol (~> 3.17.0.2)
+      lint_roller (~> 1.0)
+      rubocop (~> 1.71.0)
+      standard-custom (~> 1.0.0)
+      standard-performance (~> 1.6)
+    standard-custom (1.0.2)
+      lint_roller (~> 1.0)
+      rubocop (~> 1.50)
+    standard-performance (1.6.0)
+      lint_roller (~> 1.1)
+      rubocop-performance (~> 1.23.0)
+    stringio (3.1.5)
+    thor (1.3.2)
+    timeout (0.4.3)
+    tzinfo (2.0.6)
+      concurrent-ruby (~> 1.0)
+    unicode-display_width (3.1.4)
+      unicode-emoji (~> 4.0, >= 4.0.4)
+    unicode-emoji (4.0.4)
+    uri (1.0.3)
+    useragent (0.16.11)
+    websocket-driver (0.7.7)
+      base64
+      websocket-extensions (>= 0.1.0)
+    websocket-extensions (0.1.5)
+    zeitwerk (2.7.2)
+
+PLATFORMS
+  x86_64-darwin
+  x86_64-linux
+
+DEPENDENCIES
+  active_storage_encryption!
+  appraisal
+  aws-sdk-s3
+  magic_frozen_string_literal
+  net-http
+  rails (< 8.0)
+  rake
+  sqlite3
+  standard (>= 1.35.1)
+
+BUNDLED WITH
+   2.5.11

data/gemfiles/rails_8.gemfile

@@ -0,0 +1,7 @@
+# This file was generated by Appraisal
+
+source "https://rubygems.org"
+
+gem "rails", ">= 8.0"
+
+gemspec path: "../"